Perl: framework Catalyst a podpora UTF-8

23.4.2009 01:29 | Přečteno: 1289× | Linux

Po poměrně rychlém odchodu od PHP z důvodů, které by vydaly na další zápisek, jsem se rozhodl začít programovat perlím frameworku Catalyst. Jedním z prvních opravdových problémů, který jsem musel vyřešit, byla podpora češtiny, respektive kódování UTF-8. Ve defaultním stavu si o ní totiž můžete nechat jen zdát.

Hned po vygenerování nové aplikace funguje pouze jedna věc a tou je vypisování dat v UTF-8 z databáze. Kde však UTF-8 nefunguje jak má?

• šablony (View:TT)
• formuláře (HTML::FormFu)
• výstup z controlleru

...tedy v podstatě všude až na to přímé vypisování z databáze.

Mnoho stránek sice o tom, jak UTF-8 zprovoznit píše, ve výsledku jsou ale informace neúplné a musíte si je složit z více zdrojů, abyste dosáhli rozumného výsledku. Po asi dvouhodinovém boji jsem dosáhl kýženého výsledku a to aplikací následujícího:

• přidat use utf8 všude, kde se pracuje se stringy (obvykle controllery)
• do lib/MyApp/View/HTML.pm vložit do volání metody config parametr ENCODING => 'UTF-8'
• do lib/MyApp/Model/Database.pm vložit do parametru connection_info parametr pg_enable_utf8 => 1 (případně mysql_enable_utf8 ap.)
• v lib/MyApp.pm přidat do use Catalyst qw/.../ modul Unicode
• upravit ve stejném souboru volání __PACKAGE__->config(...) podle následujícího vzoru:

  __PACKAGE__->config({
  	'Controller::HTML::FormFu' => {
  		constructor => {
  			tt_args => {
  				ENCODING => 'UTF-8',
  			},
  		},
  	},
  	'View:TT' => {
  		ENCODING => 'UTF-8',
  	},
  });

Po aplikaci těchto úprav byste se měli dočkat korektního zobrazení češtiny ze všech možných zdrojů.

Při psaní článku jsem využil Using Unicode in Catalyst Applications, HTML::FormFu Unicode manual a diskuse utf8 in mysql a Catalyst unicode woes.

---

Offtopic: kdybych tušil, že je možné vyvíjet webové aplikace tak snadno jako v Catalystu, opustil bych PHP už mnohem dříve. Pokud jste to ještě nezkusili, vřele doporučuji! Já osobně se učím na knížce od Johnatana Rockwaye s příznačným názvem Catalyst. Má sice dost chyb, pro mě, jako pro začátečníka, je však nejschůdnější. P.S.: Kniha přepokládá znalost Perlu a architektury Model-View-Controller.

       

Komentáře

[pht]

Taky to jde dobře s masonem a dalšíma. :)

[Jan Grmela]

Mrknu Množství modulů je bohužel někdy taky nevýhoda; člověk pak neví, který si má vybrat aby nezjistil, že bude za týden označen jako OBSOLETE...

[pht]

Zvěsti tohoto typu a obecně dobré informace získáte poměrně rychle na perlmonks.org.

[Tomas]

Ja si navic upravoval ten Unicode plugin do Catalystu, protoze prevadi do unicode

pouze $c->request->params  a uz ne "query_params" a "body_params"

Jinak si rikam zlaty PHP oproti Perlu, i kdyz jsem na PHP kdysi nadaval, ale narozdil od perlu aspon umi objekty, vyjimky apod. V perlu sice neco jako objecky, vyjimky taky jsou, ale bohuzel jen "jako".

Ani nemluve o tom, ze Catalyst ma obcas v oblibe nahlasit jen "Unknown error" pri syntakticke chybe, zadny cislo radku kde je chyba nic - proste peklo.

Kdybych nebyl donucen okolnostma, tak se Catalystu obloukem vyhnu a budu pouzivat RubyOnRails nebo nejaky Pythoni framework (Pylons, Django apod.) - (clovek si pak usetri spousta prace a casu) - se vsema uvdenyma mam zkusenosti, takze vim o cem mluvim.

Tomas

[pht]

V perlu sice neco jako objecky, vyjimky taky jsou, ale bohuzel jen "jako".

Nejen jako. Opět: pokud někdo nějakou věc nepoužívá ve svém frameworku, tak je úplně jedno, jaký to je jazyk.

