Interaktívne javascript GUI

Tiene minulosti

S kladením dôrazu na javascript sa otvárajú nové možnosti k návratu k naozaj interaktívnemu GUI, ktoré obdobie dôrazu na aplikácie s tzv. "web klientom" alebo dôrazom na "tenkosť" vo veľmi naivnom zmysle čisto server side renderu dosť podkopalo.
Ďalšie nie moc šťastné obdobie, ktoré nasledovalo, charakterizuje všakovako skloňované slovko Ajax. V praxi zväčša znamenalo kombinovanie server renderu s kowbojským klientským scriptovaním. Takto bolo možné posunúť webového klienta z hľadiska interaktivity oveľa ďalej, ale za akú cenu? Len ako paradox zabrdnem zase raz do model2 MVC fanúšikov, ktorí radi kládli dôraz na testovateľnosť, čo čisto serverovsky poňaté model2 prináša, ale kombinovanie client a server GUI logiky toto takmer úplne popieralo.(zostalo manuálne "preklikávanie" alebo automatizované GUI testy).

Výzvy

S otváraním dverí pre plné využívanie možností javascriptu sa otvárajú aj nové výzvy.(tie sú samozrejme spoločné pre všetky rich GUI platformy od js pokračujúc napr. ku silverlight, winforms alebo WPF).
A aké sú tie výzvy? Odmyslime si štandardnú požiadavku na vybavenosť frameworku kvalitnými a bohatými komponentami, hlavne ovládacími prvkami. V prípade avascriptu túto požiadavku v celkom slušnej forme (ak keď nie bez zásadných výhrad) pokrýva z môjho pohľadu napr. ExtJS. Za podstatnú výzvu považujem interaktivitu v záujme vyššej kvality práce používateľov a ich pozitívnych skúseností s GUI.

Čo je moderné GUI

Modernosť GUI by som podmienil práve dobrou odpoveďou na túto výzvu. Klasický prístup jedného zobrazeného formulára s aktuálnym taskom používateľa nestačí. Používateľ by mal mať k dispozícii v tom istom čase ďalšie pohľady, ktoré mu v efektívnej podobe umožnujú v rámci kontextu aktuálne riešeného hlavného task sledovať súvisiace informácie a tiež mu majú ponúknuť možnosť sledovať a reagovať na širšie dianie v rámci aplikačnej domény. Prvá požiadavka má obraz v medziwidgetovej komunikácii a druhá v možnosti widgetu reagovať na doménové udalosti. Tiež je dnes pomerne bežnou požiadavkou, aby si priamo používateľ (alebo to pre neho urobí dodávateľ) mohol svoju obrazovku prispôsobiť potrebám a špecifikám svojej pracovnej pozície.

Kompozitné GUI pri požiadavke vysokej interaktívnosti vyžadujú teda dobré riešenie medzikomponentovej komunikácie a modulárnosti. Toto si spájam neodlučiteľne s nízkou previazanosťou najmä preto, že iná cesta nutne vedie ku neudržiavateľnému a neflexibilnému špagety kódu, hlavne pri komplexnejších aplikáciách.(samozrejme profit z nízkej previazanosti komponentov je oveľa širší napr. v testovateľnosti, modulárnej rozširovateľnosti, flexibilite v nastavovaní oprávanení cez dynamicky definovateľné role atď.)

Objavujeme objavené

