Návrhy a připomínky k PHP FAQ

Až teď jsem si všimla, že následující příklad Odlišení lichých a sudých řádků se odkazuje na tutéž DB tabulku a pracuje s ní.

Anebo: ponechat čtení dat z DB s tím, že se na začátku načtou všechna data do pole, s nímž se pak pracuje v obou příkladech (jako ve [#25]). A potom (asi až za druhým příkladem?) doplnit, že u výpisu po řádcích můžeme při větším objemu dat ušetřit jeden průchod polem tímhle for ($i = 0; $zaznam = mysql_fetch_assoc($result); $i++), kdežto při výpisu po sloupcích to není možné, protože data čteme na přeskáčku. ?

Alphard:
„jestli to považuješ za nezbytné, doplním.“
Z hľadiska účelu textu je to len taká malá nepresnosť. Stačí to nejako preformulovať na trebárs:
Nevýhodou je, že možnosti odezvy serveru jsou velmi omezené, proto se to zvykne použít jen na jednosměrnou komunikaci.

Alphard:
> „Nevidim tam nikde problem s error_reporting.“
> Pravda. Už delší dobu to chci doplnit, ale pořád není nálada nebo čas. Zvýším tomu prioritu.
Tak jsem s tím začal, aby se dalo od něčeho odrazit.

Nejčastější potíže s PHP (FAQ) » Zapnutí výpisu všech chyb a varování

Ja mam dobre zkusenosti se zapisem:
@ini_set('error_reporting', E_ALL);
@ini_set("display_errors", "on");
error_reporting(E_ALL);
Jde o to, ze ruzne starsi verze php to zapinaji ruznym zpusobem. A zavinac tam mam proto, aby to nehlasilo chybu, kdyz to zrovna neni povolene v php.ini. Myslim, ze dokonce v nejake starsi verzi zalezi na velikosti pismen. Nasel jsem kdysi i ruzne obdoby, kde misto "on" pouzili 1, ale to mi v nejake verzi php nefungovalo.

Nejčastější potíže s PHP (FAQ) » Registrace uživatelů
To je prakticky nepouzitelne. Vetsina uzivatelu potrebuje jednoduchy php program, cely funkcni kod. Tohle jsou jakesi kousicky neuplne kod, ktere pochopi a dokaze dat dohromady pouze odbornik. Novackovi je to na houby. Vlastne, hlavni myslenka toho kodu je escapovani vstupu a ani to neni zabudovane do toho sql dotazu. Mozna by bylo lepsi tohle smazat uplne nez to date dohromady.

peta:
„Vetsina uzivatelu potrebuje jednoduchy php program, cely funkcni kod.“
To má (IMHO) sloužit jako pomůcka při učení se programovat, ne open-source skript pro přihlašování uživatelů.
(Tzn. má to demonstrovat jakým způsobem se různé problémy řeší, ne dodat „zkopíruj a vlož“ skript)

No jo, ale funkcni script se da upravit, kdezto nefunkcni nikdy nefungoval a uvest ho doprovozu pro novacka je naprosto neresitelny problem. Jen si precti ty dotazy a odpovedi, co jich spousta dostane a jak na ne reaguje.

Když už poslední dobou začátečníkům radíme nepoužívat mysql, ale aspoň mysqli, co kdyby se i FAQ přepsalo pro mysqli? Otázka je, kde použít procedurální a kde objektovou verzi?

K té registraci uživatelů: Proč se to vlastně nejmenuje "přihlašování uživatelů" (když z registrace tam je jen ten INSERT)?
Anebo ponechat titulek a doplnit:
- do CREATE TABLE přidat unikátní klíč na username
- k INSERTu dopsat, že stejný dotaz (po escapování uživ.jména a hesla) se použije i u registračního formuláře, a jak se zjistí, že požadované username už existuje (případně odkázat na http://php.vrana.cz/vyuziti-unikatnich-klicu-v-databazi.php, kde jsou uvedené i jiné způsoby řešení).

Ok, nevsiml jsem si, ze se to da rolovat vpravo. Ja si porad myslel, ze je tam jen funkce db_escape. Neslo by u kodu treba podbarvit pozadi mirne jinou barvou? Kvuli tisku by to mohla byt i bila. Pripadne jeste pridat tlacitko pro zobrazeni na celou stranku. Kdybych si ten kod chtel ted vytisknout, tak si ho musim prekopirovat do pspad nebo neceho. Pripadne by tam mohl byt treba pod carou maly text: Pocet znaku: 2347, aby bylo proste jasne nejak, ze to neni cele.

peta:
„Kdybych si ten kod chtel ted vytisknout“
.. tak stačí kliknout na menu (ikonka "<>" vedle bloku kódu) a odškrtnout volbu "Omezit výšku").

„Odeslání skrytého formuláře na server (např. do iframe), možnost použít kromě dat v url i post data – výhodou je možnost odeslání post dat nebo třeba i upload obrázku na pozadí, přenáší se pouze užitečná data, stránka se znovu nenačítá. Nevýhodou je obtížnější získání odpovědi serveru.“

Získanie odpovedi servera nie je v tomto prípade vôbec obtiažnejšie než pri použití XMLHttpRequest. Môže sa považovať aj za jednoduchšie - stačí do iframe priradiť udalosť onload. Okrem toho sú bohatšie možnosti v tom, čo môže server vrátiť. XMLHttpRequest sa namiesto uvedeného spôsobu používa z iných dôvodov.

[2/27] mohlo byť aspoň upravené podľa [#2]. Tvrdenie vo FAQ je nepravdivé.

K tomuto: „Vyvolat jiný požadavek na server, např. v js vytvořit objekt obrázku. Nevýhodou je, že nezískáme odezvu serveru, data lze tedy přenášet jen jedním směrem.“ - neplatí v případě, že vytvořím objekt skriptu (<script src="neco.php?naServer=123"> který vrátí něco jako zpracujData({..data ze serveru..});), dá se to použít i některých případech, kdy AJAX kvůli cross domain request neprojde.
Ale nevím odhadnout, jestli to ještě patří do FAQ, anebo jestli to chceme radit jen ve spec.případech, kdy se fakt nic jiného nedá.
↓ Fíha, díky za odkaz, moc zajímavé řešení. :)

:) Ajax je slozita vec, co zavedli bezpecnosti opatreni. Nedavno jsem delal ruzne pokusy s iframe pres javascript a ono to v jednom prohlizeci projde, treba a v druhem ne. Treba spousteni pres server a localhost dopadlo podobne, tez to v jednom prohlizeci slo a v druhem ne. (ten soubor ted nemuzu najit, ale daval jsem to tusim i do fora, protoze jsem nemohl prijit na chybu)
Na iframe mam tento priklad, jestli ti to k necemu bude.
http://peter-mlich.wz.cz/web/js/prjpw/ajax-iframe.htm

Alphard:
Nešlo mi o to, aby tam bolo veľa vecí s PHP súvisiacimi okrajovo, ale aby tam neboli nepravdivé tvrdenia. Stačilo by tam možno dať odkazy ako en.wikipedia.org/wiki/JSONP (Tori [#13]) alebo ich nejaké dobré české ekvivalenty.

Reaguji na Alpharda:
„Líbí se mi článek www.phpied.com/ajax-with-images, který možná odkáži“
O něčem podobném jsme se nedávno bavili i na diskusi.
Mám na téma AJAXu (včetně všech alternativ) něco rozepsané. Ale asi ještě chvíli potrvá, než se to objeví na veřejně přístupném místě :-)


Reaguji na peta:
„Ajax je slozita vec, co zavedli bezpecnosti opatreni.“
Jo jo, od roku 1999 je to s AJAXem těžké…

„ale daval jsem to tusim i do fora, protoze jsem nemohl prijit na chybu“
To jsem zvědavý. Odkaz?

Ok, tak to byli pokusy ajaxu s tagem script (az ted mi dlos, ze, kdyz jsem to daval do fora, mam to vlastne jako link na profilu)
script tag + javascript generovany php

Ale s iframe jsem delal tez dalsi pokusy, jen to neskoncilo na foru a nebylo to asi tak zajimave nebo to melo podobne vysledky.

Vcera jsem delal pokusy s tagem audio, html 5. Pouzil jsem k tomu wikipedii.
http://axpsu.fpf.slu.cz/~web/x/html5-audio.htm
http://en.wikipedia.org/wiki/HTML5_Audio
Potreboval jsem pustit zvuk univerzalne pro vsechny prohlizece a rikal jsem si, ze uz mozna nastal cas vyuzit html5. Potreboval jsem to pustit z localhostu jako file://. samozrejme jsem narazil na bezpecnostni opatreni, kdy mi mp3 nechtel spustit. Jenze IE nepodporuje base64, kterym jsem to chtel osidit, pac by to uz nemelo podlehat bezpecnostnim opatrenim.
Chtel jsem docilit toho, aby hra na webu (http://) prehravala zvuk a totez, kdyz si ji da clovek stahnout do pocitace se soubory (file://).
Docela mne zklamalo, ze jeste ta doba nenastala :)
Dal hledam reseni...

peta:
Ale v tom odkázaném vlákně byly, nakolik vím, příčiny celkem zřejmé (o tom document.write se píše i v FAQ) a pak se diskuse vedla o tom, jestli má smysl elementu <script> nastavovat nesmyslný src jen proto, aby nějaký src měl.

Joker: Chamurappi byl zvedavy na priklad pokusu. Nevim, jestli mu to k necemu bude, kdyz to frame neresi.

Doplnil jsem do FAQ téma kódování.

Dobrý večer,
napadlo mi, že väčšina ľudí, ktorí píšu nejaký systém - povedzme, akokoľvek jednoduchý - používa na zisťovanie, či bol PHP súbor vložený do iného súboru, testovanie konštánt, napr.:
Nedávno som prišiel na jedno lepšie riešenie, chcel by som ním sem prispieť:
Ide vlastne o to, že vo __FILE__ je vždy cesta k aktuálnemu súboru, a v $_SERVER['SCRIPT_FILENAME'] cesta k súboru, ktorý bol spustený ako prvý. Vďaka tomu táto logika vždy univerzálne funguje.

Prosím buď o nejakú kritiku, alebo ak poznáte iné - možno lepšie - riešenie, o jeho uvedenie.
Ďalej, samozrejme, ak toto riešenie prejde vašou kritikou, mohlo by byť pridané do PHP FAQ ako univerzálne riešenie.

Kubo2:
První verze je nezávislá na tom, jaký způsobem se zpracovává požadavek (tj. jestli jedna URL == jeden skript, nebo všechno jde přes index.php s routerem).

Kubo2: používal som toto:

Libil by se mi na zacatku jednoduchy ul-li seznam vsech nadpisu, abych nemusel projizdet celou stranku a hledat treba serazovani do sloupcu.
Neco, jako pouzivam tady nebo tady...
http://www.volny.cz/peter.mlich/hcomp.htm
http://www.volny.cz/peter.mlich/www.htm
(Na vzhled prilis nehledte, pred 10 lety jsem mel jine predstavy. Na foru bych mozna pouzil bold pismo pro odkazy v seznamu)

peta:
„Libil by se mi na zacatku jednoduchy ul-li seznam vsech nadpisu“
V sandboxu jsou odkazy na všechny nadpisy v pruhu na levé straně stránky.
Takže to bude, až se někdy sandbox překlopí do ostré verze.

Ještě doplním peta: Možná by bylo lepší, aby rozcestník v Nejčastější potíže s PHP (FAQ) odkazoval na textové kotvy, místo na příspěvky. Pro případ, že by bylo nutné některé části rozdělit nebo přesunout do jiného pořadí (např. kvůli překročení délky příspěvku).

Joker: Ok, a co to prozatim doplnit rucne, treba vykopirovanim z toho sandboxu? Schvaleni muze treba trvat dalsi 2 roky. Predelavka mych stranek se vlece uz asi 10 let nebo, kdy tam mam posl. aktualitu :)

peta:
„co to prozatim doplnit rucne, treba vykopirovanim z toho sandboxu? Schvaleni muze treba trvat dalsi 2 roky.“
Brzy by zase měl být sraz a nasazení sandboxu bývá jedno z témat.
Já už loni lobboval za nasazení sandboxu, tak letos to třeba vyjde :-)