A Sun megnyitotta a JavaServerFaces implementációját

Ez a PR bullshit, ja. Egyebkent total mas megkozelites mint a struts (szoval nem hasonlo :), de component-approach frameworkbol is van sokkal jobb (wicket v tapestry pl). Igaz, ezek nem szabvanyositottak, viszont nem is papiron fejlesztettek ;)

Ha annyira ismered ezt a PR bullshitet, akkor tudhatnád, hogy eléggé hasonlít a Strust-ra, tekitve hogy a Struts alkotógárdája jelentős részét adta a JSF munkacsoportnak, akik "papíron" kidolgozták. Nyilván lehet még jobbat alkotni, nyilván fognak, mint minden szabványnál. Ha meg fejlesztesz mindkettőben egy példánál többet, akkor fel is ismered, hogy milyen Strutsos fogalom hol helyezhető el a JSF-ben :).

Tudom, hogy a többség idegenkedik az új dolgok megtanulásától, de azért azt jól látni, hogy "ezt a hülye ***** szabványt, aminél vannak sokkal jobbak is" a nagy cégek elég komoly eszközökkel támogatják... :)

wicket nekem is tetszik, tapestry meg nem skalazodik:) komoly, kollegak kimertek egy projektben...

jsf meg szabvanyos - van tobb egymastol fuggetlen implementacio - most mar tobb open source is. es konnyu hozza kattintgatos, vizualis fejlesztoeszkozt csinalni, amit lehet mutogatni Visual Studio .NET-hez szokott nepeknek, amikor azt mondjak, hogy a Java bonyolult...

Struts-hoz meg azert szoktak hasonlitani, mert a JSR specification lead-je ugyanaz a faszi volt (Craig McClanahan), aki a JSF process kb felenel lett Sun alkalmazott... meg most is az, sot blogol is.

Mondjuk úgy, hogy a tapestry összesz@rta magát egy 4 processzoros (4 * dualcore) vason, és az egész alkalmazás 2 szer szarabbul futott miatta, mint egy feleakkora vason. :)

Errõl az esetrõl beszéltél Joel, ugye? :)

kezdjuk a vegerol:

- nem idegenkedek uj dolgok megtanulasatol.

- a struts hagyomanyos request alapu mvc framework, a JSF komponensalapu, pont ez a ket teljesen ellentetes megkozelites valamelyiket alkalmazza a legtobb webes framework

- a struts alkotogardaja dolgozott a JSF-en tobbnyire, igaz.. ettol meg nem lesz a ket cucc hasonlo, mondhatni semmi koze hozza

- ettol a nagy cegek komoly eszkozei dumatol konkretan falnak megyek. ez a tipikus milliard legy nem tevedhet hozzaallas, az EJB1/2 aszerint ***** aki hulye hozza es hasonlo szovegekkel. az egesz enterprise dev tool support dollarmilliardos piac, trivialis hogy nagycegek nem hajigaljak ki az osszes befektetesuket mihelyt rajonnek hogy zsakutcaban bandukolnak a vege fele. amig ez egyertelmu lesz a milliard legynek, addig is eladnak par appservert

- az egyik JSF spec lead konkret velemenye szerint az egesz cucc a tool vendoroknak lett tervezve, nem a developereknek. ertsd: lehet jo sok csicsas osszerangatos editorokat irni meg eladni nagysebesseggel... ennyi.

wicket jopofa, de meg messze nem mature.. tapestry (meg hlship ur) konkretan nagyon nem szimpatikus de hogy skalazhato-e azzal vitatkoznek: TSS azon fut 2005 januar ota, szerintem nem kis terheles alatt..

Oké, ha számodra a komponens-alapú illetve nem-komponens alapú különbség már azt mondja, hogy semmi hasonlóság nincs közte, akkor elfogadom. De azért ha elkezdjük felsorolni a különböző tulajdonságokat, mint pl. validation, i18n, page flow, scope-ok, akkor elég sok közös dolgot látsz, amelyek szinte ugyanúgy vannak elnevezve, ami persze így átgondolva annyira nem nagy meglepetés. Lehet, hogy rossz a megközelítésem, de én a JSF-et evolúciósan a Struts-ból származtatom, de akár származhatna másból is. Átnézték a korábbi rendszerek tapasztalatait, és levontak belőle egy következtetést. Nézem én is korábban pl. tapestry-t, bár végül nem választottam fejlesztéshez, az egész ízlés és támogatás dolga. Azonban ha valamiben kialakul a szabvány, akkor célszerű azt használni.

Persze itt is megvan a hype görbe, ahogyan EJB-nél is megvolt. Annyiból jobb a helyzet, hogy most már az elején látszódott, hogy milyen célterületre rakták a technológiát, míg EJB-nél a nagyon erős tranzakciózás és a nagyon populáris objektum-perzisztencia elkülönítése nem volt mindenkinek triviális. Persze, a tool vendoroknek nagyon jó a cucc, de ugyanolyan jó dolog arra is, hogy a Delphi és ASP kódereket átcsábítsák, mert van végre felhasználóbarát eszköz.

Nem kevésszer nem is jön be :)

Hű mi lett itt...

zwei: igen, arra az esetre gondoltam.

dyn: bocs, nem írtam oda, hogy vertikálisan:) Szóval valami nagyon durva szinkronizációs problémával rendelkezik a framework, 1-2 CPU utan teljesen letörik a skálázódása.

JSF eléggé megosztja a fejlesztőket, de lehet IDE nélkül is fejleszteni benne (a backing bean-ek sima POJO-k (na ezt a részt mindig is utáltam a Struts-ban), raadasul XML file-ban kell leirni, hogy milyen szinten (request/session/app) tarolodjanak... A navigacio szerintem sokkal korrektebb, mint a Struts-ban volt. Ami nem tetszik, az az alap JSP-hez valo ambivalens viszonya... Marmint, hogy taglibkent hasznaljuk, de JSTL-lel tisztara inkompatibilis (bar tudom, minek kellene keverni a ket technologiat egy lapon belul, meg kulonbenis a kovetkezo JSP szabvany megoldja ezt a diszkrepanciat). Ha van tool, akkor az mondjuk pont a JSP-vel valo szenvedest rejti el a felhasznalo elol...

Es igazabol ugy vagyok vele, hogy ha az egysegsugaru user MS Access meg Visual Basic helyett egy JSF tool-lal dobalja ossze a kis reportgeneralo vagy adatbeviteli alkalmazasat... az mindenkinek csak jo.