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

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
frosty22
Člen | 373
+
0
-

Zdravím,

osobně bych se rád zapojil do vývoje Nette, mám určitou myšlenku na lepší podporu JS/AJAX, pro umožnění vývoje AJAXovatějších aplikací :)

V aktuální chvíli, pokud se nemýlím, je pouze podpora snippetů ze strany Nette, což je příjemná záležitost, avšak pro rozsáhlejší RIA (nemyslím vložky) aplikace nedostačující.

Otázka je v podstatě taková – měl by vývoj v tomto směru potenciál a smysl, ze strany Nette, či tato podpora by nebyla tolik stěžejní.

Například by poté mohlo existovat něco ve smyslu:

public function handleLogin($login, $password)
{
  $autorizated = $this->authorizate($login, $password);

  $dom = new \Nette\Ajax\DOM();
  if ($autorizated) {
    $dom["#login-box"]->remove();
    $dom["#content"] = $this["homepageBlock"];
  } else {
    $dom["#login-box .message"] = "Neplatné přihlašovací údaje";
    $dom["#login-box input"] = "";
  }

}

protected function createComponentHomepageBlock()
{
   $dom = new \Nette\Ajax\DOM();
   $dom["#content .next"]->onClick[] = callback($this, "showNextArticles");
   $dom["#content select.paginator"]->onChange[] = callback($this, "setArticlesPerPage");
   ... vykreslení atd ...
}

Je to jen takový wifeframe, co by teoreticky bylo možné a jakým způsobem by mohla vést cesta na vývoj více AJAX/RICH aplikací, myslíte že by to mělo nějaký smysl? V podstatě posunout úroveň manipulace JS (jQuery bych preferoval) na úroveň server-side.

Samozřejmě kvůli zatížení serveru, by bylo ideální propojení s nějakým COMET serverem, a vytvářet persistentní spojení, ale to by bylo v PHP podstatně problematické řešení, ikdyž možná by řešení by existovali (long poll, apod.)

Editoval frosty22 (2. 6. 2011 13:40)

Lopo
Člen | 277
+
0
-

ak sa nepletem tak nieco na sposob server-side jQuery je phpquery

bazo
Člen | 620
+
0
-

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

frosty22
Člen | 373
+
0
-

No samozřejmě jsem mohl předpokládat, že už něco takového existuje, na ono phpQuery se podívám blíže :)

Co se týče APE, tak to jsem již v rychlosti zhlédl, pouze tedy tam nebyla podpora PHP, avšak možná že se to již změnilo.

Stále otázka zní, zda-li by to mělo smysl? :) V podstatě tedy zapouzdřit něco na způsob phpQuery, spolu s Nette – propojit na úrovni requestů, resp. funkčnost v duchu XML-RPC, pouze tedy JSON-RPC-LOCAL(AJAX)

Editoval frosty22 (2. 6. 2011 13:10)

Ondřej Mirtes
Člen | 1536
+
0
-

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.

frosty22
Člen | 373
+
0
-

Co se týče událostí, které nepotřebují komunikaci se servrem, tak jistě ano – zbytečné zatěžovat server, avšak u požadavků spolupracující s daty, by to možná nebylo přímo od věci. Avšak toť je důvod, proč se táži, na názory ostatních – osobně jsem v tomto směru dosti subjektivní – LOVE AJAX =)

PJK
Člen | 70
+
0
-

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?

Filip Procházka
Moderator | 4668
+
0
-

Imho na tohle bych si nastudoval node.js :)

jazby
Člen | 44
+
0
-

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
Člen | 373
+
0
-

