Email utilitka

Aj Nette/Export by nebolo zlé :D :D :D

Nemeli bysme Davida zbytecne zatezovat. Tohle vsechno krasne zvlada Zend…

Jj, zend je v pohode :) ..A šak takéto dodatočné knižnice by hádam na rýchlosti neubrali keby si ich nepoužíval. A keď ich používaš, tak to máš za jedno či to je Zend abo od Nette.

David si tým Nette/Image asi zapiekol =D

Taky jsem nazoru, ze v jednoduchosti je sila, tzn uz i Nette\Image je tak trochu na hrane. Rozhodne bych captchu a podobne blbustky dal nepridaval. Navic by se jich dalo vymyslet vazne hodne. Lepsi bude se soustredit primo na dalsi vyvoj jadra frameworku.

• E-mail je výborně (už léta) vyřešený Richardem Heyesem, nebo v Zendu.
• Nette\Export – není mi úplně jasné, co by to mělo dělat (jako třeba export do Excelu apod?)
• captcha je pěkné téma pro rozšíření třídy např. TextInput do (připravovaných) nette-extras. Co třeba použít jako základ 3D captchu? Dalo by se tam pěkně použít i Nette\Image:

...
# matrice
$matrix = Image::fromBlank($matrix_dim['x'], $matrix_dim['y']);
$black = $matrix->colorExact(0, 0, 0);
$white = $matrix->colorExact(255, 255, 255);
$matrix->fill(0, 0, $white);
...

Nechci tím říct, že se bráním nápadům, jen prostě chci přidávat věci, které:

• odpovídající zaměření a jsou úměrné velikosti frameworku (exportér do Excel 2007 je 3× větší, než celé Nette)
• existuje jedno nejlepší řešení (to u captchy není už z principu možné, existují velmi rozdílné implementace a jejich plusy a mínusy jsou sporné)
• implementace v Nette musí mít evidentní přínos (pokud už nějaké špičkové řešení existuje, nemá smysl objevovat kolo)

Třeba takové Nette\Image dle mého místo má, protože základní operace s obrázky patří téměř ke každému střednímu webu a neznám jinou třídu, abych mohl říct: Nette\Image přidávat nebudu, protože existuje XYZ nebo protože to má Zend ;)

David Grudl napsal(a):

Třeba takové Nette\Image dle mého místo má, protože základní operace s obrázky patří téměř ke každému střednímu webu a neznám jinou třídu, abych mohl říct: Nette\Image přidávat nebudu, protože existuje XYZ nebo protože to má Zend ;)

Tohleto znáš?

http://phpthumb.sourceforge.net

Nette\Image má pěkné API. Asi bude problém, když člověk bude chtít pracovat s většími obrázky, tak ho bude omezovat memory limit phpčka. Tj použití ImageMagicku, když je k dispozici, tak by bylo výhodné, jako to umí ten phpthumb.

Jinak jsem spíš proti captche. Komentářové formuláře bych řešil přes povinné Preview. Pokud by to nestačilo nebo jinde zkusit použít řešení se skrytým polem, které se vymaže javascriptem (když je vypnutý javascript, tak se zobrazí „tento text musíte smazat“), případně s čeknutím refereru, že se musí nejdříve zobrazit stránka s formulářem a pak teprve formulář odeslat, respektive s čeknutím času těchto dvou po sobě následujících událostí.

veena napsal(a):

David Grudl napsal(a):

Tohleto znáš?

Nette\Image má pěkné API. Asi bude problém, když člověk bude chtít pracovat s většími obrázky, tak ho bude omezovat memory limit phpčka. Tj použití ImageMagicku, když je k dispozici, tak by bylo výhodné, jako to umí ten phpthumb.

Proč myslíš, že ImageMagick memory limit neomezuje?

Vůbec, máte někdo hosting, kde je ImageMagick k dispozici?

David Grudl napsal(a):

Vůbec, máte někdo hosting, kde je ImageMagick k dispozici?

No ve většině případů mě stačí jednoduchá práce s obrázky, ale v případě potřeby ten imageMagick pouzit jde. Nevím jak jsou na tom české hostingy, ale osobně používám takový na kterém to jde ( hostican.com )

Zrovna v tom odkazovaném článku udělají to, že zavolají externí program a ten pak samozřejmě běží v jiném prostoru. Ale o tom, že by PHP modul ImageMagick nebyl limitován narozdíl od PHP modulu GD docela pochybuju, takže – důkazní břemeno je na vás :-))

David Grudl napsal(a):

Zrovna v tom odkazovaném článku udělají to, že zavolají externí program a ten pak samozřejmě běží v jiném prostoru. Ale o tom, že by PHP modul ImageMagick nebyl limitován narozdíl od PHP modulu GD docela pochybuju, takže – důkazní břemeno je na vás :-))

Mám za to, že (snad) vždy, i když se jedná o PHP extension, tak je tam zakomponovaná pouze podpora pro volání ext. programu – a to je ta hlavní feature. Že to není přímo závoslé na jádru PHP. Kdyby samozřejmě zpracování těch požadovků proběhlo přímo v PHP (i kdyby jako extension), stejně je člověk omezený limitem paměti.

Proto, pokud by se uvažovalo o implementaci, rozhodně bych byl pro implememntaci formou volání ext. programu – jedině tak by došlo k využití nabízených výhod.

Každopádně, každý hosting, co má podporu ImageMagick, tak má (z mé zkušenosti) vždy podporu pro ext. program.

Aha, takže PHP rozšíření ImageMagick asi skoro žádný hosting nepodporuje (tudíž je v podstatě jedno, jestli jej limituje memory_limit nebo ne, ani nevím jak to ověřit, bo http://pecl4win.php.net/ is out of service). Ale na řadě míst (nebo na linuxu skoro všude?) je instalována knihovna ImageMagick, která samozřejmě memory_limitem netrpí a pokud ji hosting dovolí zavolat přes exec, je tu zajímavá alternativa pro GD.

Nevýhodou je, že to nelze nijak detekovat.

Popřemýšlím, jak ImageMagick využít.

David Grudl napsal(a):

Nevýhodou je, že to nelze nijak detekovat.

Nezkoušel jsem, ale napadá mě provést nějaký „prázdný“ příaz přes exec na imagemagick a pokud vrátí false, nebo chybu, tak imagemagick není. Druhá varianta by byla nechat nastavení, zda použít gd2 nebo imagemagick na programátorovi, s tím, že gd2 by byla výchozí.