[Tomas]

jeste jsem napriklad nepotkal funkcni verzi neceho odpovidajici

 try {} catch {}    konstrukci z jinych jazyku - to je to cemu rikam vyjimky.

[Jan Grmela]

Error.pm? Syntaxe je v podstatě identická s jinými jazyky (kus kódu z jednoho mého projektu):

try {
	# check whether the input is correct
	if($startpoint eq $endpoint) {
		throw RoutingException('same-startpoint-endpoint')
	}
...	
}
catch RoutingException with {
	my $e = shift;

	switch ($e->getMessage()) {
		case 'same-startpoint-endpoint' { $g->setStatus($e->getMessage(), 'The startpoint and endpoint is identic.') }
	...
	}
};

Někde si udělám třídu, která bude dědit po Error::Simple a implementovat getMessage(). Toť vše; funkcionalita mi příjde stejná jako v jiných jazycích

[pht]

Modul Error ještě umí veskrze užitečné otherwise, což je ekvivalent "catch všechno ostatní" na závěr výpisu. A samozřejmě finally.

Výhodou tohoto "jako-přístupu" je, že Perl Vám na rozdíl od jiných jazyků nenutí jeden jediný typ výjimek. Pokud chcete výjimky jednoduché do jednoduchého programu, použijete obyčejné die a eval, pokud chcete nejlepší a nejnovější všeumějící, použijete nějaký tlustý modul na takové výjimky, pokud chcete makové výjimky tak si uděláte jednoduše svou vlastní konstrukci mák { ... } nudle { ... } buchty { ... };. Podobně je to s objekty samotnými a dalšími aspekty.

Jinak u tohoto příkladu bych se na getMessage vykašlal, a rovnou udělal další podtřídy, pak nemusíte porovnávat řetězce. A náhradou switch je ve verzi 5.10 zabudovaný given...when.

[happy barney]

lepšou náhradou za switch je imho dispatch map.

$dispatch_map = {
  AAA => sub { ... },
  BBB => sub { ... },
  '*' => sub { ... },
};

eval { ... };

if ($@) {
  my $key = ref $@ || $@;
  $key = '*' unless exists $dispatch_map ->{$key};
  die $@ unless exists $dispatch_map ->{$key};
  $dispatch_map ->{$key} ->($@);
}

[Tomas]

Prave ze modul Error a podobne nefunguji.

zkuste si:

use Error qw(:try);

sub a {
    try {
        return 1;
    }
    catch Error with {
        return 3;
    }
    otherwise {
        return 4;
    }
    finally {
        return 5;
    };
    return 0;
}

print a(),"\n";

 -- tohle vrati "0" - presto ze by se to k "return 0" vubec nemelo logicky dostat.

v ostatnich jazycich je return navrat z funkce, kdezto v perlu bude return navrat z bloku pro obsluhu vyjimky, a pokud v blocich try/catch nemuzu pouzit return, tak me to prave dost omezuje, protoze to prave nefunguje, tak jako v onstatnich jazycich, kde je to podporovano nativne.

 

[jan]

Return se provadi vzdycky z nejvnitrnejsi funkce nebo "eval" bloku, je to vcelku jasne popsane v dokumentaci. Kdyz je nekdo blb*j a neraci si ji precist, tak to je jeho chyba. Chovani, ktere jste chtel, ale neumel zapsat, se dosahne takto:

sub a { try { RETURN 1; } catch Error with { RETURN 3; } otherwise { RETURN 4; } finally { RETURN 5; }; return 0; } print a(),"\n";

[Tomas]

1) vim co dela return i eval, preci jen uz perl par let pouzivam.

2) nelibi se mi, ze mi tu nekdo nadava do blbcu, namisto aby poradil, pokud skutecne existuje nejake reseni. Holt nadavat umi kazdy blbec, poradi uz malokdo, abych tak pouzil Vase vyrazy.

3) Do dokumentace jsem samozrejme koukal mnohokrat, zhavil jsem google, ale bez uspechu.

4) uvedeny kod mi neprijde moc funkcni, a "RETURN" velkymi pismeny jsem teda jeste nepotkal, ani nevim kde bych to nasel v dokumentaci.

perl -e 'use Error qw(:try); sub a { try { RETURN 1; } catch Error with { RETURN 3; } otherwise { RETURN 4; } finally { RETURN 5; }; return 0; }'