Osobně vidím potenciál v čistě AJAX řešeních, konkrétně tedy v intranetových systémech / backendech aplikací – rezervační systémy, Groupware, eLearning, například Feng Office (http://www.crunchbase.com/…/41575v2.png).

Podobné systémy pokud mají být fully-ajax by v podstatě tímto či podobným směrem bylo jednodušší vyvíjet. Samozřejmě děkuji za názory, podobnou cestou vývoje jsem se u větší aplikace zatím nevydal a vše řeším na straně jQuery, a následně komunikace s AJAXem, ale v tomto právě jsou snippety nereálné (například kvůli jednomu přepnutí stavu vykreslovat render/action a startovat nette) ..

Z tohoto důvodu jsem přemýšlel nad logikou, která by byla více flexibilní a v rámci ajax requestů výkonnější (což zrovna z příkladu nevychází, ale v podstatě by šlo o to, najít rychlejší cestu, jak komunikovat se serverem, a alokovat/zpracovávat jen potřebné objekty). Zároveň v tomto duchu mě právě napadlo idea, kdy by bylo možné vrátit zpět nejen obsah, ale i určitou logiku, což jsem znázornil výše.

Děkuji za další nápady a postřehy, rozhodně toto není finální smysl, nýbrž jen mind-preview.

srigi
Nette Blogger | 555
+
0
-

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)

frosty22
Člen | 373
+
0
-

Pro začátek právě zásadní potenciál vidím, právě v onom smyslu AJAXu, tj. proč zbytečně renderovat celou stránku (novinky, stránky, menu, atd.), když jen procházím stránkováním novinek, apod. A snippety, tenhle problém bohužel neřeší, co se týče zatížení serveru.

Chápu, že přesunout logiku DOMu na úroveň serveru, je přesný opak, tohoto a opět si člověk nepomůže s výkonem, a namísto oběžování CPU klienta, bude opět závislost na serveru, ale původně jsem to asi špatně vyjádřil a spíše mi šlo o jednodušší a rychlejší komunikaci AJAX requesty, a nad toto by se dalo i zapouzdřit manipulace DOM.

Základním kamenem by tedy bylo alternativní rozhraní, NAPŘÍKLAD které by co nejdříve při requestu (ideálně například i před spuštěním databáze v boostrapu) detekovalo AJAX a ihned zavolalo konkrétní metodu, která jí má zpracovat, v té pokud by byl například přístup do databáze, tak poté teprve by se to připojilo do databáze, pokud však by potřeba nebyla, tak by ihned vrátila konkrétní data a uzavřela spojení. Onen DOM, který jsem v příkladu naznačil, by měl spíše sloužit k tomu, aby vznikla možnost doplnit onu návratovou hodnotu i o určitou logiku, která by se aplikovala na DOM, což jsem předpokládal, že by zpřehlednilo programátorskou práci, jelikož by vše bylo v jedné části.

Samozřejmě volat pak metody, které pouze upravují DOM, aniž by vyžadovali práci s daty apod., tak to by bylo opět zbytečné plýtvání hardwarovými prosředky na straně serveru.

Ve finále však máte asi pravdu a tato volba v možnostech PHP je nešťastná, a u větších projektů může dojít poté spíše k nepřehlednosti a složitosti namísto naopak.

Dr.Diesel
Člen | 53
+
0
-

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.
frosty22
Člen | 373
+
0
-

No pravděpodobně máš pravdu a nic lepšího než snippet ve finále nevymyslím :) No na jednu stranu docela škoda, jsem doufal, že se budu moci zapojit do vývoje nette ve směru AJAXu, což je záležitost, které se v poslední době podstatně hodně věnuji a v RIA aplikací vidím velký potenciál, ale holt se budu muset nasměrovat trošku jiným směrem, a „vymyslet něco“, co by ulehčilo práci na RIA aplikacích :) Například nějaké přímé componenty alespoň :)

Vyki
Člen | 388
+
0
-

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)

frosty22
Člen | 373
+
0
-

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.

Další důvod, kolik uživatelů má vypnutý JS? A když mají tak je to jejich boj, jelikož na vysokém počtu webových stránek již teď neuspějí, takže nonJS řešení v dnešní době již dost postrádá smysl, avšak je to pouze můj osobní názor.