Asi neprekvapí, že snaha o riešenie tejto výzvy je obhjavovaním už objaveného. (Takto by som charakterizoval aj celé toto vývojárske obdobie :-) Hovorím napr. o zapojení messagingu/eventingu na úrovni GUI. Toto bolo v tej či onej podobe súčasťou pôvodného MVC patternu. Postupne nás však tvorcovia väčšiny GUI frameworkov od využívania messagingu a nízkej previazanosti vzďaľovali, čo bolo iste správne z pohľadu jednotlivých základných widgetov, ale nie z pohľadu celej aplikácie. Napr. v prípade model2 webovej aplikácie (a to bolo úplne pochopiteľné) sa messaging stratil úplne a vo winforms bol zabalený v ovládacích prvkoch a málokto ho využíval na vyššej úrovni a napr. MVVM tiež s medziwidgetovým messagingom nepočíta. Opačným javom bol dôraz na nízku previazanosť a testovateľnosť tam, kde nemala veľký prínos, ale znamenala veľký nárast pracnosti a komplexnosti kódu.
Udalosti resp. správy reprezentujúce udalosti však nie sú zaujímavé len z hľadiska medzikomponentovej komunikácie, ale aj z hľadiska napojenia aplikácie na doménový model. Používateľ bol často uväznený vo svojej inštancii GUI. Ak sa chcel dostať k dôležitým informáciám a udržiavať si prehľad o dianí mimo aktuálne riešenú úlohu, musel sa aktívne "preklikávať" cez aplikáciu, miesto toho, aby ho sprostredkovávala aplikácia ako "na dlani".

Multithreading a JS

Keďže sa chceme baviť o javascripte, len v krátkosti konštatujme, že okrem asynchrónneho vykonávania a spracovania(ako best practice) http requestov nám všetko (zatiaľ) pobeží v jednom vlákne. Toto je však postačujúci kompromis pre kvalitné a reponzívne GUI, ktoré samozrejme na seba neberie viac zodpovednosti, ako je nevyhnutné.

Microsoft a moderné GUI - Project Silk

Web Guidance team vyprodukoval v rámci interného vývoja niečo, čo v zámere ide presne tým istým smerom, kam som mieril v posledných mesiacoch ja. Milá náhoda, na ktorú ma včera upozornil kolega. Spomínaný projekt dostal názov Silk. Projekt využíva JQuery. V mnohom s konkrétnymi prístupmi pri designe aplikácie nesúhlasím ale pointa je dobrá.
Tiež je to ďalšia dobrá správa vo svetle pivo diskusií so Slavofom a Mirkubom, že v Microsofte sa na js frameworky v najakej miere myslí (keďže MS uspal Asp.Net Ajax a súčasné JQuery dobrodružstvo z pohľadu enterprise aplikácií neberiem vážne).
V prípade, že sa dočká framework pokračovania, autori sľubujú, že sa budú viac sústrediť na MVC prvky a uvažujú o zapojení knockout.js frameworku.

 

Netreba čakať čo a či niečo vymyslí MS

Návrhu GUI frameworku, ktorý by spĺňal už niekoľkokrát v článku zopakované kritéria som sa v poslednej dobe relatívne dosť intenzívne venoval. Uvediem schému jedného z možných prístupov. Upozorňujem, že určite nebude vyhovovať resp. zodpovedať špecifikám každej aplikácie. S architekúrou sa dá naozaj pohrať a treba ju vždy citlivo prispôsobiť. Určite prvým negatívnym pocitom väčšiny nezainteresovaných bude zložitosť návrhu. Áno, v istom zmysle je to zložité, ale pri projekte väčšieho rozsahu to môže pomocť eliminovať paradoxne iné formy neudržateľnej komplexnosti kódu, ktorá zabíja väčšie projekty a pomáhať pri dobrom zvládnutí jednotlivých častí designu produktivite, testovateľnosti, zníženiu chybovosti, rozširovateľnosti, udržovateľnosti atď. 

  

Main Presentation Model

Hlavný aplikačný presentation model, ktorý zodpovedá za klientskú aplikačnú infraštruktúru a jej stav, teda všetko, čo sa týka aplikácie ale nesúvisí s doménovou problematikou. Je zaujímavé najmä z pohľadu tých widgetov, ktoré riešia základné infraštruktúrne veci, navigáciu, kontainery iných špecializovaných widgetov, stavový riadok a pod. Tieto wigety môžu poslať PM command(zmena konfigurácie, aktivovanie iného widgetu), počúvajú na zmeny v presentation modely (napr. cez observer pattern, zmena aktuálne focusenutého tasku, zmena konfigurácie a pod.) a prípadne získavajú údaje (aktuálny používateľ, konfigurácia, zoznam dostupných aplikačných taskov/činností, navigačná hierarchia a pod.) Okrem toho PM rieši veci ako inicializácia aplikácie a pod.
Ak posiela command voči remote facade, tak len v prípade, že treba sperzistentňovat stav na servery a read sa deje za účelom načítania týchto perzistetných dát. Všetko ale mimo doménovú problematiku. Uvažovať o subscribenutí PM na model, ktorý by riešil tieto veci nemá zväčša význam.(hraničné prípady, keď treba napr. okamžite reagovať na lockenutie usera adminom, zmenu členstva v roliach a pod.)