syntax error at -e line 1, near "RETURN 1"
syntax error at -e line 1, near "RETURN 3"
syntax error at -e line 1, near "RETURN 4"
syntax error at -e line 1, near "RETURN 5"
 

[jan]

ad 2) Mne se zase nelibi, pokud nekdo neopravnene kritizuje neco jen proto, ze tomu nerozumi.

ad 4) Ten kod mi take neprijde funkcni, protoze RETURN je v baliku Error::Return, ktery tam nenatahujete.

[Tomas]

ad 2) to byla jen reakce na toho "blbce";), omlouvam se

Jinaj jsem (zatim) presvedcen, ze rozumim tomu jak funguje "return", "eval", modul Error i Error::Return (o kterem jsem doted netusil) a dalsi pouzite konstrukce

Ale vratim se uvedemu kodu a k tomu, ze se nechova jako vyjimky v jinych jazycich:

 perl -e 'use Error qw(:try); use Error::Return; use Error::Return; sub a { try { RETURN 1; } catch Error with { RETURN 3; } otherwise { RETURN 4; } finally { RETURN 5; }; return 0; } print a,"\n"'

vrati 1, ale mel by vratit 5, protoze posledni co by mel provest je blok "finally".

 

[jan]

Urcite? Todle mi prijde uz celkem dost zavisle na jazyku (provedlo by se to treba pri volani execve()?), nicmene ani to by nemel byt problem - podivejte se na kod Error/Return.pm - je to asi 5 radku, takze vynutit si chovani, na jake jste zvykly by nemel byt problem. Jinak ja osobne jsem rad, ze se perl nechova jako jine jazyky, takhle je totiz mnohem ohebnejsi.

[happy barney]

return je návrat z funkcie, okamžitý. T.j. logicky očakávam, že keď dám "RETURN 1",nebude volať žiaden iný kód. V tomto je vaše uvažovanie prinajmenšom vadné.

[Tomas]

smysl try {} finally {} je prave v tom, ze blok finally je volan vzdy.

Jako clovek, ktery pouzival nejakou dobu python, jsem vyjimky zvykly pouzivat, takze hledam obdobu v perlu, samozrejme, ze si muzu upravit tohle chovani, ale je to o tom, ze si to musim napsat narozdil od jinych jazyku kde je to jejich soucast.

Perl ma samozrejme jine vyhody oproti ostatnim jazykum, ale ma taky bohuzel svoje nevyhody.

 

[happy barney]

ak toto myslenie nie je svinské programovanie, tak potom už neviem čo

Dostávate sa do konfliktu medzi "return" a "finally". Chcem vás vidieť, ako debugujete, keď aj try, aj finally budú obsahovať nejakú šialenú logiku a finally bude meniť návratovú hodnotu ...

chovanie, ako spomínate, by malo zmysel pri takejto konštrukcii:

sub aaa {
 ...
} finally {
  return 5;
}

[Tomas]

finally blok proste slouzi ke "cleanup kodu", aby se tento kod nemusel opisovat vsude, ale aby mel clovek jistotu ze bude proveden.

create_tmp_files();

try {

    nejaky_kod....

    return 0;

}

catch  ..... with { 

   obsluha vsech moznych chyb

   return 1;

}

finally {

  delete_temporary_files();
}

 -- cleanup kod "delete_temporary_files"  je volan pouze na jedinem miste a mel by byt zavolan za kazdych okolnosti.

 

ale jestli nechapete k cemu slouzi try {} finally {} tak je to pak tezky

[happy barney]

ako vravím, dostávate sa do konfliktu medzi return a finally. Finally je samozrejme volané, ak nepoužijete return.

Čo sa týka syntaxe, podobný príklad v perli už je ... continue.

while () {
} continue {
}

[Tomas]

Jaky konflikt?

blok finally se ma zavolat pri  returnu, continue, beaku apod. Jaky by pak mel blok finally smysl? to je prave duvod proc se pouziva, abys mel jistotu, ze se dany clean-up kod skutecne provede.

Je to podobne jako destruktor u objektu, taky se vola pri returnu, breaku, continue a obecne opusteni daneho bloku platnosti objektu.

 

[pht]