PJK
Člen | 70
+
0
-

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)

Vyki
Člen | 388
+
0
-

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

O RIA bez JS nikdo nic nepsal. To je holý nesmysl samozřejmě. Pokud půjdu cestou AJAXu můžu vytvořit aplikaci, která bude nést znaky RIA aplikace. Pokud to však naprogramuji tak, aby to šlapalo i bez JS, které třeba zakážu, k pojmu RIA se to příliš blížit nebude, ale stále to bude funkční aplikace.

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…

Pod pojmem aplikační logika se skrývá co ten tvůj program vlastně bude dělat, jak bude fungovat. Na straně serveru to definuješ pomocí PHP skriptů, na straně klienta pomocí JS.

Klientsky orientovaná RIA aplikace – Na straně serveru je minimum aplikační logiky, která se stará o výběr dat z DB a jejich posílání do klientské části aplikace. Klienstaká část aplikace data přijme a musí je umět zpracovat – to co bys jinak dělal v PHP musíš nyní udělat v JS. Takto například funguje ExtJS. V tomto případě se JS bude starat i o prezentační část, musí se postarat o výpis dat v nějaké formě.

Serverově orientovaná RIA aplikace – Na straně serveru je většina aplikační logiky. Data se vyberou z DB a připraví se pro šablonu, která mi tvoří prezentační část. Na straně klienta mi stačí hloupý skript, který mi přijaté fragmenty kódu (snippety) pouze překresluje, víc umět nemusí.

Editoval Vyki (4. 6. 2011 1:17)

Vyki
Člen | 388
+
0
-

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)

hrach
Člen | 1822
+
0
-

History.pushState se da obchazet pomoci #. Pokud se bavime o „aplikaci“, tak vetsinou mame taky cilovku – tedy uz se da lepe predpokladat, jestli to pobezi na IE6 v Ceske sporitelne, nebo na FF4 v nejake programatorske firme… ⇒ Pouze ajaxovy frontend → nouproblema!

Editoval hrach (4. 6. 2011 12:36)

frosty22
Člen | 373
+
0
-

„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)

newPOPE
Člen | 648
+
0
-

@frosty22

to je zrejme problem stavu aplikacie ktory (aspon sa domnievam) je rieseny URLkou. V sucasnosti mas v NETTE strom komponent zacinajuci niekde u presenterov a pripojene ine komponenty a tie su bud autonomne alebo su riadene rodicmi.

Skor by som sa snazil vyriesit ten stav v ktorom sa app nachadza, a potom uz by sa s tym pracovalo pohodlnejsie (nie som expert v inych oblastiach ale neriesia toto apl. servery v inych jazykoch?).
Cize vymyslet nejaky mechanizmus ktory by stav jednotlivych komponent ukladal automaticky.

Priklad:

<?php
	$this->getParam('xyz');
?>

Prave toto by sa netahalo z GET,POST ale zabezpecil by to hore spomenuty mechanizmus…

Filip Procházka
Moderator | 4668
+
0
-

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…

Ondřej Mirtes
Člen | 1536
+
0
-

HosipLan++

PJK
Člen | 70
+
0
-

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.

frosty22
Člen | 373
+
0
-

HosipLan:
Pravděpodobně máš pravdu, ostatně byl to jen myšlenkový pochod, jakým způsobem řešit čistě AJAX intranetové aplikace, a bohužel to vypadá, že špatný. Nicméně pokusím se nasměrovat veškerou logiku na stranu klienta, tj. jQuery řešení. A stranu serveru ponechám pouze jako datové řešení.

newPOPE:
Bohužel pravda, řešením je nejspíše použití jiného jazyku, který by k tomuto přistupoval synchroně viz například pomocí node.js, apod. Hlavně tedy využití COMET serveru je ideální.

Nuž díky za informace, ale snaha byla :)