Ahoj, pro 2 doporucuji RIA framework ZK www.zkoss.org: tez je mozne psat RIA bez znalosti JS a CSS jako u GWT. Pro pripad hackovani jednoduchy kod, JS psano normalne. Integrace se Springem, CDI. Nevyhoda je ze je placeny (zdarma je jen CE verze, ktera je ale take dobre pouzitelna.) Tez se podivej na rozsireni ZK-DL pochazejici z ceskych luhu a haju.
2011/9/27 x y <[email protected]>: > *********** >>add Single page application(SPI) > z mojho pohladu pre richwebapp so stavom na klientovy(single page) vidim v > sucastnosti 2 alternativy: > 1.gwt way: gwt + springMVC(mozno tiez roo) +hibernate) > 2.web standard way: > front(UI+UI logika): MVC JS framework + HTML + CSS; vymena dat:json > backend: service tier- RESTove service metody + persistencia(Dao+entity) > 1.GWT: > vhodnost: ludia ktory robili so swingom(a nakladny je prechod na > webstandardy) > //vyhody: nieje duplicitny kod, rovnaky jazyk na servery a klientovy(to > nevnimam ako zasadnu vyhodu) > //nevyhody: > -v pripade rozsirenia tymu relativne vyssie ludske naklady(predsalen > najat JS developera je odost menej nakladne a rychlejsie, ako gwt > developera) > - potencialne problemy s udrzatelnostou z dovodu nedoladenosti > technologie(kompilatora) > 2.webstandard way: > //vyhody: > -Vyhodu vidim v tom ze clovek "vie co sa deje" (teda ma system pod > kontrolou), nieje problem customizovat, a moze pouzivat pokrocilejsie > techniky javascriptu a API(java je predsalen trochu pozadu, aj ked sa to > lepsi). > -negacia nevyhody GWT (teda nizsie ludske naklady v pripade rozsirenia > tymu) > //nevyhody: > -vyznamnou nevyhodou uvedenej webstandardovej alternativy bude zrejme > vyssia pracnost kedze cast kodu bude duplikovana na klientovy, a serveri > (triedy, validacia) => co moze byt pri editacii,rozsireniach dost > spomalujuce a error prone. Vidite aj vy tuto nevyhodu natolko kriticku, ze > je tato websatndard way prakticky nepouzitelna ? > -nevyhodu pouzitia 2 jazykov nevnimam ako podstatnu > ******* >>ad projekt > co sa tyka nasho projektu tak: otazka je aku technologiu zvolit ak je ciel > spravit rich app(prevazne singlepage), ide o startupovy projekt a tym nema > problem sa naucit hocijaku technologiu. (btw nemame skusenosti s GWT). > V pripade 2. webstandard cesty aku technologiu by ste odporucali na backend, > myslim ze mvc framework(napr. SpringMVC) je zbytocne kedze controller nieje > potreba, taktiez view je v podstate datovy typ skonvertovany do jsonu. > Microsoft ma WCF, ktory by mal riesit taktu poziadavku (teda riesi servisnu > a persistentnu vrstvu), je nijaka takato pouzitelna technologia aj v jave ? > ****** >>ad reakcia na studiu thoughtworks.com > "GWT attempts to hide many of > the details of the web as a platform by creating desktop > metaphors in Java and generating JavaScript code to > implement them." > -ano GWT nahradza klasicku web komunikaciu za RPC, no co z tohto tvrdenia > vypliva, ma RPC niejake obmedzenia voci klasickej web request/response > alternative ? > "Third, it suffers from > the same shortcomings of many elaborate frameworks, > where building simple, aligned applications is quick and > easy, building more sophisticated but not supported > functionality is possible but difficult, and building > the level of sophistication required by any non-trivial > application becomes either impossible or so difficult > it isn't reasonable." > -v com konkretne su tie obmedzenia pri budovani komplexnych aplikacii? > Nerozumiem velmi tym narazkam lebo ked chceme klient a server pisat v jednom > jazyku a neduplikovat kod(teda eliminovat uvedenu kriticku nevyhodu u > web.standard.way) jedinou moznostou z mojho pohladu je RPC, alebo je aj ina > rozumna alternativa ? > > > > > > > > 2011/9/26 Lukas Barton <[email protected]> >> >> No vzhledem k defektum v samotnem kompilatoru je obcas nutne debuggovat >> ten vygenerovany Java Script, a to je opravdu lahudka. >> Stejne tak profilovani nema cenu delat v hosted modu. >> Lukas >> >> 2011/9/26 Vladislav Krejcirik <[email protected]> >>> >>> Vygenerovany JS lze debugovat v Eclipse kdyz mate nainstalovany GWT >>> plugin. >>> >>> On Mon, Sep 26, 2011 at 11:12 AM, Peter Hanuliak >>> <[email protected]> wrote: >>>> >>>> otazka znie, ci ste zbehnuty v tomto frameworku, alebo nie >>>> pokial mate know-how tak viete ake problemy nastanu a ako ich budete >>>> riesit + viete dopredu lepsie odhadnut narocnost >>>> >>>> >>>> On Mon, Sep 26, 2011 at 10:33 AM, x y <[email protected]> wrote: >>>>> >>>>> Chcem sa spytat na skusenosti s GWT na projektoch(Vyhody/nevyhody). Ci >>>>> ma v dnesnej dobe zmysel postavit projekt na tejto technologii, ak ma tak >>>>> v >>>>> akych pripadoch ju zvolit/nezvolit. >>>>> Podla http://www.thoughtworks.com/radar zjavne GWT nieje dobrou >>>>> volbou. Citujem: >>>>> GWT is a reasonable implementation of a poor >>>>> architectural choice. GWT attempts to hide many of >>>>> the details of the web as a platform by creating desktop >>>>> metaphors in Java and generating JavaScript code to >>>>> implement them. First, in many ways, JavaScript is >>>>> more powerful and expressive than Java, so we >>>>> suspect that the generation is going in the wrong >>>>> direction. Secondly, it is impossible to hide a complex >>>>> abstraction difference like that from event-driven >>>>> desktop to stateless-web without leaky abstraction >>>>> headaches eventually popping up. Third, it suffers from >>>>> the same shortcomings of many elaborate frameworks, >>>>> where building simple, aligned applications is quick and >>>>> easy, building more sophisticated but not supported >>>>> functionality is possible but difficult, and building >>>>> the level of sophistication required by any non-trivial >>>>> application becomes either impossible or so difficult >>>>> it isn't reasonable. >>>> >>> >>> >>> >>> -- >>> >>> /**************************************/ >>> Best regards / S pozdravem >>> Vladislav Krejčiřík >>> >>> http://www.vkrejcirik.info >> > > -- Ondra Medek