No nevím, asi by takto tu logiku postavit šlo a věřím, že některé jazyky to tak mají. Ale bude jednodušší nemíchat příkazy pro změnu průběhu kódu (jako je return, goto, break (v perlu last) apod) s bloky pro ošetření výjimek, protože to pouze ztíží čitelnost. Navíc Váš první příklad měl return i v bloku finally, takže tam opravdu není jasné jaká hodnota se vrátí ven.

Destruktory objektů se (v perlu) nevolají při opuštění bloku, ale při snížení počítadla referencí na nulu. Někdy to je při opuštění bloku, někdy ne, ale s blokem finally to má myslím společného dost málo.

[jan]

Nicmene ty vyjimky v pythonu se taky chovaji dost podivne, napriklad v pripade nize, se treba finally vubec neprovede. To radsi jednodusse zapamatovatelne perlovske "kdyz vyskocim z funkce finally se nevola" nez si pro kazdou funkci opoustejici funkci  zjistovat, zda finally zavola.

import os

try:

    raise

except:

    print "except"

    os.execv('/bin/date', ['date'])

else:

    print "Else"

finally:

    print "finaly"

[pht]

Jako clovek, ktery pouzival nejakou dobu python, jsem vyjimky zvykly pouzivat

Vy jste zvyklý je využívat v pythonu, ale uvědomte si, že python není pupek světa, nesežral všechnu moudrost, atp. zkrátka, že výjimky jsou trochu širší téma. Pokud hledáte v perlu python, tak jste na tom podobně, jak ti co hledají v linuxu windows. Budete furt jen remcat, že to "není dost dobrý".

A z věcného hlediska je dosti diskutabilní, jestli když dám do catch bloku return, jestli se má volat blok finally nebo nemá. Co by ten return měl podle Vás jiného dělat než skončit _funkci_ (uvědomte si, že ve funkci může být try-catch bloků několik a navíc vnořených)? Ukončit blok catch, a přejít do bloku finally, nedejbože s tím, že návratovou hodnotu zahodí?? Pěkně děkuji za takovou "logiku". Tomu bych se širokým obloukem vyhnul, protože nechci způsobovat migrénu těm co to po mně budou číst.

A ještě k tomu navíc nechápu, proč bych měl, když už používám výjimky, vracet nějaké náhodné návratové hodnoty typu 1, 10, 5, -4... funkce má vrátit výsledek nějakého výpočtu, a pokud v ní nastane výjimka, tak návratová hodnota má jít do kytek a má se řešit ta výjimka.

[Tomas]

1) Uvedomuji si ze python neni pupek sveta, ale to perl taky ne.

2) "return" ve finally bloku je logicky nesmysl, ja tim pouze naznacoval, ze block "finally" neni vubec zavolan.

3) smysl finally bloku je prave spusteni "clean-up" kodu pri jakemkoliv opusteni bloku try/catch - tozn. i "return", jaky by pak mel blok finally smysl?

Prijde mi to jako samozrejme chovani - java a ostatni jazyky to maji take tak:

  http://java.sun.com/docs/books/tutorial/essential/exceptions/finally.html

[pht]

To je ale obyčejná lookup tabulka. Do té nejde zapsat interval, regexp, nebo jiné věci, které nad rámec normálního céčkovského switche právě poskytuje perlovské given...when (díky smart match operátoru). Detaily jsou popsány v manuálu. V perlu 6 je to pak dovedeno do dokonalosti, jelikož tam má smart match mnohem větší využití.

[happy barney]

niekde plus inde mínus. given .. when mi napr neumožní modifikovať tabuľku podľa potreby (použitím local). Víťazom sa stáva kombinácia oboch .

[pht]

umožní, stačí tu tabulku dát jako alternativu do when

[Jan Grmela]

S tím requestem se na to budu muset mrknout. Zlatý PHP? Když jsem naposledy psal nějakou větší věc, tak se mi co chvíle stávalo, že jsem narazil na nějaký bug v PHP, který buď vůbec nešel spravit (například jsem se setkal i s jedním, který na Win shazoval Apache) nebo na něj byl nějaký dirty hack. A to nemluvím o bordelu (čti nekonzistenci pojmenování) funkcí, pořadí jejich parametrů a podobně. PHP by si zasloužilo kompletní rewrite (rozhraní teda určitě). Perl mi připadá takový dospělý (jasně, ty objekty jsou humus). To ale není ten hlavní problém. Díval jsem se na několik populárních frameworků pro PHP a žádný mě nijak zvlášť nezaujal. V Perlu sice programuji jen něco přes rok, přesto mi bylo hned po prohlídnutí nějakých článků jasné, že Catalyst bude ta správná volba. A začínám si to myslet čím dál víc -- během několika hodin jsem se naučil jak ve třech souborech udělat to, co bych v PHP dělal týden (uvažujme vlastní framework). P.S.: asi to bude znít šíleně ale syntaxe Perlu mi tak nějak přirostla k srdci Jazyky Ruby ani Python mě nijak zvlášť neoslovily.

