Zdravim,
Celkem pouzitelny se mi jevi Struts2, zalozeny na WebWorku. Co me zejmena
zaujalo:
- Struts2 nevyzaduje pouziti tech prisernych ActionForm formularu, kterych bylo
vzdy v projektu mraky a nic moc nedelaly. Clovek tedy mohl vve Struts1 pouzivat
dyna action formy, ale ty stejne musel minimalne registrovat v konfiguracnich
XML, jejichz velikost se rapidne zvetsovala a prehlednost zmensovala.
- Akce jsou ted POJO objekty, ktere neextenduji/neimplementuji zadny pochybny
inteface (-> jednodusi testovani), pri submitu formulare se setuji property
primo na te akci.
- Akce muze mit vice vykonnych metod libovolneho jmena (ne tedy jen jednu
metodu execute jako v Struts1), coz se mi jevi jako skvele pro CRUD akce, ktere
tak mohou byt soucasti jedne Action bez toho, ze bych akce musel rozlisovat
nejakym parametrem requestu a pak delat v execute rozskok apod. Metody v Action
se rozlisuji uvedenim jmena metody v URL (bud za !, nebo za / -
.../user.action!insert .../user.action/insert apod).
- Ze stranky je mozne akci volat akci primo bez toho, ze bych musel tu akci
volat nejak predem (tj. jit na akci pres jeji URL, tam vse ulozit do scope
promennych a forwardovat se na stranku, kde bych s temi scope promennymi dale
pracoval). Tj. napriklad naplneni obsahu comba hodnotama znamena toto:
<s:action id="po_list" name="po_list" namespace="/m/test" flush="false"/>
<s:form action="po_dump" namespace="/m/test" id="dump">
<table>
<tr>
<td>PO type:</td>
<td>
<s:select name="entityName" size="1" list="#po_list.entityNames"
value="#po_list.selectedEntityName"/> <-- zavola na akci po_list metody
getEntityNames() a getSelectedEntityName() -->
</td>
- Podpora namespacu akci. Namespacy se mohou extendovat, cimz se daji akce lepe
organizovat (spolecne sdilene akce vs. specificke akce). Struts1 mely neco
podobneho v podobe "modulu", ale ty namespacy mi prijdou dotazenejsi.
Par mensich much Struts2 jeste ma, ale uz existuje stabilni produkcni verze.
Honza
-----Původní zpráva-----
Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za uživatele Jiøí Chaloupka
Odesláno: Friday, March 23, 2007 07:28
Komu: Java
Předmět: Re: Jakarta Struts ?
Souhlas, nicméně bych na to pohlížel ještě z jedné strany.
Pokud je nějaký projekt vyvíjen soukromou osobou mimo korporátní podporu, hrozí
Vám v případě, že ta osoba na projektu přestane pracovat a nikdo její práci
nepřevezme, že po čase budete muset přepisovat kus aplikace jenom proto, že
vyvstane nutnost přechodu na novější platformu, přičemž starý kód na ní už
nebude fungovat (příklad - IT zákazníka se rozhodne přejít na novější verzi
aplikačního serveru a dá vám řekněme půl roku, aby jste aplikaci na nové verzi
vyzkoušel a případně upravil). Příklad kdy se něco takového stalo, byť tak
trochu v uvozovkách, je ReiserFS.
Na druhou stranu, pokud se přidržíte knihoven a postupů v oficiálních větvích,
je pravděpodobnost toho, že k něčemu podobnému dojde, znatelně nižší. Kolega tu
uváděl EJB2.0, konkrétně entity beany. Jasně že dnes je Hibernate EJB3.0
podstatně dál, ale entity beany jsou přesto velmi dobře použitelné a jsou
podporovány všemi aplikačními servery dnes a troufám si tvrdit, že ještě pár
let podporovány budou.
Čili zvažoval bych to i z tohoto pohledu, ale v daném případě záleží kdo je Váš
zákazník a jestli záleží na Vás, na čem ta aplikace poběží, nebo jestli v tom
máte jen "doporučující slovo"
Jirka
Martin Kuba napsal(a):
Jiří Hradil wrote:
Dobrý den Martine,
Stripes jsou velmi hezké a jednoduché-nasadil byste je však do
produkčního prostředí (stabilita, řešení problémů)? Obávám se trochu
dalšího vývoje, JSF od Sunu jsou sice složité, ale z dlouhodobého
pohledu se mi právě JSF jeví jako stabilní a podporovaná platforma.
Odpovědí se bohužel musím posunout do oblasti dojmologie.
Když je něco jednoduché, tak to taky má tendenci být stabilnější
a případné problémy jsou řešeny rychleji, než u složitých řešení.
Že je něco podporováno nějakou velkou firmou není záruka ničeho.
Hraju si s webovými aplikacemi touhle dobou deset let, a pamatuju
se například na dobu, kdy firma IBM propagovala svůj
webový server ICSS (IBM Internet Connection Secure Server)
jako ten správný server, a ostouzela Apache. A ejhle,
do dvou let IBM zahodila ICSS, a začala používat a propagovat
Apache, protože byl *lepší*.
Stejně tak si firma SUN vymyslela Entity Enterprise Java Beans,
a asi osm let je propagovala jako to správné řešení,
aby nakonec uznala, že to nikdo nechce používat a všichni používají
Hibernate, a EJB v poslední verzi místo Entity EJB používají
JPA, což je přejmenované API od Hibernate.
Co se týká webových aplikací, tak SUN vymyslela servlety, což
byla dobrá věc. Ale pak si vymyslela JSP se skriptlety,
což byla špatnost a reakce na vznik Mikrosoftích ASP,
a propagovala je dlouhá léta. Až nakonec musela uznat,
že skriptlety jsou špatnost a pod tlakem úspěšných Struts
vytvořila JSTL tagy (podle Strutsích JSP tag libraries)
a přidala EL jazyk, který IMHO převzala ze Strutsů,
které ho převzaly z Freemarkeru. V době, kdy SUN
propagovala JSP verze 1.0, bylo zdaleka nejlepší
používat Freemarker.
Čili věci podporované SUNem jsou možná stabilní v tom smyslu,
že z důvodů zpětné kompatibility budou použitelné
i v budoucnu, ale není pravda, že je proto dobré je používat i
když existují lepší řešení, protože ta lepší řešení se časem
prosadí a SUN je bude muset akceptovat.
Makub
