25.1.2010

Emulovanie java tried v GWT

Naposledy pri jednej nezáväznej debate pri dobrom pivku sme narazili na situáciu ako riešiť problém Command patternu v GWT. Celkový problém spočíva v tom, že klient (rozumej javascript, alebo skompilovaný GWT Java kód) zostrojí lightweight verziu Command objektu na GUI (s naplnenými dátami), pošle sa na server - či už pomocou RPC, alebo JSON (alebo telepaticky, v princípe je to jedno :) ) , na serveri sa zostrojí už plnohodnotná inštancia triedy so serializovanými dátami a daný Command sa vykoná a poprípade vráti výsledok späť na klienta. V princípe existuje viacero riešení, otázkou je čo uzná GWT špecialista-odborník za najvhodnejšie :). V princípe ma napadá hneď niekoľko riešení:
  • Vytvoriť "custom field serializer" pre dané command-y, ktorý bude zodpovedný za deserializáciu serializovaného objektu a jeho korektné nainštanciovanie - nevýhoda je, že je potrebné pre kazdý command vytvárať vlastný deserializér, čo v princípe nie je nejaký extra problém ale je to celkom otrava a celkovo ... na čo ? keď sa to dá aj jednoduchšie.
  • Nejakým zázrakom cez aspekty zneuctiť proces GWT deserializácie a inštanciovanie presunút do vlastnej réžie (Igor alebo Michal ... nepodelíte sa o svoje riešenie ? :) ) - výhody sú nesporné - jedna univerzálna trieda pre inštanciovanie všetkých Commandov
  • Využiť proces emulácie java tried a vytváranie ich lightweight verzie na klientovi - je to oficiálny postup aj zo strany GWT, odskúšaný praxou a celkom zaujímavé riešenie. Jediným problémom môže byť to, že treba serializované položky leightweight a plnohodnotnej verzie commandu udrziavať synchrónne - to znamená, že keď pridám novú položku do commandu, musím ju pridať na 2 miestach, kvôli serializácii na klientovi (1 miesto) a kvôli deserializácii na serveri (2 miesto). Toto však v dnešnej dobe nie je žiadny problém, pretože doménová oblasť je pred implementáciou dôkladne zmapovaná, požiadavky korektne zanalyzované, softvér bezchybne navrhnutý, takže nehrozí, že by počas implementácie nastala zmena v požiadavkách alebo zmena v rozhraní daných Command objektov ;). Mimochodom kompletný článok je možné nájsť na wiki stránkach acris-u: GWT Emulation.

5 komentárov:

Igor Mihalik povedal(a)...

Samozrejme, ze postup s pouzitim aspectj blizsie popiseme. Hoci si nemyslim, ze ide o "zneuctenie" deserializacie GWT. Oaspektovanie tried sa deje na urovni bytecode-u a je uplne jedno, ci je to GWT trieda deserializera alebo akakolvek ina java trieda pokial je to v sulade s liskovym substitucnym principom (co v nasom pripade je). Hlavna vyhoda IMHO je, ze odpada akakolvek potreba riesit duplicity v code ;)

peter.simun povedal(a)...

Ano, ano. Tie nestastne duplicity ... lenze tak, ci tak musis mat command triedu aj na klientovi aj na serveri, nie? Pokial to chapem spravne ide len o korektne instanciovanie potrebnej triedy. Pokial to chapem zle, tak ma tu prosim verejne vyfackaj :) [to, ze mam overovaci retazec "fight" nebude nahoda :) ]

Igor Mihalik povedal(a)...

Trieda je aj na klientovi aj na serveri, no trieda na serveri je podtriedou triedy na clientovi a teda uz obsahuje len samotnu logiku vykonania commandu.

peter.simun povedal(a)...

musim uznat, ze je to navrhnute celkom pekne. Uz by ma zaujimal len ten aspekt :) V kazdom pripade dakujem za info

Vojtech Szocs povedal(a)...

@Peto, pozri projekt gwt-command-aspectj