[Tomas]

Ja myslis,

 

Me osobne se libi kazdy z techto jazyku - perl, python, ruby - kazdy pro neco jinyho

Ale nejvic me zaujako ruby, protoze to je vlastne kombinace  perlu, pythonu a smalltalku,

a myslim, ze to dobre zkombinovali. Navic v kombinaci s kvalitou frameworku rubyOnRails je to muj favorit;)

 

Python a ruby jsou vcelku srovnatelny, a protoze jsou znacne mladsi jazyky nez perl, tak maji krome objektu  a vyjimek

ale taky nativni podporu generatoru, iteratoru, decoratoru a dalsich vymozenosti primo v syntaxi jazyka, takze ten kod je rychleji napsany a prehlednejsi.

srovnatelny s nimi bude perl6, ktery je kompletne prepsany, ale to je zatim budoucnost (a otazka jak to bude s kompatibilitou).

 

[xsubway]

Příloha:

• rubyonrails.org (19399 bytů)

rubyonrails.org?

čekal jsem něco jiného: viz. webarchiv :-|

[dad]

rad bych se zeptal na nekolik veci ohledne Catalystu. (jako deleslouzici perlista mam k nejakym takovym nastrojum blize nez k php, python, java)

1. cetl jsem, ze je mozno pouzivat interni http-server catalystu a nebo ze to jede i pres apache. Co pouzivate, muzete doporucit? Me by bylo milejsi, kdybych mohl pouzit ten vestaveny http server.

2. jak je to s databezemi, vyuziva to sqlite a i mysql a pgsql. Mate s tim zkusenosti. Kterou pouzivate. Je mozno sahat na nejaka data i mimo databazi - napr. informace uschovane v nejakych ascii-souborech

3. Jaka je zatez servru? Perl tihne obcas k tomu zatizit cpu - bezi to pekne rychle ale kdyz bezi na servru jeste neco jineho, tak je to znat. Muzete to potvrdit? (psal jste, ze jste drive pracoval v php oblasti) takze to muzete event. srovnat.

4. Na odpovidajicich strankach catalystu pisou i o podpore ajaxu. Mate s tim nejake zkusenosti.

[Jan Grmela]

Ke dvěma posledním bodům se zatím nemohu vyjádřit. Vyvíjím na lowend mašině (Celeron 1.2, na němž je trvalý load kolem 0.9), na produkčním serveru to bude jiště o nečem jiném K Ajaxu jsem se zatím nedostal, v knize je ale popsán, tak se jím budu jistě brzo zabývat. Nějaká podpora každopádně existuje.

Interní server je opravdu příjemná feature, zvlášť pro debugging. Vestavěný server lze použít i v produkčním prostředí -- drobná nevýhoda je však, že je jednovláknový, tudíž je třeba jich mít puštěných víc na různých portech a dělat load ballancing. Nedoporučuje se používat přímo CGI, to spíše už mod_perl v Apachi. Podporované databáze jsou minimálně sqlite, mysql, postgres, oracle a myslím ještě DB2 od IBM. Osobně používám postgres, je to však o zvyku a možnostech na serveru.

Data z plaintextových souborů se dají číst stejně jako z databáze, jen je třeba napsat si na to vlastní Model.

[happy barney]

ad 1: odporúčam fastcgi. je možné ho bežať na viacerých iných strojoch ako samotný webserver (apache som k tomu neprinútil, ale taký lighttpd či nginx s tým problém nemajú)

ad 2: nič vám nebráni napísať si vlastný modul pre vašu vlastnú potrebu (ak neexistuje)

ad 3: spotreba cpu nie je záležitosť interpreteru, ale aplikácie. K tomuto len jedno, každý framework je pomalší ako špecializovaná aplikácia (hoc v rovnakom jazyku)

ad 4: google: "catalyst ajax"