- Akciófigyelő: Jelentősen olcsóbban nyit az Ulefone új mindenese
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Motorola Edge 40 neo - színre és formára
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Mobil flották
- Netfone
- Samsung Galaxy A52s 5G - jó S-tehetség
- Android szakmai topik
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- iPhone topik
Új hozzászólás Aktív témák
-
modder
aktív tag
Ahha, ez érdekes, ezek szerint csak beépített típusokra működik, és objektum esetén pont úgy viselkedik, mint pl. a Java, és nem úgy, mint C++ (ott ugye objektumot is simán lemásolja, ha nem referenciaként van átadva).
Tömbnél nem meglepő módon lemásolja az egész tömböt (ebből indultam ki a példámnál):
function test($var)
{
$var['bar'] = 'foobar';
}
$foo = array('bar' => 'baz');
print $foo['bar'] . "\n"; // baz
test($foo);
print $foo['bar'] . "\n"; // bazEzek szerint objektumnál fölösleges is referencia szerint átadni abban az esetben, amit az előző hozzászólásomban írtam.
Kösz a helyesbítést
-
#14998
modder
aktív tag
Speeedfire
#14996
modder
aktív tag
válasz
Speeedfire
#14996
üzenetére
igen, referencia szerinti átadás van, szerintem csak rosszul használtad ezt a "hint" kifejezést. A & jel nem egy "hint" az interpreternek.
-
#14992
modder
aktív tag
Speeedfire
#14991
modder
aktív tag
válasz
Speeedfire
#14991
üzenetére
a copy-on-write memória modell miatt csak akkor kell referenciát használnod, ha paraméterben átadott változón akarsz úgy változtatni, hogy megtartsa az új értékét visszatérés után, csak ezt ugye illik metódus fejkommentjében feltüntetni.
Egyébként el tudom képzelni, hogy jóval hatékonyabb lehet nagy objektumok esetén, mintha visszatérnél:
public function csinalValamitObjektumon($objektum) {
$objektum->adat = 5; // lemasolja az $objektumot
return $objektum;
}
$objektum = new Objektum();
$objektum = csinalValamitObjektumon($objektum);Ennél jobb, ha referenciaként adod át, és nem térsz vissza vele.
http://hengrui-li.blogspot.hu/2011/08/php-copy-on-write-how-php-manages.html -
#14892
modder
aktív tag
rootkiller
#14891
modder
aktív tag
válasz
rootkiller
#14891
üzenetére
Sajnos nem csak a google számára nem sikerült megfogalmaznod a kérdésedet
A polimorfizmus az, amikor a gyerek osztályban felülírod a függvényt, amit az ősosztályban definiáltál, és ezentúl az fog meghívódni gyerekosztály típusú objektumnál.
Amit te leírtál, az függvény túlterhelés (function overloading), ami nincsen a PHP-ban nyelvi elemként. Helyette van hackelős módszer: http://stackoverflow.com/a/4697712/818375A polimorfizmusról pedig: http://stackoverflow.com/a/750309/818375
"Az én esetemben vannak függvények azonos névvel új létrehozásra valamint módosításra" ugyanaz a függvény módosítja és hoz létre újat? Nem túl fasza.
És lehetőleg a $_GET['id']-tól való függést ne az üzleti logika vagy modell részbe tegyed, hanem a controllerbe, ahol ellenőrzöd, hogy egyáltalán megvan-e a $_GET['id'] paraméter
-
#14888
modder
aktív tag
PumpkinSeed
#14887
modder
aktív tag
válasz
PumpkinSeed
#14887
üzenetére
-
modder
aktív tag
válasz
modder
#14885
üzenetére
http://www.php.net/manual/en/mysqli-stmt.bind-param.php
Ezzel a paraméterek escapelve lesznek - ha jól tudom - így ha a $_GET['id'] változód bármit is tartalmaz, védve leszel az sql injection ellen.
Másik előnye, hogy így prepared statementet használsz, amit cache-el az adatbázis kezelő, ezért nem fogja ugyanarra a queryre újra és újra végrehajtani az optimalizációs eljárást, hanem elmenti a végrehajtási tervet. http://stackoverflow.com/questions/12286313/do-sql-bind-parameters-affect-performance
http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php -
#14885
modder
aktív tag
PumpkinSeed
#14884
modder
aktív tag
válasz
PumpkinSeed
#14884
üzenetére
ha az emlékeim nem csalnak, az alábbival megkapod a $query_id-tól kisebb legnagyobb id-val rendelkező, a $query_id, és $query_id-tól nagyobb legkisebb id-val rendelkező képeket.
(SELECT * FROM ( -- ez a kulső select azert kell, hogy novekvobe rendezze
SELECT * FROM kepek WHERE id <= ".$query_id." ORDER BY id DESC LIMIT 2)
ORDER BY id ASC)
UNION
(SELECT * FROM kepek WHERE id > ".$query_id." ORDER BY id ASC LIMIT 1)Ezt azért így kell, mert, ha van öt képed, amiknek az id-ja rendre id = {1,2,3,4,5}, majd kitörlöd a 2-est, akkor azt kapod, hogy id = {1,3,4,5}. Persze azt is megcsinálhatod, hogy kódban végigmész az egész result seten, és kiválasztod a megfelelő rekordokat, de szebb, ha az egészet rábízod az adatbáziskezelőre.
Erről beszélt a kutya is itt [link]Ja, és természetesen használj a attribute binding-ot a mysqli apival, mert rohadtul nem biztonságos a query stringbe behányt get paraméter.
-
#14869
modder
aktív tag
PumpkinSeed
#14868
modder
aktív tag
válasz
PumpkinSeed
#14868
üzenetére
adok egy hintet:
<a href="?elem=<?= $p +1; ?>"><div id="button_next"></div></a>
A <?= -re be fogtok szólni, de én szeretem.
-
#14867
modder
aktív tag
PumpkinSeed
#14863
modder
aktív tag
válasz
PumpkinSeed
#14863
üzenetére
valami olyasmit akartál csinálni, hogy 0-ra lefelé vált, 1-re pedig fölfelé, de "valamiért" nem működik. Jobban járnál, ha az elem query param tényleg a kép sorszámát tárolná.
-
#13184
modder
aktív tag
Speeedfire
#13183
modder
aktív tag
válasz
Speeedfire
#13183
üzenetére
Akkor szerintem elég, ha kicseréled a shop user tábláját egy view-ra, ami a saját user tábládból kérdez le, de a neve megegyezne azzal, amit a shop modul vár. De akkor a módosításokat mindenképpen az eredeti táblán kell elvégezni, mert azt ugye view-n nem lehet.
-
#13182
modder
aktív tag
Speeedfire
#13181
modder
aktív tag
válasz
Speeedfire
#13181
üzenetére
Elég általános megoldást írtam, nem yii specifikus.
Jól értem, hogy nem akarod az egész adatbázist közösen használni, csak a user managementet? Sajnos nem ismerem a yii-t és az extensionjeit, de ha a két rendszer ugyanaz, akkor ugyanazt az adatbázis sémát használják. Így elvileg egyszerűbb megoldani, hogy az egyik webshop másik adatbázishoz kapcsolódjon közvetlenül, és onnan kérje le az adatokat. A gyakorlatban pedig vannak problémák:
1) lehetnek olyan join lekérdezések, ahol egy webshop táblát kapcsolsz össze egy user táblával. Ezt akkor szét kell választani kódban.
2) ha használ tranzakciókezelést, akkor a két adatbázis közötti elosztott tranzakciót inkább felejtsd el, hacsak nincs már erre megoldás yii-ben vagy PHP-ban.Egy rendszert általában egy adatbázisra terveznek. Kétlem, hogy annyira modulárisra csinálták volna ezt a webshopot, hogy egyszerűen le tudd cserélni honnan autentikálja a felhasználókat. Ha igen, akkor szerencséd van
Mindenesetre tényleg nézz utána, hátha ezt már valaki megoldotta, ha nem, akkor kezdd el nézegetni a kódot, hogyan van megoldva a user management, és hol tudnál belenyúlni, melyik réteget tudnád lecserélni úgy, hogy közös user adatbázist használjon.
A user management modullal együtt tud működni
Ha a user management modulnak meg tudod mondani, hogy melyik adatbázishoz kapcsolódjon, az jó. Ez azt is jelenti, hogy a webshop vélhetőleg nem függ adatbázis szinten a user tábláktól, úgyhogy nem lesznek 1)-beli esetek. A probléma viszont még fennáll, hogy a webshop saját user táblája, ahol a postázási címet meg ilyeneket tárol, ugyanazt az adatbázis hozzáférést akarja majd használni, mint a maga a webshop.A legnagyobb problémát szerintem az fogja jelenteni, hogy a webshop modult, mint egy egységet egy adatbáziskapcsolatra tervezték, így kétlem, hogy konfigurálással be tudnád neki állítani, hogy a termékeket a saját adatbázisból szedje, de a webshop user-t egy másikból. (mivel ha jól láttam a képről, a webshop user táblája össze van kötve a yii user táblájával)
-
#13179
modder
aktív tag
Speeedfire
#13176
modder
aktív tag
válasz
Speeedfire
#13176
üzenetére
Kijelölöd az egyik rendszer felhasználói adatbázisát, mint a felhasználói adatbázis, és közösen azt használod mindkét rendszernél.
A másik rendszer authentication&authorization rétegét le kell cserélned, hogy "az adatbázist" használja, ne a sajátját. Ez rendszertől függően lehet egyszerű és bonyolult is, de mindenképpen bele kell nyúlni a kódba, és módosítani kell, hogy amikor a másik rendszer egy felhasználót autentikálni szeretne, azt ne a saját adatbázisból próbálja meg, hanem "az adatbázisból".Többféleképpen lekérdheted a felhasználói adatokat "az adatbázisból":
-- kapcsolódhatsz közvetlenül az adatbázis kiszolgálóhoz
-- csinálhatsz egy service réteget ahhoz a rendszerhez, amelyiknek az adatbázisát használni fogod (SOAP vagy REST), és a másik rendszer ezt hívja minden egyes alkalommal, amikor egy felhasználót be kell jelentkeztetni/regisztrálni.Az előbbi egyszerűbb, szerintem, de ha változik az adatbázis struktúra egy update során, akkor kínos minden rendszer implementációját frissíteni, plusz nehezen megoldott az auditálás.
Az utóbbi azért jó, mert a kód könnyebben, módosítható, mint az adatbázis struktúra, és anélkül lehet az autentikáció implementációját változtatni, hogy a service interfészt megváltoztatnád. (pl. ha az adatbázis struktúrán változtattál). Én ezt választanám egy REST interfésszel. Arra ügyelni kell, hogy a két rendszer közötti kommunikáció SSL-en keresztül menjen.Amit még meg kell említeni, hogy a felhasználó azonosításán kívül valószínűleg be lehet állítani egy csomó más felhasználói preferenciát is a különféle rendszereken. Én ezeket megtartanám rendszerfüggően, az adott rendszer saját adatbázisát. Azon a rendszeren, amelyik nem a saját felhasználói adatbázisát használja autentikációra, a service hívásból visszajött valamilyen user id-hoz kötném ezeket az adatokat.
-
modder
aktív tag
Jótanács: biztosabb kiküldeni egy Content-type headert, mert az leveri a meta tagben szereplő értéket, és felülírhatod vele a szerver által alapból kiküldött értéket, ha van.
http://php.net/manual/en/function.header.php[ Módosította: CoolMan ]
-
modder
aktív tag
válasz
kkdesign
#12223
üzenetére
az biztos hiba volt, amúgy a hibaüzenet elég beszédes, nem árt elolvasni
a session_start() azért írja ki azt, mert az kiküld egy PHPSESSID nevű cookie-t a böngészőnek amivel azonosíítja a felhasználót és a felhasználóhoz tartozó session-t. ha te bármit kiírsz a kimenetre még az előtt, hogy a meghívnád a session_start()-ot, akkor már nem adhatsz hozzá új header-t a php kéréshez, tehát "headers already sent".
megoldás:
session_start() legyen legeslegelső függvény amit meghívsz. (legalábbis bármilyen output előtt). figyelj oda, ha valami hibát generál, a warning vagy error üzenet is output lesz. -
#12194
modder
aktív tag
kaplaranti
#12191
modder
aktív tag
válasz
kaplaranti
#12191
üzenetére
-
modder
aktív tag
Egyébként nagyon magasan van az a léc, ahova a php ne lenne elég. Az, hogy a kód milyen minőségű lesz, elsősorban a fejlesztőn múlik itt is, mint minden más nyelvben.
Ez igaz, és erre mondtam, hogy ha alapvetően egy nyelv szabályokra épül, kevesebb lehetőség van a gányolásra. Érted, ha át akarsz kelni egy szakadékon, sétálhatsz fél kilométert a hídig, vagy átkelhetsz rajta egyenesen, de akkor lehet, hogy eltöröd a lábad.A tömbös példámat rosszul fogalmaztam meg. Nem arra akartam kilyukadni, hogy ha tömböt használsz az nem hatékony, hanem hogy ezzel a megoldással simán elszalad a ló a fejlesztővel, hogy ja, csak dobjunk bele mindent ami kell egy hatalmas tömbbe, mert az milyen egyszerű. Aztán jön a másik fejlesztő, és dolgoznia kell egy ilyen multidimenziós tömbön, és fogja a fejét, hogy vajon mi az isten lehet ebben a tömbben.
Nyilván arra akarok kilyukadni, hogy ha multidimenziós tömb helyett az ember objektumhierarchiát használna ezekre a feladatokra, az sokkal átláthatóbb kódot eredményezne. de hát az olyan nehéz, mert akkor definiálni kell osztályt... meg mi az, hogy egy tömb vagy lista csak egyféle típusú elemekből állhat, fúj
És akkor arról még nem is ejtettem szót, hogy a mai fejlesztőkörnyezetek type hinteket adnak az objektumokra, de a tömb elemekre sosem fognak.A Haskell nem azért működik így, mert funkcionális nyelv, hanem mert típusos nyelv, és azt mondták a kitalálói, hogy ha van módszer arra, hogy megkíméljük a fejlesztőt attól, hogy mindig kiírja a típust, akkor használjuk.
Valamivel ki kell tölteni a helyet abban a könyvben. Remek érv Egyébként nem azért hoztam fel, mert haskellben kell programozni, hanem azért, mert jó, ha az embernek van viszonyítási alapja. Vagy olvassak inkább arról, hogy milyen király php-ban a "magic metódusokkal" megoldott függvény túlterhelés, és egy 20 éves nyelvnél még mindig ilyen tákolmány megoldásokat kell alkalmazni? -
modder
aktív tag
Ne feledd, a szkriptnyelvek alapvetően rövid programok írására lettek kitalálva.
Jajj, erről meg is feledkeztem, most újabb érvet adtál a kezembe
Szóval igen, valóban remek eszköz egy nem gyakorlott ember kezében, hogy a logikára tudjon koncentrálni, és ne a nyelvi megszorításokra. Ezzel nem vitatkozom.A baj az, hogy a nyelv "kinőtte magát". Az emberek már nem kis dinamikus weboldalakra akarják használni, hanem bonyolult funkciókat megvalósító portálokat írnak benne. És akárki akármit mond, minél nagyobb vagy bonyolultabb egy rendszer, annál több szabály szükséges ahhoz, hogy jól működő, olvasható, módosítható kód szülessen benne.
Ha már szóba került a Drupal. Nekem úgy tűnik, hogy nagyon sok energiát fektetnek abba, hogy minél jobb legyen a rendszer, gyorsabb. De van egy csomó hülyeség, amit a PHP megenged (pl. minden lószart hatalmas multidimenziós tömbökben tárolunk végig a program futása során), amik. azt eredményezik, hogy egy drupal oldalletöltés több száz megabyte memóriát igényel.
--Vannak más nyelvek, ahol gyönyörűen meg van oldva, hogy ha létrehozol egy változót, onnantól már nem változtathatsz a típusán, és ki sem kell írni a típusát sehol.
--És melyik ez a nyelv? Vagy most az új C++ auto kulcsszavára gondolsz?
A Haskell-t kezdtem el tanulgatni, és ott ez így működik. Szintén Haskell könyvben taglalják több paragrafuson keresztül, hogy mennyire jó, hogy ha megnézzük egy metódus szignatúráját, abból egyből látszik, hogy mit csinál egy függvény, és nem kell találgatnunk csak a függvény nevére alapozva. -
#12119
modder
aktív tag
Sk8erPeter
#12118
modder
aktív tag
válasz
Sk8erPeter
#12118
üzenetére
Szerintem egyáltalán nem előny, hogy ugyanaz a referencia többféle típusú értéket vehet fel. Sőt egyáltalán az, hogy a függvényeknek nem kötelező megadni a paraméter típusát.
-- Így ha valaki netalántán újra szeretné használni, ha nincsen dokumentálva vagy nem néz bele a kódjába, fingja nem lesz róla, hogy milyen paramétert vár.
-- Másik legnagyobb gáz, hogy sokan többféle visszatérési értéket adnak egy függvénynek.
De nem is akarom részletezni, hogy hányféleképpen rossz ez a típustalanság.Ami előnye (lenne), hogy nem kell mindenhol kiírni a típust, de ez nem feltétlenül jelent dinamikus típusosságot. Vannak más nyelvek, ahol gyönyörűen meg van oldva, hogy ha létrehozol egy változót, onnantól már nem változtathatsz a típusán, és ki sem kell írni a típusát sehol. Azonban fordítási hiba lesz, ha mégis más típusú értéket akarsz adni neki. Ezt hívják type inferencenek.
Pl. php-ban valahogy így nézne ki:
$azEnKecskem = new Kecske();
$mostMarMasKecskeje = $azEnKecskem;
$gyerekKecske = Kecskek.szaporodj($azEnKecskem);
// eddig végig lehet következtetni, hogy mi a változók típusa
// azonban a következő compile errort dobna, ha esetleg
// szeretnénk újra felhasználni egy létező változót
$azEnKecskem = new Auto();Coyot hozzászólására reagálva
-
modder
aktív tag
válasz
pakriksz
#10859
üzenetére
azt hiszem pl. dotcloud mysql adatbázisához hozzá tudsz férni kívülrűl.
Egyébként szerintem nem olyan bonyolult összehozni egy ilyet, amiről beszélsz. egy szimpla REST apival megoldható, pl json-ben adná vissza a sorokat. szerintem még egy több megás result setet is simán vissza lehet adni egyben, miért is ne.Ha nem szimpi egyben visszaadni, akkor szerver oldalon csinálhatsz olyat, hogy a query-d végére fűzöl (a távoli kliens számára transzparens módon) OFFSET x LIMIT y -t, session változóban eltárolod a query-t egy egy referenciával és egy iterációt számláló változóval.
Miután a kliens elküldte a query-t, visszakapja a referencia számot, és erre hivatkozva csak next-next-next-eket küld a proxynak.
A proxy a referencia szám alapján kikeresi a query-t, növeli az iterációs változó értékét, majd ez alapján az érték alapján új offsetet ad az előzőleg letárolt query-nek. Az új offsettel lefuttatja a query-t, majd elküldi a választ.
A kliens a referencia számra hivatkozva a next-next-next... kérésekben visszakapja pl json-ban a választ.Ami itt rettentő fontos, hogy mivel plain SQL lekérdezéseket küldesz a proxynak, legalább a requestet kezdeményező klienst autentikálni kell valahogy. Pl egy egyszerű szimmetrikus kulcsú HMAC algoritmussal aláírni az elküldött SQL query-ket, majd a proxy oldalon ellenőrizni, hogy tényleg a megfelelő kulccsal lett-e aláírva a query. ha igen, akkor futhat, ha nem, akkor hitelesítetlen felhasználó próbálja meg elérni a proxy-t
-
modder
aktív tag
válasz
lakisoft
#10140
üzenetére
Én nem vagyok java ee expert programozó, de most azzal fogok dolgozni jó ideig, és nem hiába nem a PHP-t választottam, pedig ahhoz is értek kicsit.
Sajnos azt nem mondtad el, hogy egyedi fejlesztés lenne, vagy valamilyen ingyenes(nem ingyenes) webshop motort használnál.
Első szempont:
csináld abban, amihez értesz.
Második szempont:
nézd meg a tárhely lehetőségeket. Van egy csomó PHP PaaS cloud alapon. Van javahoz is Google Appengine (most ezzel próbálkozom) vagy Heroku
Harmadik szempont:
fenntarthatóság. Itt nálam egyértelműen a Java nyer. Azért, mert Java EE definiál egy jól körülhatárolt rétegelt architektúrát: adatbázist, perzisztencia réteget, üzleti réteget, kontrollert és megjelenítést. Mindennek megvan a maga helye, nem mosódnak el a határok a kódban a szerepek között.
Java-ban ugyanolyan gyorsan fejlődik a cloud technológia, pl NoSQL adatbázisokhoz API, ezekre épülő perzisztencia réteg, Memcached, 3rd party API-k.PHP-t azért nem választom, mert nem típusos nyelv, ami melegágya a gányolásnak: nem egyértelműen definiált interfészek. Egyébként itt is lehet választani valami MVC frameworkot, amivel lehet nagy volumenű alkalmazásokat gyártani, pl symfony.
Ha esetleg webservice-t kell publikálnod, akkor PHP-ban szenvedni fogsz vele.
ha Business2Business kommunikációt akarsz később, szintén szenvedni fogsz vele.Biztonság: mindkettő olyan biztonságos, amennyi hangsúly fektetsz az impelementációban erre a kérdésre.
Még egy szempont, hogy PHP-ba sokkal könnyebb beletanulni, általában egyszerűbbek a megoldások, de ez szintén melegágya az elk*rvult kódnak, mert ahogy nőnek az igények, nő a komplexitás, és az egyszerű megoldások a későbbiekben gátat szabnak a kód fejlődésének. Javab engem arra ösztönöz, hogy már az elején végiggondoljam, hogy mit hogyan akarok csinálni, és a kiterjeszthetőségre törekszem. Ettől a kód az első lépésekben túl komplexnek tűnhet az igényekhez képest, de később ahogy fejleszteni kell, minden megtérül.
-
modder
aktív tag
válasz
riska1982
#10100
üzenetére
Itt írják, hogy statisztikai alapon készülnek azok a listák, amik segítségével felfedezik az elgépelést, és új kifejezést tudnak helyébe ajánlani. szóval ahhoz, hogy ez jól működjön, egy kicsit programozni is kell, és nem árt a nagy felhasználói aktivitás.
http://stackoverflow.com/questions/307291/how-does-the-google-did-you-mean-algorithm-work/307344#307344Elmondás alapján nem tűnik nehéznek implementálni. Ha viszont a "termékek" amik között keresni akarsz, nem tartalmaznak speckó neveket, akár a google adatbázisát is használhatod erre a célra. Elvileg lehetséges:
http://stackoverflow.com/a/1691335/818375 -
modder
aktív tag
ha még mindig nem megy, próbáld meg a webszerveren állítani az output buffert
pl Apachenál SendBufferSize 0Amúgy ha apache modulként van fönt a PHP, el tudom képzelni, hogy automatikusan flusholja az apache output bufferét is. (nálam működött ez annó). Ha nem apacheot használsz vagy fastcgi van, akkor lehet, hogy nem ilyen egyszerű a helyzet. mindenképpen nézz utána a webszerver output bufferének is.
(sőt, akár még a böngésző is bufferelhetni, azt mondják
) -
modder
aktív tag
válasz
Siriusb
#9746
üzenetére
IP címre soha nem szabad hagyatkozni egyediségvizsgálatnál: dinamikus ip cím, nat.
Csak most kapcsolódtam be, de egy egyszerű, bárki számára elérhető anonim szavazásnál tényleg simán elég egy cookie. Az emberek nem törlik minden percben a cookie-kat, persze aki rosszindulatúan szeretné módosítani a szavazást, annak így is megvan a lehetősége.
Ha mindenképpen ki akarod kényszeríteni az egyedi szavazást, akkor elengedhetetlen a regisztráció.
-
modder
aktív tag
Háttő
Én most hirtelen kétfélé többnyelvűséget tudok megkülönböztetni:
1) Az oldalon megjelenő statikus szövegek: navigáció, regisztráció, miegyéb. Itt általában olyan megoldás van (azt hiszem ilyen a Zend i18n modul is), hogy megadsz egy nyelvi fájlt, aminek minden sorában van egy angol szöveg - másnyelvű szöveg pár. Visszaadhat akár tömböt is (Kohana pl. ezt csinálja)return array(
'Welcome :user' => 'Isten hozott :user'
)majd kódban a szövegeket speciális függvénnyel íratod ki, ami éppen aktuális nyelvi beállításoknak megfelelő nyelven írja ki a szöveget:
echo __('Welcome :user' , array(':user' => 'Laci'));
2) Dinamikus szövegek: blogpostok, cikkek, amiket adatbázisban tárolsz. Ez a bonyolultabb téma. Azért is, mert egy adatbázis rekord nem csak szövegeket, hanem számokat, kapcsolatokat is tárolhat, amit nem akarsz redundánsan tárolni a többnyelvűség miatt. Ezek a megközelítések jutnak eszembe:
a) van egy entitás táblád, és van több entitás_nyelv táblád. Az entitás táblába beleteszed a nyelvfüggetlen adatokat:
mikor készült a cikk, ki a szerzője, mikor módosították, milyen kategória...Az entitás_nyelv táblába pedig beleteszel egy kapcsolatot az entitás táblára, és a nyelvfüggő dolgokat ebbe teszed: maga a cikk szövege, cím
szerintem ez elég tiszta megoldásb) ugyanabban a táblában tárolod egy entitás minden fordítására vonatkozó adatot, és beteszel egy nyelv mezőt. Ez azért jó, mert nem kell a kapcsolatokkal foglalkozni, viszont a nyelvfüggetlen adatokat valszeg redundánsan tárolod, és konzisztensen kell tartani, amikor valami frissül
c) brutálisan általános és lassú megoldás, de cachelhető kódból, ezt már egyszer megcsináltam
Van egy nyelv táblám, aminek mezői [ id, nyelv, tablanev, tablamezo, tablaPK , szoveg ]
gondolom ebből látszik, hogy mire megy ki a játék. Az összes entitásom összes szöveges mezőjét az összes nyelvre egy rekordként tárolom. Működő megoldás, nagyon dinamikus, nem kell meglévő adatbázisstruktúrát megváltoztatni, és ha cachelsz szöveget pl. APC-be, akkor még elfogadható sebességű is lehet. Ha nem cachelsz, akkor viszont túl sok adatbázis lekérdezés. -
#9109
modder
aktív tag
Speeedfire
#9108
modder
aktív tag
válasz
Speeedfire
#9108
üzenetére
Na itt egy érdekes "probléma", aki elég bátor az megválaszolhatja, hogy ez-e az elvárható működés vagy sem
-
modder
aktív tag
felteszed az új kódot?
Én még mindig próbálom megfejteni, hogy mi volt a probléma a te megoldásoddal.$this->fb = new Facebook(array("appId" => APP_ID, "secret" => APP_SECRET, "cookie" => true));
$fb = $this->fb;
if($user_id = $fb->getUser()) {
// get user data
} else {
// redirect
}Abba az if ágba nem lép bele annak ellenére, hogy már engedélyezte a user az alkalmazást, így a getUser()-nek vissza kéne adnia egy id-t. Az előző formodon újra a facebook gombra kattintva már nem kellett volna redirectelnie fészbuk login oldalra, de ahogy láttam tegnap éjjel, mégis megtette...
-
modder
aktív tag
akkor azt a kódot is feltölthetnéd, ahonnan meghívod a get_user() függvényed, mivel a regisztráció tökéletesen megy nekem (jajj, tudod az e-mail címem
) . Újra a facebookra kattintva már nem kéri, hogy engedélyezzem az alkalmazást, úgyhogy gyanítom valami a controlleredben van elszúrva. -
#9080
modder
aktív tag
Speeedfire
#9077
modder
aktív tag
válasz
Speeedfire
#9077
üzenetére
Jól van, igazatok van. akkor MINDENT félreértettem %%%ÖTÖT
-
#9076
modder
aktív tag
Sk8erPeter
#9070
modder
aktív tag
válasz
Sk8erPeter
#9070
üzenetére
Jól van
én csak azon kaptam fel a vizet hirtelen, hogy nem értettem, miért kell egy egyszerű kérdésből jQuery hypeot generálni. De valszeg nem kellett volna beleszólnom, főleg, hogy az illetékes észre sem vette -
#9069
modder
aktív tag
Sk8erPeter
#9066
modder
aktív tag
válasz
Sk8erPeter
#9066
üzenetére
Csak azért tettem ilyen éles megjegyzést, mert nem tartom helyénvalónak, ha valaki egy kezdő kérdéssel jön, még fel is mutat valami elvben működő kódot, akkor egyből le kéne hurrogni azért, mert nem úgy csinálta, ahogy valaki más elképzelte.
Csinálja úgy ahogy tudja, ahogy működik, nem árt, ha így is meg tudja valósítani amit akar. Majd idővel ahogy fejlődik, rájön, hogy másképpen egyszerűbb, jobb.
-
#9065
modder
aktív tag
Sk8erPeter
#9063
modder
aktív tag
válasz
Sk8erPeter
#9063
üzenetére
Miért nem mondjátok ki egyenesen, hogy ő egy f*szfej, mert plain javascriptet használt olyan dologhoz, amit egyébként éppen most tanul
-
modder
aktív tag
-
modder
aktív tag
válasz
PazsitZ
#9017
üzenetére
Ha látnátok a fától az erdőt, akkor észrevennétek, hogy Sk8erPeter teljesítménybeli kérdésére próbáltam választ adni az utolsó bekezdésben, csak ehhez elő kellett venni a régi nyelv alap problémáit a kivételekkel, hogy össze lehessen hasonlítani.
De igazad van, vagy várjál csak, ja nincs! -
#9016
modder
aktív tag
Speeedfire
#9015
modder
aktív tag
válasz
Speeedfire
#9015
üzenetére
name és value attributumát megkapod php-ban
-
#9014
modder
aktív tag
Sk8erPeter
#9009
modder
aktív tag
válasz
Sk8erPeter
#9009
üzenetére
Nem akartam amellett kardoskodni, hogy kb soha nem szabad Exceptionöket használni, csak nem érdemes első megoldásként gondolni rá. Mindig nagyban függ a problémától, lehet, hogy nagyobb cégeknél, pl. IBM erről vannak infók. Én úgy érzem, hogy nem szívesen fordulok Exceptionökhöz, mégha kényelmesnek is tűnik a használata.
Erről lehetne akár cikket is írni, hogy hogyan lehet bizonyos eseteket simán return valuekkal vagy exceptionokkel megoldani, és összehasonlítani.
Két nagy probéma van az exceptionökkel:
C++-ban azért okoz teljesítméncsökkenést, mert az Exception-t a stacken hozza létre, és dobásnál ahogy visszatér az összes függvényből, mindig a stack tetejére kell másolnia az exception objektumot, ha a catch 5 fv-nyel föntebb van, akkor az 5 másolás.
A másik probléma pedig hogy ha például nyitunk egy resource-t pl file handlert, de dobunk egy exception-t, akkor hajlamosak vagyunk erről megfeledkezni, és nyitva marad.
Az előbbi szerintem PHP-ra már nem igaz, mert amúgy minden adatstruktúrának megvan a C-beli reprezentációja (plusz absztrakció), egyébként pedig valszeg minden heap-en van tárolva.
utóbbi pedig akár lehet igaz is. -
#9007
modder
aktív tag
Sk8erPeter
#9006
modder
aktív tag
válasz
Sk8erPeter
#9006
üzenetére
A symfony error handlingről beszélt, ami tipikus hiba eset (értsd: ha hiba történik, amire egyáltalán nem számítottál, exception, ugyanez a Kohana is, ezért van stacktrace, amikor valamit elszúrok), nem arról, hogy a mindennapi funkcionalitást exceptionökre építed.
A 404-es hiba exceptionnel történő kezelése pedig nem ördögtől való, mint azt korábban írtam: mindegy. Viszont ez architektúrális szinten jelenik meg, ezért van létjogosultsága.
Mondtam, nehéz eldönteni mi az amit lehet/szabad/érdemes exceptionokkel csinálni és mi az, amit nem. A validálás olyan, amit én nem exceptiönökkel csinálnék. Alternatívát a 404-re pedig írtam.
-
#9005
modder
aktív tag
Sk8erPeter
#9004
modder
aktív tag
válasz
Sk8erPeter
#9004
üzenetére
én inkább így közelíteném meg:
function blabla(){
// .......
$errorArray = array();
if( $hiba_van ){
$errorArray[] = 'ezért meg azért';
return $errorArray;
}
return empty($errorArray) ? true : $errorArray ;
// .......
}Az exceptiondobálós példával van még egy gubanc: ha minden egyes alkalommal, amikor hibát találsz a validációban, dobsz egy kivételt, akkor ki fogod hagyni az utána következő formelemek validálását, és nem fogod tudni, van-e több hiba is.
Ha pedig minden formelemen végigmész, összegyűjtöd a hibákat, és utána dobsz egy exception-t, benne például egy tömbbel a hibákról, akkor már nem nagyon látom annyira egyszerűbbnek a hibakezelést.
-
#9001
modder
aktív tag
Sk8erPeter
#9000
modder
aktív tag
válasz
Sk8erPeter
#9000
üzenetére
Megadják a lehetőséget
-
#8999
modder
aktív tag
Sk8erPeter
#8997
modder
aktív tag
válasz
Sk8erPeter
#8997
üzenetére
Most már nem fogok mindenre reagálni, leírtam az érveimet. Felőlem mindenki olyan esetekben dobál exception-t a kódjában, ahol akar.
Csak egy pár dolog:
Azt hiszem érthető voltam, de akkor leírom érthetőbben: amikor refaktorálod (átírod, javítod) a kódot, nem fogod tudni, hol dobtad az exceptiönt, amíg tényleg nem dobtál egyet.
Például van a form validáló osztályod, ami dobhat 4féle exception-t, te meg szeretnéd tudni, hol dobja, akkor legjobb esetben is ctrl+ffel keresel rá. Ha pedig a stacktrace-t akarod használni, ahhoz generálnod kell egy olyan hibát, ami ezt az exceptiont dobja.Aztán kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Nyilván, ha valaki idiótán programoz, arra nincsen mentség.Aki pedig azt állatja, hogy minden függvényt azzal kezd, hogy /** */, az biztos ráér programozni
-
modder
aktív tag
válasz
PazsitZ
#8996
üzenetére
PHP-ban valszeg nem olyan költséges, mint pl. c++-ban.
Ne értsetek félre, jó dolog az exception olyan hibák kezelésében, amik tényleg az elvárt futástól különböző esetekre vannak.
Ezen kívül azonban, amikor a program funkcionalitásába belekalkulált dolgokról van szó, mint például: S8erPeter-nek volt egy form validálós, feldolgozós példája, ahol hiba esetén kivételt dob, illetve a fentebb tárgyalt esetben, hogy nem talál egy oldalt, akkor exception-t dobjon, amikor az egy belekalkulált működés, szerintem; az exception számomra egy kerülő megoldás, ahol ide-oda ugrálunk a kódban.
Itt tulajdonképpen arról van szó, hogy milyen 'hiba' vagy kivételes eset fordulhat elő többször, amire számítani kell, és mi a valódi hiba (ez utóbbi esetben érdemes kivételt használni). Nem láttam még olyan keretrendszert, ami kivételdobásokra alapozta volna a működését.Nekem ez az álláspontom. Nem éles a határ, hogy mikor érdemes kivételeket használni, nem egyértelmű eldönteni, de én ott például, ahol user input validálást csinálok, számítok rá, hogy rossz lesz az input, és nem fogok kivételeket dobálni rossz inputra.
Egyébként meg mindenki úgy programoz, ahogy akar.
...A dokumentálás meg egyáltalán nem alap, gyors fejlesztési ütemben pedig mindig elmarad, de aki megtanul tiszta kódot írni, az a többi fejlesztő munkáját megkönnyíti.
-
#8995
modder
aktív tag
Sk8erPeter
#8994
modder
aktív tag
válasz
Sk8erPeter
#8994
üzenetére
Én csak ezzel nem értek egyet:
a kivételkezelés akkor is ezerszer átláthatóbb hibakezelési formaKivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod.
Vissza a fenti mondathoz. Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed.
Még egy dolog.
Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud.Ezt a Dependency Injectionhöz tudom hasonlítani. Ott arról van szó, hogy bizonyos műveleteknek vannak előfeltételei, előfeltétel objektumai, és addig átlátható, amíg a függvények bemenetein megjelennek ezek az előfeltételek, mert addig nyomonkövethető a kdóban az előfeltétel.
Egy szó, mint száz. Nem érdemes általános gyakorlattá tenni a kivételek dobálását. Form validálásnál még talán elmegy. De ezt is lehet hit kérdéssé tenni, nem muszáj rám hallgatni
-
modder
aktív tag
szerintem ez, hogy kivételt dobsz, vagy hogy kezeled le azt, ha nem talál a keretrendszered egy oldalt, az rajtad múlik. Általában ugye úgy működik egy mvc architektúrájú keretrendszer, hogy megkeresi az url vagy route alapján ráillő kontrollert.
Lehet az, hogy nincs meg a kontroller vagy nincs meg a kontroller által kiszolgálandó erőforrás, például cikk, termék.
Ha nem találja a kontrollert vagy az adott oldalt, cikket, akármit, amit beírt a felhasználó az url-be, akkor akár helyben is -- ott ahol kiderült, hogy nincsen sehol a kérdéses erőforrás -- küldhetsz az outputra egy 404-et, majd "szép leállást" produkálsz pl. zárod a logokat. Erre csinálhatsz egy függvényt vagy beleraod a response osztályodba, és hívsz egy iylet, hogy $this->response->out_404();
Így meg mindegy, hogy exception-t dobsz-e vagy helyben egy függvényen belül kezeled-e le a dolgokat, mert hiba esetén meghívni egy exception-t vagy egy függvényt ugyanannyi kódolás minden esetben, bár utóbbinál legalább nem operálsz exceptionökkel.
-
modder
aktív tag
válasz
spammer
#8977
üzenetére
szerintem is, kukis az biztos működni fog, és viszonylag egyszerű is, ha csak cikkszámok listájáról van szó. esetleg megnézhetsz valami LocalStorage dolgot (keress rá). ez asszem ilyen HTML5-ös szabvány.
Ha nincs DB, még a cikkszámra kattintva akár egy AJAX-os megoldással (hogy ne töltődjön újra az oldal) session változóba is mentheted a cikkszámokat.
-
#8970
modder
aktív tag
Sk8erPeter
#8969
modder
aktív tag
válasz
Sk8erPeter
#8969
üzenetére
Ó, ezt nem tudtam. Köszönöm a kiegészítést!
-
modder
aktív tag
A paginálás nem egyszerű dolog. Gyakorlatilag kell egy olyan osztály, ami képes egy k : [1,n] (ahol k az oldal száma) egész számot leképezni az adatbázis által visszaadott rekordok intervallumaira.
page 1 -> mysql sorok(0,10)
page 2 -> mysql sorok(11, 20)
...Itt a mysql lekérdezésben a LIMIT és az OFFSET-tel szoktak operálni (MySQL-ben), vagy ha az adatbázis interfészed tud ilyen funkcionalitást megvalósító fv-eket, akkor azzal.
kb ez úgy néz ki, hogy ha tudod, hogy 1 oldalon 30 elemet akarsz megjeleníteni, akkor osztályod úgy készíti el az adatbázis lekérdezést az elemeidre, amiket meg akarsz jeleníteni, hogy:
$sql .= ' ORDER BY ido DESC LIMIT 30 OFFSET ' . $page * 30 . ';';
van nagyon sok működő megoldás neten, csak keresgélj.
-
#8961
modder
aktív tag
Peter Kiss
#8959
modder
aktív tag
válasz
Peter Kiss
#8959
üzenetére
jajj
el lehet játszani ilyenekkel, de ugyanehhez a funkcionalitáshoz elég csak egy __call() fv-t használni -
#8958
modder
aktív tag
Sk8erPeter
#8956
modder
aktív tag
válasz
Sk8erPeter
#8956
üzenetére
ez esetben csak vicceltem!
![;]](//cdn.rios.hu/dl/s/v1.gif)
amúgy én lehet, hogy "picsahülye vagyok az egészhez", de valamelyik programnyelvben akkor is hibát dobott a példakódra
(C vagy Java talán vagy mind2) -
#8955
modder
aktív tag
Sk8erPeter
#8954
modder
aktív tag
válasz
Sk8erPeter
#8954
üzenetére
nem beszélve arról, hogy emlékeim szerint le sem fordul így
isset($_POST['hirlevel']) ? $hirlevel = 'igen' : $hirlevel = 'nem';(talán lehet vele trükközni, hogy kapcsos zárójelbe teszed, de lehet, hogy akkor is kell az egyes ágaknak visszatérési érték)
-
#8948
modder
aktív tag
Speeedfire
#8947
modder
aktív tag
válasz
Speeedfire
#8947
üzenetére
Beállította magának, hogy update lesz? Te lehet, hogy jobban vágod a YII működését, de nem hiszem, hogy intuíció alapján csinál dolgokat
Szerintem ha újat akarsz hozzáadni, minden iterációban példányosíts egy új Items-t.
(Én Kohanával dolgoztam, és ott úgy van az ORM modell, hogy egy példány<-->egy rekord az adatbázisban, persze komplexebb modelleknél, ahol több táblába akarsz egyszerre menteni meg blabla, felül lehet definiálni a működést, de alapból így van)
-
#8946
modder
aktív tag
Speeedfire
#8941
modder
aktív tag
válasz
Speeedfire
#8941
üzenetére
úgy tűnik, yii-t használsz, úgyhogy elég speckó a kérdésed. én azzal még nem foglalkoztam. kéne tudni, hogy működik az new Items nevű modelled.
Ami amúgy egyből feltűnik a fileHandler függvényedben, hogy itt
$model->name = $fullImgName;
$model->size = $instance->size;
$model->type = $type;ugyanarra az objektumra állítod be mindig az értékeket, és utána elmented. Ha ez egy ORM-es cucc, akkor az első mentés után generál egy id-t a PRIMARY KEY-hez, majd ugyanazt a rekordot módosítja újra és újra minden iterációban. (Nem tudom, mi az az $instance, meg ezek, de nem látom, hogy a modellben lenne valami belső léptetés az új elemeknek).
Remélem elég sugallatot adtam
-
modder
aktív tag
ez számtalan helyen elromolhat. kezdve attól, hogy nem jó a javascript XMLHTTPRequest küldés, nem jó a feldolgozó php (bár ezt kétlem), nem jól nyered ki a requestből az adatot.
Szóval lehetnél specifikusabb, hogy mi nem jó.
Egybként ami feltűnik, hogy relatív útvonalat használsz az XMLHttpRequestben, a HTML fájlod pedig a html mappában van, tehát a request az a hostnev/html/apn.php -ra fog irányulni, első meglátásra.
tegyél az url elé egy per jelet, hogy a hostod gyökerétől mérje az url útvonalát: "/apn.php?blabla"
Azt pedig, hogy hogy kell a problémát megkeresni, hagy ne kelljen elmondani
mind chrome-ból vagy firefoxból nyomon tudod követni a javascripted futását, és kiírja a hibákat, érdemes nézni a böngészőből a request-responseokat is, mert ott látod, hogy egyáltalán elment-e a kérés és milyen válasz jött rá -
modder
aktív tag
Hála a jó istennek
Annyit kell csinálnod, hgoy a formba teszel egy hidden mezőt aminek a neve pl. fav_id, értéke értelemszerűen a favoritod id-ja.
Amikor pedig megnézed, hogy van-e del vagy add, akkor azt is megvizsgálod a ciklusban, hogy a fav_id megegyezik-e az aktuális iterációban vizsgált favoritoddal.Egyébként nem is értem, hogy ez a hiba nálad miért nem jelentkezett. Gondolom volt egyetlen favoritod, és örültél, hogy arra megy
-
modder
aktív tag
Lehet, hogy én vagyok a figyelmetlen, és nem veszek észre valamit a kódban, amiből kiderülhetne az, amire kíváncsi vagyok.
menjünk sorba:index.php:
1) végigiterálsz az adatbázisból szedett favoritokon, mindegyikhez tartozik egy session változó, aminek az értéke true vagy false OK
1.1) kiíratod mindegyik favorithoz, hogy
"<form action='' method='post'>
<input class='fav_false' type='submit' name='add' value=' ' />" . " " . $row['item_name'] . "
</form>
...illetve a del párjátattól függően, hogy a sessionváltozóban true vagy false van-e OK
1.2) mindegyik favoritnál megnézed, hogy $_POST['add'] vagy $_POST['del'] kérés jött-e a fönti formból. NEM OK --> Honnan látod szerver oldalon, hogy az add vagy a del melyik favorit elemre vonatkozik? Hogy jobban megértsd, és nekem is választ tudj adni a kérdésemre, elmondom, hogy szerintem a következőképpen működik az index.php: add vagy del változó megjelenése esetén az összes favorit elemre beállítja a true-t vagy false-t. -
modder
aktív tag
Itt kiraksz egy formot, de magában a formban egy darab azonosítót nem rejtesz el (mondjuk egy hidden inputtal, vagy másképp), így nem tudom, honnan szeded, hogy mondjuk épp az 5-ös azonosítójút szeretném eltárolni a kedvencek közé.
De ebből még mindig nem tudod szerver oldalon, hogy melyik form lett elküldve, melyik azonosítójú elemet akarod betenni favoritba. Az eddigi kódrészletek alapján így néz ki
//pszeudo
for( $row in $rows){
if( $_POST['add'])
$_SESSION['fav_' . $row['id']] = 'true';
}mivel nincsen semmilyen más favorit azonosító, amit elküldesz a formból a szervernek, nem tudom, honnan kéne tudni szerver oldalon, hogy arra az egy bizonyos favorit elemre vonatkozik a hozzáadás
-
#8905
modder
aktív tag
Speeedfire
#8904
modder
aktív tag
válasz
Speeedfire
#8904
üzenetére
akkor gondold át
-
#8903
modder
aktív tag
Speeedfire
#8902
modder
aktív tag
válasz
Speeedfire
#8902
üzenetére
nem ott szeretted volna!
Gondolom tisztában vagy vele, hogy amikor a modelledhez hozzáadod a napot, a belső ciklusnak csak az utolsó iterációja fog megjelenni a $nap változóban -
modder
aktív tag
ezt a kérdést pontosabban is megfogalmazhattad volna, főleg stackoverflow-on
Mit jelent a jó és mit jelent a rossz bemenet?
Egyébként a modelledben a keresés csak akkor fog false-szal visszatérni, ha hiba van az adatbázis lekérdezésben (nem éred el az adatbázist, vagy szintaktikailag helytelen lesz a generált sql)
De ezek csak tippek, számomra nem nyilvánvaló a kérdés
-
#8899
modder
aktív tag
Speeedfire
#8898
modder
aktív tag
válasz
Speeedfire
#8898
üzenetére
Nem tudom pontosan, mit akarsz (nem olvastam vissza
), de nem hiszem, hogy a $nap-ot a 2. for-cikluson belül akartad deklarálni -
#8893
modder
aktív tag
Peter Kiss
#8892
modder
aktív tag
válasz
Peter Kiss
#8892
üzenetére
Ez érdekes. Az első kommentből kiderül, hogy elvileg ezt már javították, ezek szerint semmilyen célt nem szolgált, csak így lett megvalósítva.
Érdekesebb a PHP copy-on-write technikája, amit már olvastam valahol, de később, amikor rá akartam keresni (a pontos kifejezés hiányában) nem találtam semmilyen információt róla. Még arra sem emlékszem, hogy meg lenne-e említve a PHP doksi referenciák fejezetében.
Ez a kitekintés arra volt jó, hogy feliratkoztam a php-internals listára, mert amúgy is érdekel a belső működése
-
modder
aktív tag
nem akarok trollkodni, de akkor vedd el addig a jogokat, amíg még működik, és akkor kiderül, hogy melyik jog kell neki. meg ellenőrizd, hogy tényleg arra az adatbázisra adtál-e jogokat, amit használni akarsz vele. van ilyen pl., hogy SHOW DATABASES jog, nem árt, ha ki tudod listázni az adatbázisokat, hogy kiválaszthasd a sajátod.
-
modder
aktív tag
Az a baj még a "szeretnék megtanulni programozni" kérdésekkel, hogy sokan elfelejtik, hogy a programozás nem csak arról szól, hogy kódolok, és akkor ha elég sokat kódolok, akkor készen lesz és jó lesz. Ahogy a kovács szakma sem csak arról szól, hogy ütöm a forró vasat, és akkor jó lesz.
Nagyon sok munkát kell fektetni abba, -- amit már az előző hozzászólásomban meglebegtettem -- hogy jól meg tudd tervezni a kódod, és algoritmus érzék kell hozzá. Ezeket lehet fejleszteni. Ha két részre osztanám a programozói tudást: szintaxis+könyvtárak és tervezés+algoritmus, akkor a tanulásba beleölt idő nagy részét utóbbi kettő fogja kitenni. -- véleményem szerint
[szerk.]
és persze törekedni kell arra, hogy a források után angolul kutatunk, hiszen magyarul csak limitált forrás elérhető, főleg az újabb technológiákból. -
modder
aktív tag
Általában egyetértek azzal, hogy "a PHP szorosan összekapcsolódik a gányolással", a tipikus Pistike (elnézést a Pistikéktől
) megtanul PHP-ban programozni, és honlapokat "fejleszt".Azonban ma már nem csak arról szól a webprogramozás, hogy PHP+Apache+MySQL, hanem REST API-k, különböző szintű cache-k, elosztott adatbázisok (pl. MongoDB), AJAX, PUSH notification, cloud storage-ek (Amazon S3), OR mapping.
Vannak szofisztikált PHP mvc frameworkok (Kohana, amivel most én dolgozgatok).Ezek használata elég sok tervezést igényel architektúrális szinten, és ma az újragondolt OO-val a PHP teljesen alkalmas egy komplex rendszer létrehozására. Lásd, Doclernél még mindig PHP-ban írják a backend nagy részét, és sok nagyvállalatnál is.
A kérdés nem az, hogy PHP vagy Java EE vagy C#, hanem az, hogy képes vagy-e elsajátítani azt a készséget, hogy megfelelően megtervezd az alkalmazásod, és fegyelmezett, jól körülhatárolt szerepkörökkel rendelkező moduláris kódot alkoss. Ehhez bizony sokat kell kódolni, más kódját, tervezési mintákat, architektúrális mintákat kell tanulmányozni.
Aztán ha elhiteted állásinterjún, hogy te bizony értesz mindezekhez, és tényleg értesz, akkor nem leszel alulfizetve, és vezető fejlesztő leszel
Egyébként én is már jó ideje Java EE felé kacsintgatok, mert nagyon kényelmes és kifinomult megoldások vannak már benne specifikáció szinten. pl. JSF, EJB-k, JPA.
-
#7981
modder
aktív tag
Sk8erPeter
#7980
modder
aktív tag
válasz
Sk8erPeter
#7980
üzenetére
de igen: curl http://domain/drupalinstall/cron.php ^^
ezt told be ütemezőbe. vagy akár egy wget. -
#6944
modder
aktív tag
Speeedfire
#6942
modder
aktív tag
válasz
Speeedfire
#6942
üzenetére
Helló,
Nem mindegy, hogy milyen fordítású apache van fönt. Amennyit én tudok, a prefork verzió childprocesseket hoz létre, amíg a worker verzió szálakat.
Olvasd el ezt: http://httpd.apache.org/docs/2.0/mpm.html
Ha prefork verzió van fönt, a MaxSpareThreads nem játszik.Itt van a prefork által elfogadott paraméterek: http://httpd.apache.org/docs/2.0/mod/prefork.html
Nem tudom milyen megfontolásból tetted a routerre, ha otthon baszkódsz vele és kíváncsiságból, akkor nem gond, de azért vállalati környezetben ne csinálj ilyet
Még eljátszogathatsz az apache process nice érékével is, hogy ha hálózati forgalom szempontjából a router keményen igénybe van véve, az oldallekérdezések ne fogják vissza, de az is lehet, hogy erre nincsen szükség.
Nem vagyok egy nagy apache guru, de megpróbálkozhatsz olyannal is, hogy ne töltsön be modulokat, amik nem kellenek, pl. ssl.
-
modder
aktív tag
válasz
#34784256
#1725
üzenetére
hát igen, ez nem éppen php-s kérdés volt. de aki webfejlesztéssel foglalkozik előbb-utóbb -főleg manapság amikor már minden böngésző jól ismeri a javascriptet- szembe tallja magát olyan feladatokkal amihez elengedhetetlen a javascript használata, ennélfogva meg kell tanulni egy erős alapszintű javascript programozást (scriptelést) amire már lehet alapozni.
De a különböző böngészők kezelésére is van megoldás, például még html szinten van valami hasonló tag, hogy <if IE></if IE> az e között levő kód csak akkor hívódik meg, ha a böngésző Internet Explorer, és e közé lehet írni az IE alá szánt javascript kódot.
-
modder
aktív tag
Tuladjonképpen a cikkben amit már belinkeltem:
http://www.devshed.com/c/a/PHP/Socket-Programming-With-PHP/pont php-val old meg egy "kis saját webszervert"
socketet használ, és beteszi loopba az egészet. shell-ből meghívja, azt csá
ott figyel örökké, és válaszol ha kell. Nyilvánvalóan egy szerver applikációhoz nem php a megfelelő megoldás, de amíg nem több száz felhasználót kell egyszerre kiszolgálni, addig ez is tökéletesen megteszi, és annyit gyorsít a dolgon, hogy nem veszi igénybe a webszervert + nem fog minden egyes alkalommal lefordulni, hanem miután elundul megy.Kipróbálnám ezt a megoldást szívesen, de egy mezei webhosting szolgáltató nem fogja engedni hogy futtassak egy ilyet nem virtuális szerver környezetben, úgyhogy marad a sima php script ami minden egyes alkalommal meghívásra kerül.
-
modder
aktív tag
válasz
#34784256
#1722
üzenetére
Erre írsz egy egyszerű javascriptet.
Az ablak x és y koordinátáinak, méretének stb. meghatározásához megkeresed google-n a megfelelő függvényeket.
majd ahová a linket szeretnéd elhelyezni írsz egy:<script language="javascript">
x = this.function_of_x_whatever();
y = this.function_of_y_whatever();document.write("<a href=\"proba.php?x=" + x + "&y=" + y);
</script>
nem nagyon értek javascripthez, de egy hasonló kódnak ez lesz a hatása.
(ez elég bizalomgerjesztően hagnzott, kb: el se olvasd a hozzászólásom )arra vigyázz, hogy a javascript write függvényben NE legyen sortörés csak \n karakter.
Ezzel nagyon sokat szívtam.MOD:
Talán szebb megoldás, hogy a html kódba simán beírod, hogy <a href=# onclick="uj_php_oldal()">Blabla</a>
és a html kód <head> közé írod be a javascript kódot ami tartalmazza az uj_php_oldal() függvényt ami meghívja az új oldalt stb.
-
modder
aktív tag
Köszi a választ.
Igen, elég kicsi az adatmennyiség tulajdonképpen csak maximum pár száz karakter kérésenként. A hangsúl itt inkább azon van, hogy 1 ilyen oldal másodpercenként produkálhat kb 20-30 a szerver felé ami átmegy apache>php>mysql mindenen.
Ezért jutott eszembe, hogy levehetném a fölösleges terhelést apache-ról, ha írnék egy állandóan futó scriptet, amit a legutóbbi hozzászólásomban írtam. Bár ezt nehezebben veszi be a webhosting szolgáltatóDe ha állításod szerint ez a 20-30 kérés még nem olyan sok másodpercenéknt, akkor lehet maradok a "hagyományos" 1script futás/kérésnél.
-
modder
aktív tag
találtam egy nagyon jó cikket: http://www.devshed.com/c/a/PHP/Socket-Programming-With-PHP/
szerintem ez alapján fogok csinláni php-ben egy kis szervert ami kezeli az egészet, így nem fogja fölöslegesen terhelni a webszervert szerver oldalon.
mivel kliens oldalon csak javascript áll rendelkezésemre és abban (e szerint itt: http://bytes.com/forum/thread533816.html ) nincs socket handling ezért marad a kb másodpercenkénti kérés a szerver felé.
Az előző kérdésemre a webhosting szolgáltatóval kapcsolatban azért még várok válaszokat =)
-
modder
aktív tag
Heló,
Kell csinálnom AJAX technikával egy "chat" vagy üzenőfal progit egy site-ra.
Ez csak a legalapabb funkciókat fogja tartalmazni, tehát 1 "szoba" lesz ahová mindenki írhat.mielőtt a kérdésre térnék leírom én hogyan képzeltem el:
Kliens
a kliens az oldalon először beírja nicknevét, e-mail címét, utána chatelhet.
a kliens oldalon a javascript kód <= 1 másodpercenként kérést intéz a szerver felé, hogy jött-e új üzenet, ha jött, a szerver (php progi) küldi az eltelt idő alatt érkezett üzeneteketSzerver
Itt egy adatbázis memory vagy innodb táblában tárolom az üzeneteket, esetleg másik táblába vagy fájlba loggolom bizonyos időközönként. A kliens kérésére a legutóbbi üzeneteket elküldöm neki.Az egész procedúra miértjét/hogyanját még kitalálom, nem árt a gyakorlás, meg úgyis van csomó kód amit leszedhetek a netről.
A kérdés: Tehát az előbbiek szerint a kliens <=1 másodpercenként kérést intéz a szerver felé. Na most ha pl 20 ember chatel akkor ez mennyire terheli meg a szervert? Illetve webhosting szolgáltató hogy értékeli az ilyet, például alapból limitálva van a processzor időm és belassulhat az egész site emiatt? Ez a fő kérdés
Esetleg ti hogyan oldanátok meg? Most még az jutott eszembe, hogy ha valaki küld új üzenetet akkor és csak akkor a script kiküldené az összes aktív kliensnek, na de hogy oldom meg, hogy apache csak úgy küldjön adatot kérés nélkül a klienseknek... Ezek meg a "mellék kérdések"
Köszi a válaszokat
))))))))))))))))))))))))))))))))))
) . Újra a facebookra kattintva már nem kéri, hogy engedélyezzem az alkalmazást, úgyhogy gyanítom valami a controlleredben van elszúrva.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), de nem hiszem, hogy a $nap-ot a 2. for-cikluson belül akartad deklarálni
Új hozzászólás Aktív témák
Hirdetés
- Autós topik
- Milyen TV-t vegyek?
- Akciófigyelő: Jelentősen olcsóbban nyit az Ulefone új mindenese
- Xiaomi Pad 5 - hatásos érkezés
- btz: Internet fejlesztés országosan!
- Formula-1
- Teljes verziós játékok letöltése ingyen
- The Division 2 (PC, XO, PS4)
- Pécs és környéke adok-veszek-beszélgetek
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- További aktív témák...
- Apple Watch SE2 / 44mm / Midnight / Black Sport / Cellular (99%)
- Iphone 13 Pro Max 128 GB /// 86% Akku // Számlával és Garaniával
- Iphone 12 Pro Max 128 GB /// 88% Akku // Számlával és Garanciával
- Xiaomi Redmi 9A 32GB Kártyafüggetlen 1Év Garanciával
- Apple iPhone 12 Pro Max 128GB Kártyafüggetlen 1Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- 0% THM részletfizetés, beszámítás! Gamer PC, notebook, konzol, Apple termék, hardver KAMATMENTESEN!
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- DOKKOLÓ BAZÁR! Lenovo, HP, DELL és egyéb más dokkolók (TELJES SZETTEK)
- ASUS Radeon RX 7600 V2 Dual OC 8Gb - Aqua gari 26.12.12 ig
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest