Tady posilam sve historicke poznamky, ktere jsem si delal pro Dagiho
podcast a taky pro sebe pri pruzkumu teto technologie. Treba to nekomu
pomuze. Par veci co jsou v textu sice nejsou z dnesniho pohledu uplne
presne, ale....
Eclipse RAP:
*******************************************************
History (od Jochen Krause):
RWT (RAP widget toolkit) vzniknul puvodne z projektu W4T (www window
toolkit)od Innoopracts
(dalsi Innoopracts projekt: Yoxos enterprise edition). Prvni release W4T
vysel v prosinci 2001 a cilem
bylo vytvorit java web vyvoj jednodussi. V te dobe to byla docela
revolucni vec v provnani se soudobymi
frameworky pro UI. Byl vytvoren i plugin na podporu vyvoje - W4T Eclipse,
ktery se stal docela popularni.
Nicmene W4T nebyl standard a Innoopract pokukoval po JSF. Chteli/stvorili
(??) JSF kompatibilni
implementaci, ktera ale byla zahozena/zrusena, protoze dosli k zaveru, ze
API komponent je prilis slozite
a nepruhledne. Udelali jen lifecycle management W4T podobny tomu v JSF a v
roce 2005 pridali knihovnu
pro ajax requesty. Ajax umoznil rozjet vyvoj konceptu workbench->plugin na
webu. V lete 2005 byl uspesne implementovan
a predstaven koncept "web workbench" zalozeneho na OSGi ve webovem
kontejneru. Stale se bavime o implemntaci W4T.
RAP byl ohlasen v breznu roku 2006 a jako Eclipse project byl zarazen na
konci cervna 2006. Stale trval plan
vytvorit pomoci W4T workbench implementaci jako widget toolkit. Velice
brzy vsak bylo zjisteno, ze Eclipse komunita
preferuje SWT API z mnoha ruznych opodstatnenych duvodu (ne proto ze W4T
API bylo spatne, ale hlavne pro vyhodu SWT ve
znovupouziti kodu a v male learning curve). Zacalo se tedy s reimplemntaci
komponentove vrstvy s SWT API a pro klientskou
stranu bylo zvoleno Qooxdoo. S pomoci komunity a po pripojeni Steva
Northhovera byl v breznu 2007 predstaveno RWT jako
podmnozina SWT.
TECHNOLOGIE pouzite v Eclipse RAP
--------------------------------------------------------------------------------
Eclipse RCP (Rich Client Platform)
Jde o velice robustni framework postaveny nad OSGi. RCP je lety
proverena
technologie, ktera ma za cil usnadnit vyvoj novych, velice
komplikovanych
aplikaci v mnoha oblastech (GUI, event model, rozsiritelnost,
customizace).
Vzorovym prikladem je samotne Eclipse IDE postavene nad Eclipse RCP.
Diky pouziti Eclipse RCP v Eclipse RAP se tak dostava do rukou tvurcu
webovych
aplikaci velice mocny nastroj, ktery jiz na urovni RCP resi takrka
vsechny pripady,
ktere se v intranetovych aplikacich dnes resi - komponenty, view,
eventy,
customizace.
Qooxdoo - http://qooxdoo.org
Pro GUI na strane klienta pouzita knihovna Qooxdoo. Qooxdoo je
javascriptovy
framework, ktery umoznuje psat komplexni GUI aplikace. Od tvurce
takove GUI
aplikace neni vyzadovana znalost HTML ani CSS, vse je ve sprave
Qooxdoo
(dale jen QX). Tento model, kdy vyvojar pouziva pouze JS tridy QX k
vytvoreni
GUI je velice prijemny. V podstate jde o stejny typ prace jako kdyz se
pracuje
v Jave se swingem nebo s SWT, pripadne v Dephi s VCL. QX diky
dynamicke praci
s DOMem lehceji smazava rozdily mezi klientskymi prohlizeci (event
model, box
model) QX ma IMHO velkou budoucnost a jiz dnes ve verzi 0.7.2 maji o
tento
framework zajem vetsi firmy (Eclipse RAP, Delphi for PHP, ASP.NET).
bodove:
- Qooxdoo zastresuje firma "1&1 Internet AG" (velky hostingovy
provider)
- Qooxdoo je aktivne vyvijeno - iterace minor verze (0.x) kolem 3/4
roku
- postavene na AJAXu, vlastni RPC (remote procedure call)
- skinovani
- Vyborna dokumentace
- SDK nastroje pro optimalizaci samotneho QX na konkretni projekt.
- Rozsahla komunita
- LGPL || EPL
KLADY Eclipse RAP
--------------------------------------------------------------------------------
customizace/modularita
tato vlastnost ziskana diky Eclipse RCP + OSGi je v ostatnich
konkurencnich frameworcích velice tezko dosazitelna, az nemozna.
Nedokazu si
vubec predstavit, jak napriklad v JSF pripravit customizace alespon
vzdalene
takove, jak nabizi RCP+OSGi. RCP je vyvijeno obrovskou komunitou lidi
a proslo
jiz nekolika verzemi a refaktor fazemi, ktere RCP ucesali do dnesni,
velice
pouzitelne podoby. Vytvorit neco podobneho napriklad v JSF je nemozne.
zapouzdrenost Qooxdoo v RAP
ten kdo pise RAP nemusi o QX vedet vubec nic
rychlost vyvoje
Diky Eclipse RCP je vyvoj oproti ostatnim technologiim (napr. JSF)
radove
rychlejsi
sjednoceny pristup
Diky RCP je sjednocen pristup k tvorbe cele aplikace. Prirozena tvorba
perspektiv,
view, editoru, event, extension pointu. Cele UI se pise v Jave a tim
se
vyvojar nemusi zabyvat dalsimi jazyky jako je HTML, JS, CSS.
ZAPORY Eclipse RAP
--------------------------------------------------------------------------------
fork Qooxdoo
to znamena, ze pri uvolneni nove verze QX nelze ihned v RAPu nahradit
QX vrstvu.
Takze pri novem release QX je nutne cekat az na to zareaguji tvurci
RAP a udelaji fork noveho release QX.
zapouzdrenost Qooxdoo v RAP
zde jako nevyhoda, protoze tou zapouzdrenosti se ztraci moznost ohybat
RAP
pro nase potreby na urovni QX. Respektive to asi lze, ale nebude to
uplne
spravna cesta a hlavne to vyzaduje hlubokou znalost RAPu i QX.
vzhled aplikace
diky zapouzdrenosti QX v RAP nema vyvojar moznost vyrazneji ovlivnit
vzhled
aplikace v nem napsane. RAP zpristupnuje nekolik malo skinovatelnych
polozek,
ktere v soucasne verzi hrube nedostacuji mojim narokum. Lze ale
ocekavat, ze
v dalsich verzich RAPu dojde v tomto ohledu ke zlepseni. Samotne QX ma
vybornou
moznost skinovatelnosti.
POZNAMKY
--------------------------------------------------------------------------------
nezname presne memory footprint RAPu na strane serveru
docetl jsem se o 100MB ram na 500 soucasne pracujicih uzivatelu, coz se
mi
osobne nezda moc realne, ocekaval bych vyrazne vice.
tvurce RAPu hovori o typicke response size kolem 300bytes, coz je az
neuveritelne
priznive cislo. Overeno a udaj souhlasi.
Pro predstavu: ze stareho Airyprot (JSF+A4j) jsem nevyrazil mene nez 5kB
na response a to bylo v situacich, kdy jsem v responsu nemel zadnou
aktualizaci
visualnich prvku. V RAPu ma i response s aktualizaci dat tabulky kolem
1kB.
RAP by mel setrit sitovy bandwith cachovanim requestu na klientu a
odeslanim
az v okamziku, kdyz uz je nezbytne server o zmenach informovat. tezko
overitelne
se soucasnymi znalostmi RAPu.
Zatim vubec netusim jak presne RAP naklada s jednotlivymi scopes
(request scope,
session scope, application scope). Otazkou je, jestli vubec RAP neco
takoveho
umoznuje. Je docela mozne ze vyvojar v RAP k problemu scopes pristupuje
znacne
odlisne. Privadi to na myslenku kde pak vzit/ridit conversation scope,
pripadne
bussiness scope. Zatim nejasne.
Eclipse RCP je ultra mazec a je to neco, co se clovek nenauci pres noc.
Zas na druhou stranu uz s malem vedomosti jsem schopen vytvaret to co
jsem v JSF
a navaznych technologiich byl schopen delat az po nekolika mesicnim
uceni.
QX zavadi svuj system prekladu. Zatim nevim, kolik z toho je pravzato do
RAPu.
RAP ma hodne malou dokumentaci, ale zase relativne zivou komunitu a
prijemne
developerske forum.
Ucit se RAP, znamena ucit se RCP a RCP ma dokumentace mraky. V soucasne
dobe
zvlada RAP jen omezenou mnozinu RCP funkcnosti, ale cilem RAP je pokryt
kompletni
RCP. Hloupe je, ze dnes se tezko poznava hranice, co jeste z RCP mohu
pouzit a
co uz RAP nepokryva.
Diky tomu, ze vyvijime v Eclipse IDE, je velice sympaticke spousteni a
debugovani
RAP aplikace. Rychle, celkem nenarocne. Skoro bych se nebal rici, ze
lepsi nez
deploy pres Maven ve starem prototypu Airy.
