Nette & Ajax, směr pro vývoj Rich aplikací

comet server, ktory fajn funguje aj s php je APE ape-project.org

No nevím, myslím, že kdo chce vyvíjet RIA aplikace, měl by se naučit Javascript a dělat tuhle práci v něm.

Tak tohle je jedna z mých představ pekla. Všechno od persistence až po barevné hejblátko ve formuláři nadefinovat v na serveru… Zabetonovat to horem dolem, dostat nespravovatený backend a mizerný frontend.

Nemyslím si, že takto se dají vyvýjet webové aplikace. Připadá mi to jako vcelku pochybná cesta, jak dělat malé webové prezentace.

Máš nějakou představu o tom, co by mi to vlastně přineslo za výhody? Mohl bys uvést příklad?

Jednou jsme se touto cestou vydali v posledním systému co teď vyvíjíme a výše zmiňované řešení proklínám, jako jedno z nejhorších. Stává se z toho nepřehledný bastl, zvláště v okamžiku, kdy aplikace funguje v dual režimu (fully ajax i non-ajax). Řešení nette pomocí snipetů mi vyhovuje mnohem více, i když má to hodně much.

Každopádně kromě phpquery existuje i přímo phpjquery

frosty22 >> taketo systemy su IMHO pisane prave naopak. Backend je len API, storage a logiku zastresuje nieco ako ExtJS.

Na druhu stranu, Jakub Nesetril na minulorocnom Webexpo predpovedal, ze sa blizi novy koncept (mozno zjednotenie kodu klienta/servera, frontend/backend) webapps. Teraz zijeme v dobe AJAXu (pred tym bola pred-ajax doba) a podla neho sa coskoro web posunie dalej. Nikto vsak nevie kde. Ked som na tuto temu halucinoval :D s @tiso, rozmyslali sme prave o tom, ze v novej dobe by sa DOM menil priamo zo servera. Kazdy pripojeny klient by na serveri predstavoval zivy DOM strom a server by ho svojou logikou menil priamo u seba.

Toto bohuzial na PHP nie je moc realizovatelne, lebo PHP je skript, ktory iba prebehne. Ale prave na Node.js, ktore je runtime by to mozno slo spravit. Ale ako pisem – je to taka halucinacia.

Editoval srigi (3. 6. 2011 9:54)

No k poslednímu příspěvku bych řekl asi to, že imho prakticky popisuješ snippety

• „detekovalo ajax a ihned zavolalo konkrétní metodu“ – nj. ale k té konkrétní metodě se je potřeba někudy dostat (router), řešit u toho případně autentikaci a autorizaci apod.
• připojení k databázi lze řešit lazy nastavením, tj. že spojení se provede až při prvním dotazu
• osobně si myslím, že to co popisuješ v úvodu lze přes snippety a komponenty udělat už teď, akorát je potřeba se rozhodovat jinde než v handle metodě presenteru. Tj. v presenteru jen invaliduješ loginBox komponentu a ta sama rozhodne, že pro přihlášeného se nevykresluje / vykresluje jinak. Se snippety je pak easy zajistit render jen konkrétní části stránky.

Přečetl jsem si celé toto vlákno a rozhodl se také zareagovat. Podle mého názoru by bylo velmi nešťastné začít psát RIA aplikace, které si bez vypnutého JS neškrtnou.

Hlavní otázkou totiž je, v jakém poměru rozdělit aplikační logiku mezi klienta a server. Podle toho rozlišujeme serverově a klientsky orientované RIA aplikace. RIA aplikace postavená na technologii AJAX, by podle mého i v dnešní době měla být orientována serverově – většina aplikační logiky by měla zůstat na straně serveru.

Však i Nette a jeho snippety k tomu vedou. K překreslování snippetu stačí mít v klientské části velmi jednoduchý a hloupí kód, který se stará o jejich překreslení. Samozřejmě, že když smažu nebo přidám položku do tabulky, nemá cenu překreslovat celý, mnohdy velký snippet. Stačí si na tyto události napsat obsluhu, která při úspěchu v DOM element vyjme nebo přidá.

Osobně se snažím i administrace psát tak, aby bez JS fungovalo 99% funkcionalit. Dovedu si však představit, že pokud aplikaci spravuje pár lidí, není problém upozornit je, že bez JS si neškrtnou.

Závěrem snad jen to, že na serverovou část klienta se můžu spolehnout více než na tu klientskou, kde je prostředí o hodně proměnlivější (možnosti prohlížeče, slabší výkon počítače…), což je další důvod proč aplikaci orientovat serverově.

Editoval Vyki (3. 6. 2011 23:38)

Vyki napsal(a):