Widget

Môže ísť o rôzne zamerané widgety. Jednak o tie, ktoré som už spomenul a súvisia so základnou aplikačnou infraštruktúrou a ktoré majú vzťah len ku hlavnému PM. Potom sú to viewy samotných aplikačné taskov(formuláre, aplikačné činnosti). Tu je zvačša praktické riešiť presentation model implicitne prípadne ako embedded(teda tak, že widget má asociovaný práve jeden PM). Tasky už zväčša riešia veci na úrovni domény a teda posielajú commandy, ktoré spôsobia nakoniec nejakú zmenu stavu v doménovom modely. Majú prístup ku aktuálnemu stavu doménového modelu a čo je veľmi podstatné z hľadiska interaktivity, dokážu počúvať a reagovať na doménové udalosti, ktoré publikuje doménový model po zmene stavu. (pribudol kredit na (mojom) účte - aktualizujem zobrazený aktuálny stav na účte, zákazník zrušil konkrétnu objednávku - zobrazím warning ak ju práve vybavujem a pod.). Zároveň takéto widgety dokážu prostredníctvom aplikačného message busu komunikovať s inými widgetmi. (V zozname spoločností jednu označím a špecializovaný mapový widget, ktorý na danú udalosť počúva okamžite vyznačí najkratšiu k miestu určenému adresou firmy a zazoomuje). Takýto widget je vlastne treťou najbežnejšou skupinou - teda nejaký špecializovaný gadget, z akých si môžem rozšíriť pracovnú plochu aplikácie a ponúkajú mi dodatočné informácie, buď k aktívne riešenému tasku alebo stručný prehľad o dôležitých veciach aj mimo kontext tasku.

Applikačný Message bus

Rieši medziwidgetovú komunikáciu popísanú vyššie a rovnako sprostredkováva widgetom doménové udalosti. Čo sa týka konkrétnej realizácie tejto druehej zodpovednosti, ide z pohľadu javascritu o výzvu. Okrem long pollingu nie je k dipozícii momentálne žiadne ľahko dostupné riešenie.(SignalR framework je možným riešením aj vo vzťahu ku web sockets) 
Druhým problémom je to, či riešiť subscription na klientovi, a to by znamenalo transfer všetkých doménových udalostí na každého klienta alebo na servery, čo chce zase riešenie subscribeovania sa na servery a riešenie delivery do konkrétnej inštancie klienta. Ani problém s bezpečnosťou nie je úplne triviálny.

Remote facade

Skladá sa z troch častí, ktoré netreba nutne fyzicky oddeliť. Prvá zodpovedá za posúvanie alebo v jednoduchšom prípade rovno vykonanie commandov, druhá za obsluhu query dotazov z klienta a tretia prípadne za sprostredkovanie doménových udalostí.

Doménový model

Rieši problematiku business domény. Dôležitá je tu schopnosť generovať doménové udalosti.(v zábere článku je dôležitá možnosť viewov reagovať na tieto udalosti, ale tu ich možné využitie a prínos zďaleka nekončí, dá sa cez ne riešiť budovanie samostatného query storage cez denormalizéry, interdoménová komunikácia a využitie pri integračných scenároch a pod. ale to je už zase iný príbeh)

DB

Dátové úložisko :-) SQL / NoSQL čo len chcete 

Já chci sempl!

V dohľadnej dobe nebude. Čo ale asi bude a je teraz kôly príjemným rodinným starostiam zatiaľ len spiacim prototypom, je RavenDB Web Management Studio. To ale postráda doménovú vrstvu a teda pokrýva tento design len čiastočne.

P.S. Kto si to fakt prečítal celé, ruku hore, má u mňa pivo :-)