PHP - diskusní klub na Lopuchu

Registrace nového uživatele

Návod

Kluby

Archív Lopuchu

Lopuch.cz

Diskuze na Lopuchu,
pohlazení na duchu

Lopuch.cz

	Klub PHP [ŽP: neomezená] (kategorie Programování) moderuje makovec.
	Archiv Diskuse o vybornem skriptovacim jazyku php. Dulezite odkazy, pred polozenim dotazu zkuste hledat odpoved zde: www.php.net - domovská stránka PHP www.kosek.cz - spousta tutorialu pro PHP v češtině

Nastavení klubu

Nastavení práv

Homepage

Anketa

[ 1845 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


	Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 1.6.2009 21:10	2696
	Tak treba v Ruby on Rails je to dost zaklad a asi by uzivatele nemenili.


	pepak - Pepak.net 1.6.2009 20:58	2695
	Objektově-relačnímu mapování jsem nějak nikdy nepřišel na chuť, a v interpretovaných jazycích už vůbec ne.


	makovec Chuck Norris snědl jídlo od Babicy - a ještě si přidal 1.6.2009 20:32	2694
	Bredy [2693]: dik, ale ja radsi vlastni. jen je chci vylepsit. z drivejska mam s kontrolou IP, ale rikam si ze to stopro de lip. jen ne a ne kapnout na to co by bylo nejlepsi


	1.6.2009 20:29	2693
	makovecPoužívám BlueBoard.


	Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 1.6.2009 20:22	2692
	(Za predpokladu, ze DB prepared statements umi. A popravde receno jeste asi lepsi je (ve vetsine pripadu) mit nejaky OR mapovani, ktery krome SQL injection za cloveka resi i jiny veci. Jenze zase o takovejchhle vecech holt mezi beznou "PHP populaci" neni zas az tak velky povedomi.)


	pepak - Pepak.net 1.6.2009 19:44	2691
	Škoda, že nikdo nepoužívá prepared statements, které celý problém SQL injection řeší beze zbytku. A vedle toho je pak aplikace mnohem rychlejší.


	makovec Chuck Norris snědl jídlo od Babicy - a ještě si přidal 1.6.2009 19:42	2690
	jak nejlepe resit ankety? pres kolacky ? (velejednoducha moznost zfalsovat vysledek) pres ip ? (slozitejsi falsovani ale sdilena IP si ani neskrtne) nebo jakasi kombinace obojiho?


	1.6.2009 19:12	2689
	používal jsem magic quotes, ale postupně přecházím na jinou formu zápisu do DB, v té nejjednoduší formě v podobě asociativního pole, kde každou pološku příslušná zapisovací/výkonná funkce o escapuje sama.


	huh 1.6.2009 17:06	2688
	tvx [2687]: Pokud to obsahuje & jen v platných entitách tak to dekóduj, jinak to ber jako už dekódované (buď je to bez entit úplně nebo je to mix typu XML v XML).


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 1.6.2009 16:41	2687
	huh - problem je ze netusim co mi ze zdroje prijde neb je znacne heterogenni a navic kazdej den to muze dodata jinak a rucne ty data jet nejdou ":( leda snad nejakej preprocesing s odhadem... kkl diky, doplneni nekterych novinek jo, jasne, mam na vse samozrejme zapouzdrujici funkce ktery jde aplikovat i na pole narozdil od natovnich :) ktery dle verze php zvolej spravnou funkci :) addslashes je pak jistota co funguje vzdy, ten vykrik na konci poradne nechapu a ani neni zduvodnenej.


	Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 1.6.2009 16:32	2686
	tvx [2684]: Zkus procist tohle. Mimo jine se tam uplne na konci pise, ze na addslashes by mel clovek uplne zapomenout. Ale na detaily (souvisejici konkretne s PHP) se me neptej, nedelam s PHP bezne natolik, abych vedel, ktera escapovaci funkce co presne dela.


	huh 1.6.2009 14:54	2685
	Pokud to nejakej zdroj posila zakodovany, tak hned na vstupu dekodovat a dal s tim pracovat normalne.


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 1.6.2009 14:41	2684
	Jak resite praci s html, konkrene se specialnima znakama? Ja do db ukladam maximalne cistej text co dostanu, honim jen pres addslashes(), kdyz delam vystup, tak htmlspecialchars() kde uz cihaj vtipny problemy: pri nastaveni normalnim doubleencode je to v pohode do ty doby, nez mi z externiho zdroje dorazi treba spravne zakodovany url s & ... v ten okamzik to na vystupu prevede na &mp; v tu dobu je prima mit to zase nastaveno jako doubleencode=false :) ktere ale pri praci s databazi prozmenu postupne odstranuje umyslne vicekrat zakodovany entity az do puvodniho tvaru. Jsem v koncich, tohle asi nepujde jinak nez uplne selektivne co?


	15.5.2009 21:38	2683
	me je to jedno. vnitrni casti programu stejne nesmi pracovat nativne se $_SESSION, ale s nejakym uzivatelskym objektem. Samotny mechanismus ziskavani dat ze session je celkem nezajimavy. Vyuziti databaze umoznuje napriklad ten objekt generovat uz na urovni sql dotazu, kdy cast se vyzvedne ze session zaznamu a cast z perzistentnich dat toho uzivatele, treba nacionale, prezdivka, veci, ktere pouzivas dost casto, aby ses na to opakovane vyptaval databaze.


	EtDirloth 15.5.2009 20:03	2682
	makovec [2674]: wget Bredy [2663]: 1.) (session nechodily) mam chapat tak, ze session_start() a $_SESSION neboli z nejakeho zahadneho dovodu k dispozicii? 4.) nechapem - expiraciu session snad riadis z aplikacie cez samotne session-data. 2., 3., 5., 6., 7.) takisto niesu dovodom pre vlastnu implementaciu session - pricom samozrejme nehovorim o implementacii custom save handler, ale o tom, ze obchadzas mechanizmus session_start a superglobal $_SESSION, implementaciou vlastneho API. Bredy [2666]: zlozite to iste nebude, ale ak v aplikacii pouzijes nativne $_SESSION (pre dobry pocit s lubovolnou implementaciou session save handleru - a je jedno, ci to bude defaultny session.save_path, DB, alebo webservice), ziskas velku vyhodu prenositelnosti (ci uz custom save handleru, alebo aplikacie). Na druhu stranu, ak pouzijes svoje custom API, aplikacia ho proste musi poznat.

[ 1845 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


(c) 2001-2011 Lopuch.cz Kontakt