Přečetl jsem si celé toto vlákno a rozhodl se také zareagovat. Podle mého názoru by bylo velmi nešťastné začít psát RIA aplikace, které si bez vypnutého JS neškrtnou.

Hlavní otázkou totiž je, v jakém poměru rozdělit aplikační logiku mezi klienta a server. Podle toho rozlišujeme serverově a klientsky orientované RIA aplikace. RIA aplikace postavená na technologii AJAX, by podle mého i v dnešní době měla být orientována serverově – většina aplikační logiky by měla zůstat na straně serveru.

RIA bez Javascriptu? Proboha. 2011. HTML5. Javascript mi běhá i na zahradě. To je práce navíc, kterou nikdo neocení.

A pokud mě chceš podpořit v dalším konstruktivním rýpaní, můžeš definovat aplikační logiku, serverově orientovanou aplikaci a popsat tu logickou úvahu…

edit: typo

Editoval PJK (4. 6. 2011 0:29)

frosty22 napsal(a):

Konkrétně to co jsi nyní uvedl, tak to je dost věc názoru – ano může aplikace košér a fungovat bez JS, jasně proč ne. Na druhou stranu čas jsou peníze, a u některých vysloveně RIA aplikací, je tatřka nemožné, respektive muselo by se například i navrhnout alternativní GUI, jelikož bez JS nejsou modální okna, vysouvací menu jsou pracnější, drag&drop neexistuje atd. viz odkaz výše na Fenq, což je docela RIA aplikace, jejíchž některé části by se pracně řešili bez JS.

Já s tebou v zásadě souhlasím. Určitě je to pohodlnější psát pouze pro podporu s JS. Psát i druhou verzi bez JS je potom opruz. V mé administraci také neběhá bez JS všechno, ale snažím se aby většina ano. Pokud chce někdo provádět admnistraci a mít k dispozici všechno, co mu můžeme prostřednictvím RIA aplikace nabídnout, ať si potom povolí JS, nebo aktualizuje prohlížeč. Pokud to, ale neudělá bylo by dobré, aby mohl dělat alespoň ty základní operace – facebook sice nemám, ale předpokládám, že i tam to nějak podobně fungovat bude.

Další věcí je, že do JS je vidět. Pokud budu mít v JS uloženo pár hloupých řádků, může mi být jedno, že je někdo zcizí. Dále tu jsou rozdíly v implementačních detailech JS v různých prohlížečích. Sice to jde eliminovat pomocí JS frameworků, ale ne na všechno frameworky stačí. Třeba poslední co mě nakrklo je, že IE 9 neumí history.pushState což umožňuje pomocí JS měnit hodnotu URL.

Editoval Vyki (4. 6. 2011 2:05)

„Další věcí je, že do JS je vidět. Pokud budu mít v JS uloženo pár hloupých řádků, může mi být jedno, že je někdo zcizí.“

Tak tohle by bylo díky onomu návrhu v prvním příspěvku – manipulace s DOM elementy na straně serveru a komunikace zasílání i aplikační logy na základě requestů, více problematické pak ukrást zdroják. Ano šlo by to, ale již by to postrádalo takovou eleganci, a musela by se podstatná část dopsat / odovodit.

Ale největší problém opravdu by pak byl, zpětná odezva resp. mohli by v podstatě existovat jen settery, alternativně by se musel vymyslet zajímavá logika, která by i vyžadovala, co konkrétního se má zpětně zaslat s požadavkem.

Příklad:

// tohle je v pohodě
$dom = new Dom();
$dom["#content"] = "Vítáme Vás";

// tohle už je problém
if ($dom["#content"]  == "vítáme Vás") ...

// takže u událostí na straně klienta, by se muselo i definovat, jaké informace je poslat zpátky

Editoval frosty22 (4. 6. 2011 11:43)

Tohle je paranoia… Nechápu proč bych měl upravovat DOM čemukoliv jinému než XMLkám. Od čeho jsou šablony.

Střežená má být business logika a né práce s pár tagama, co to je za blbost…

Pokud jde o DOM na serveru, ještě bych si přisadil, že v rozumně zjednodušené podobě už řeší snippety. Šťourat se v tom dál je overkill.

Když někdo chce ty trochu nešťastně pojmenované „plně ajaxové“ aplikace, tak to nebude psát v PHP. Dál se o tom budu bavit jen osobně, neboť takhle se bez výsledku uflejmujeme a každý přitom bude mluvit o něčem jiném :P. Že by téma na poso?

A ten facebook… tě pošle dohazjlu, resp. na mobilní verzi :). Řešit, jestli web bude funogvat bez JS, mi připadá důležité jenom kvůli vyhledávačům. Aby všechen obsah, který chceme mít zaindexovaný, byl dosažitelný i bez něj.