Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: martin 20. 04. 2013, 20:31:27
-
Dobry den,
ucim se delat web v Jave. Zatim mam zkusenosti pouze se JSTL a Stripes frameworkem.
Shanim nejaky framework, ktery by mi dovolil tvorit webove aplikace vcetne GUI (abych si ho nemusel cele psat sam). Nasel jsem nekolik zajimavych frameworku. Nejvic me asi zaujal Vaadin (https://vaadin.com/home) - ukazky vypadaji opravdu dobre: Desktop (http://demo.vaadin.com/dashboard/), Mobil (http://demo.vaadin.com/mobilemail), tutorial s adresarem (https://vaadin.com/tutorial).
Pak jsem jeste nasel PrimeFaces (http://www.primefaces.org/). Podle ukazek (http://www.primefaces.org/showcase/ui/home.jsf) take vypada velice dobre.
Dale jsem nasel GWT (https://developers.google.com/web-toolkit/) (Google Web Toolkit). Neni moc navazany na Google App Engine (https://developers.google.com/appengine/)? Mam strach z vendor lock-in.
Jake dalsi existuji?
Rad bych podporu v IDE (idealne Eclipse, ale neni podminkou) a nejaky GUI navrhar, jako ma Vaadin (https://vaadin.com/image/image_gallery?uuid=ec1ca697-454d-4607-8af7-5ef0d0673b50&groupId=10187&t=1305548740828).
Vzhledem k tomu, ze studuji a mam relativne dost casu, rad bych se poradne naucil nejaky realne vyuzivany framework. Muzete mi prosim neco doporucit? Zajimaji me hlavne vyhody daneho reseni, jak moc se pouziva a slozitost na nauceni se.
Neradte mi prosim .NET, PHP, RoR a dalsi platformy! Zajima me Java.
Dekuji za rady!
-
Dale jsem nasel GWT (https://developers.google.com/web-toolkit/) (Google Web Toolkit). Neni moc navazany na Google App Engine (https://developers.google.com/appengine/)? Mam strach z vendor lock-in.
Pokud člověk nechce, tak Google App Engine použít nemusí. Na GWT mne překvapilo, jak snadno jde v případě potřeby pozměnit implementace nějaké jeho třídy, aniž by musel člověk upravit samotné GWT. Konkrétně jsem měl problém s DisclosurePanelem, neboť způsob, jakým implementoval schovávání obsahu, nebyl kompatibilní s java applety - po zobrazení obsahu se applet vždy znovu inicializoval. Vyřešil jsem to tím, že jsem upravil DisclosurePanel.java tak, aby používal jiný mechanismus skrývání, dal jsem ho k sobě do projektu a nastavil projek tak, aby upřednostnil mou implementaci před tou v GWT.
Ještě lepší příklad byly různé menu a okna (generované na stránce pomocí HTML) , které prohlížeč vždy zobrazoval pod obsahem java appletu. To jde vyřešit trikem, že se pod zobrazovaný obsah vloží iframe. Stačilo upravit PopupPanel.java, aby pod sebe přidával iframe a opět zařadit tento soubor do projektu. Tento upravený soubor pak začnou využívat i všechny ostatní třídy z GWT, takže najednou začalo s java appletem fungovat vše, co používá PopupPanel, tj. menu a "vyskakovací" okénka.
Ostatní frameworky neznám, třeba to nebude problém ani v nich.
-
ja som skusal jsf, gwt, vaadin, a apache wicket. Wicket mi prisiel najlepsi na to co som potreboval (viacvrstvova aplikacia s cca 300 obrazovkami, vela formularov a zoznamov pre cca 3000 subeznych pouzivatelov - 6 instancii vm)
vyhody:
komponentovy model (podobny ako asp.net webforms) - robi sa s tym lahko ako s desktop aplikaciami
malo js (resp kolko si das, tolko bude),
nie je zavisly na inych produktoch
rychlost,
pamatove naroky (ak neulozis do session co netreba)
jednoducha integracia so springom
html kod treba rucne napisat - lahko sa da vsetko ovplyvnit, preniest na mobil... (lahko sa robil design)
nevyhody:
horsia dokumentacia a tym padom sa to dlhsie uci
html kod treba rucne napisat - nenasiel som uspokojivy wysiwig editor
co mi vadilo na vaadine: zavislost na gwt pre view (veeela js), vyhoda: podpora programatorov (dokumentacia, editor,...)
co mi vadilo na gwt: horsia integracia s mavenom, milion javascriptu, vacsina bezi na klientovi
co mi vadilo na jsf: niektore spravanie sa nedalo zmenit, pamatove naroky.
-
Zkuste se podívat na ZK Framework - http://www.zkoss.org/. Má komponentový MVC, a MVVM model a poměrně slušnou dokumentaci, takže se v něm dobře píše. Problémy nastávají, když chcete psát v čistém HTML, občas vytváříte dost hacky kód. Pouze poslední verze podporuje HTML 5 (a to ještě ne kompletně).
-
Se Spring MVC, JSF, Wicket a GWT chybu neuděláš. Vaadin neznám, ale tipl bych si, že tu bude jeden z kupy "niche" frameworků - jakých je na Java platformě hafo (Tapestry, Play, Click...). Tyhle méně používané frameworky mají velmi podobné vlastnosti - mizernou dokumentaci, malou podporu na fórech, nutnost lézt do zdrojáků, nepřenositelný skill, frustrace, smrt.. :D
-
Chtěl jsem navrhnout ať se podíváte na Tapestry (a Caynne jako ORM). Ale podle některých je to "niche". Já zase neznám skoro vůbec wicket. Tak jen přidám jen odkaz na video, které by jste měl zhlédnout před tím, než začnete vybírat. http://vimeo.com/12650821 (http://vimeo.com/12650821). Mat Raible pravidelně publikuje srovnání různých Opensource Java web framworků. Poslední bude asi tady http://raibledesigns.com/rd/entry/comparing_web_frameworks_and_html5 (http://raibledesigns.com/rd/entry/comparing_web_frameworks_and_html5).
Napište prosím co jste na konec vybral a proč. Dobrá studie na téma výběru dobrého frameworku, bude určitě hodně lidí zajímat.
-
Nedalo mi to a lehce jsem zagooglil. Výběr nejzajímavějších materiálů:
http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/ (http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/)
http://blog.websitesframeworks.com/2013/02/web-frameworks-types-122/ (http://blog.websitesframeworks.com/2013/02/web-frameworks-types-122/)
Pak je ještě jeden rozměr, který jsem nikde v porovnáních neobjevil, ale myslím, že má svoji váhu. Je to integrace frameworku s ORM vrstvou. Myslím, že to je jeden z úhelných kamenů úspěchu RoR. Tedy, že vám automaticky poskytne model na základě metadat z DB a nemusíte jej tak vytvářet 2x ( jednou v DB a podruhé v Javě ).
-
Tak jsem se rozhodl pro JSF (Java Server Faces) v kombinaci s RichFaces / IceFaces / PrimeFaces.
Muzete mi doporucit nejake materialy pro uplneho JSF zacatecnika? Idealne v elektronicke podobe. Internet je plny ruzne starych a ruzne kvalitnich Hello world tutorialu, ale dost mi jich nefungovalo (asi moji chybou).
Jak je to s verzemi JSF? V hodne tutorialech psali o JSF 1.2. Ma to jeste dnes cenu, nebo jit hned do JSF 2?
Vsude slysim chvalu na kombinaci JSF+Spring. Je opravdu Spring tak nepostradatelny? Ma smysl se hned od zacatku ucit i Spring, nebo je lepsi zacit s cistym JSF a pozdeji treba pridat Spring? Ve Springu jsem nikdy nedelal.
-
Ahoj martine,
pokud zacinas s Webem v kombinaci s Javou, myslim, ze nejlepsi je zacit necim vlastnim a pěkně od píky. U toho pochopis vsechny souvislosti, ktere vsechny frameworky nejakym zpusobem poskytuji a řeší.
Podle meho nazoru pokud budes k necemu inklinovat bez zakladnich znalosti, budes delat zbytecne kroky a odradi te to. Pokud nejprve zvládneš základy, budeš se hned lépe orientovat v dokumentacích a snáz v ní budeš hledat, protože budeš znát terminologii i co přesně hledáš.
Zkus nastudovat a projit nasledujici material, ktery te provede zaklady a navrhne dobry zaklad webového MVC. Myslím, že jako start je to výborný materiál.
http://www.nplus1.net/java_web_programming.pdf (http://www.nplus1.net/java_web_programming.pdf)
Přeji ti hodně štěstí.
-
Se Spring MVC, JSF, Wicket a GWT chybu neuděláš. Vaadin neznám, ale tipl bych si, že tu bude jeden z kupy "niche" frameworků
Trochu mi tu v tom výčtu chybí Struts (resp. Struts 2), což je jeden z nejpoužívanějších. Zatímco Spring a Struts jsou založeny na tradičním modelu (buzzword je "action based"), Wicket je komponentový a tím pádem se více blíží desktopu. Vaadin je používá GWT na zobrazování a ani Vaadin ani GWT nejsou svázány s Google App Enginem.
Osobně bych doporučil se podívat i na Grails - jedná se o celkem přijemný framework pro Groovy (což je dynamický jazyk běžící na JVM). I když Groovy má hodně daleko k ideálu, je to příjemnější volba než Java, miminálně na zobrazovací modul aplikace. Kódit něco v jazyku Java ... neříkám, že to občas nedělám, ale vždy si připadám, jak kdybych se vracel o 10 let zpátky.
-
struts 1 treba nechat v hrobe, spring mvc ho radostne nahradi
jsf2 je uz dostatocne zrele, richfaces k nemu uz viacmenej tiez
spring na uvod az tak netreba, ten sa da do velkej miery nahradit JEE vecami (dependency injection a pod.)
-
Dost casto pada zminka o Struts 2. Jde opravdu o tak dobry a pouzivany framework, nebo se pouzival driv a dnes v nem ze setrvacnosti jede spousta projektu?
Co rikate na Stripes? Zda se mi jako vylepseny Struts. Mam provadu?
Ma dnes cenu zacinat v Struts/Stripes/Wicket, nebo jit rovnou na JSF/Spring?
Existuje pro Struts/Stripes/Wicket neco jako RichFaces/IceFaces/PrimeFaces? Ja nic nenasel. U JSF se mi zda relativne snadne psani AJAXovych aplikaci.
-
aby som zabranil zmatku v pojmoch: ako sa viackrat povedalo: struts1/struts2/stripes/spring mvc su jedna rodina mvc frameworkov, kde plati zasada, ze sa vsetko chape v strankach a navigacii medzi nimi
jsf a wicket su granularnejsi: uvazuje sa v komponentoch a ich vlastnostiach, viacmenej ako v swingu ci starom delphi
(btw kym jsf je kombinacia Java kodu a specialnych tagov v sablonach, wicket je rydzi java kod, kde sablony su ciste HTML, ale filozoficky su to znacne odlisne kniznice)
stripes bol svojho casu pekny framework, lebo elegantne riesil veci, ktore boli v struts 1 tazkopadne (predsa len, struts 1 je z 2001), zaviedol anotacie a mnoho vylepseni v api.
spring mvc sa od verzie 3 extremne prekopal v stripesovskom duchu, a myslim, ze momentalne ma analogicku podporu featur (+ dalsie ako rest), s vacsim rozsirenim v projektoch a lepsou dokumentaciou a komunitou, nehovoriac o tom, ze je to integralna sucast springu
co sledujem blogy, tak sucasna dilema je ci spring mvc alebo jsf2 alebo wicket. springmvc je dobry na jednoduchsie ui a rest api, jsf2 je zase rana istoty, s obcasnym zapasom v niektorych veciach; wicket je zase narocny na naucenie, ale zvlada s eleganciou hyperkomplexne UI a situacie, kde su predosle dva frameworky sialenstvom.
-
Ahoj martine,
pokud zacinas s Webem v kombinaci s Javou, myslim, ze nejlepsi je zacit necim vlastnim a pěkně od píky. U toho pochopis vsechny souvislosti, ktere vsechny frameworky nejakym zpusobem poskytuji a řeší.
Podle meho nazoru pokud budes k necemu inklinovat bez zakladnich znalosti, budes delat zbytecne kroky a odradi te to. Pokud nejprve zvládneš základy, budeš se hned lépe orientovat v dokumentacích a snáz v ní budeš hledat, protože budeš znát terminologii i co přesně hledáš.
Zkus nastudovat a projit nasledujici material, ktery te provede zaklady a navrhne dobry zaklad webového MVC. Myslím, že jako start je to výborný materiál.
http://www.nplus1.net/java_web_programming.pdf (http://www.nplus1.net/java_web_programming.pdf)
Přeji ti hodně štěstí.
Kristova noho, to jsou fakt rady tohle... Aby si místo Tomcatu napsal od píky i vlastní webový server, aby "pochopil všechny souvislosti", mu náhodou taky neporadíš? :o
-
Uprimne receno, jestli jsi technologicky vyhodnotil JSF jako svuj framework tak vrele doporucuji jej nahradit Wicketem.
Oba jsou komponentove, nicmene Wicket je mnohem "cistsi" ve smyslu vic OOP friendly. Wicket te bude prirozene vest k vytvareni re-use (zakladni duvod existence OOP) komponent. Temer vse (od nejmensich komponent jako "html link" nebo "html label" ) je ve Wicketu objekt. Svoje vlastni komponenty budes vytvaret casto a rad, tva aplikace bude prehledna, udrzovatelna, snadno rozsiritelna (vsechno vychazi z one OOP friendly filosofie).
-
Tak jsem se rozhodl pro JSF (Java Server Faces) v kombinaci s RichFaces / IceFaces / PrimeFaces.
Muzete mi doporucit nejake materialy pro uplneho JSF zacatecnika? Idealne v elektronicke podobe. Internet je plny ruzne starych a ruzne kvalitnich Hello world tutorialu, ale dost mi jich nefungovalo (asi moji chybou).
Jak je to s verzemi JSF? V hodne tutorialech psali o JSF 1.2. Ma to jeste dnes cenu, nebo jit hned do JSF 2?
Vsude slysim chvalu na kombinaci JSF+Spring. Je opravdu Spring tak nepostradatelny? Ma smysl se hned od zacatku ucit i Spring, nebo je lepsi zacit s cistym JSF a pozdeji treba pridat Spring? Ve Springu jsem nikdy nedelal.
JSF 1.2 je uz mrtve a mam pocit, ze sa uz ani nesupportuje. Silne odporucam JSF 2.0 aj koli tomu, ze su dost velke rozdiely oproti starsej verzii. Kedysi by som ako framework viac mozno odporucal wicket alebo vaadin ale dnes JSF 2.0 plne vyhovuje a robi sa v nom velmi pekne a rychlo. Rovnako je dobre pristupna dokumentacia a vlastne ide o mainstream komponentovy framework pre javu. Najskor ti mozem odporucit vyskusat zakladnu referencnu implementaciu a potom, ked ju uz budes poznat mozes skusit primefaces, ktory su pre JSF v tejto dobe asi najlepsie.
Avsak treba upozornit, ze komponentove frameworky maju aj iste nevyhody. Mozes s nimi urobit iba to na co boli naprogramovane alebo si pracne robit zlozite komponenty co nie je vzdy rozumne. V poslednej dobre sa zacinaju dost vracat MVC frameworky s pouzitim JavaScriptu na klientskej strane (napr. spring MVC + extJS), ktore su dost zlozite na pisanie kodu (JavaScript) ale maju ovela viac moznosti nez klasicke komponentove frameworky. Podla mna sa v nich dost zlozito vytvaraju a udrziavaju aplikacie a treba ich pouzivat hlavne na dost nestandardne app.
-
Uprimne receno, jestli jsi technologicky vyhodnotil JSF jako svuj framework tak vrele doporucuji jej nahradit Wicketem.
Oba jsou komponentove, nicmene Wicket je mnohem "cistsi" ve smyslu vic OOP friendly. Wicket te bude prirozene vest k vytvareni re-use (zakladni duvod existence OOP) komponent. Temer vse (od nejmensich komponent jako "html link" nebo "html label" ) je ve Wicketu objekt. Svoje vlastni komponenty budes vytvaret casto a rad, tva aplikace bude prehledna, udrzovatelna, snadno rozsiritelna (vsechno vychazi z one OOP friendly filosofie).
Wicket neznam. Jak moc se pouziva? Jak je na tom dokumentace, podpora v IDE (idelane GUI navrhar)?
Rad bych neco "komercne" pouzivaneho. Chci proste venovat cas do uceni frameworku pro ktery pak sezenu praci.
-
ak ide o istotu jobu, potom wicket neries a chod do jsf + vhodna widgetova kniznica (richfaces a spol), lebo samotne jsf su bez nej dost o nicom.
v kazdom pripade:
* wicket ma velmi dobry mailing list, je k nemu pat knih
* gui navrhar ti netreba, lebo ako som pisal vyssie, wicket pouziva ciste html.
* podpora v ide tiez nie je nutna, kedze robis ciste oop v jave
-
Ahoj martine,
pokud zacinas s Webem v kombinaci s Javou, myslim, ze nejlepsi je zacit necim vlastnim a pěkně od píky. U toho pochopis vsechny souvislosti, ktere vsechny frameworky nejakym zpusobem poskytuji a řeší.
Podle meho nazoru pokud budes k necemu inklinovat bez zakladnich znalosti, budes delat zbytecne kroky a odradi te to. Pokud nejprve zvládneš základy, budeš se hned lépe orientovat v dokumentacích a snáz v ní budeš hledat, protože budeš znát terminologii i co přesně hledáš.
Zkus nastudovat a projit nasledujici material, ktery te provede zaklady a navrhne dobry zaklad webového MVC. Myslím, že jako start je to výborný materiál.
http://www.nplus1.net/java_web_programming.pdf (http://www.nplus1.net/java_web_programming.pdf)
Přeji ti hodně štěstí.
Kristova noho, to jsou fakt rady tohle... Aby si místo Tomcatu napsal od píky i vlastní webový server, aby "pochopil všechny souvislosti", mu náhodou taky neporadíš? :o
Proc me to nenapadlo hned. Napsat si vlastni webovy server vrele doporucuji. ;D
Proč sem radil začít od základů?
Ve firme jsem se sektal s mnoho lidmy prosazující různé frameworky. Ideálně to bylo tak, že na každý projekt použili jiný framework aby pak celá naše firemní kultura byla co nejvíc košatá. Nakonec se nějak ustálilo, ale mělo to jeden dopad. Jednoduchá aplikace se ladila týdny, protože v době implementace to nikdo pořádně neznal. A hlavně běh jednoduché aplikace vyžadoval neuměrné množství paměti a nepracoval efektivně - což možná souvisí i s objektovým návrhem business logiky.
Když to vezmu důsledně, tak se utratilo mnoho peněz na učení a opravy chyb, které kdyby se investovali do vývoje vlastních komponent, tak jsme mohli mít luxus podklad pro všechny projekty, nad kterým máme plnou kontrolu (objektový model, pamět, konfigurace, integrace). Žádné hledání na fórech a vymýšlení nesmyslných řešení pomocí použitého frameworku. Kompletní čistý produkt, který lze jednoduše použít znovu a hlavně rešení jednotlivých aplikací postavit víceméně uniformně. Totiž jako úplně nejhorší problém je, když tvoje aplikace nefunguje a ty zjistíš, že za to může framework a musíš čekat na novej release.
Proto pro mě jednoznačně platí, když něco dodáváš dělej to jak nejlíp umíš, a když používáš framework tak nevíš jestli je to to nejlepší. Nikdy. Jednoznačným důkazem nechť je vlastní diskuze o výběru nejlepšího/vhodného frameworku.
-
Po přečtení této diskuse nevěřím vlastním očím - že by ta skělá multifunkční java nebyla vhodná na tvorbu webu/aplikací na webu?! Rozuměj - nejde o to, že by to nešlo, ale že to je takový BIG problém/opich. Nicmoc vizitka.
-
cela diskusia je o tom, ze na spravnu ulohu spravny framework, o vhodnosti javy tu nik nepochybuje okrem vas, diskobolos :-)
jednoduchá aplikace se ladila týdny, protože v době implementace to nikdo pořádně neznal. A hlavně běh jednoduché aplikace vyžadoval neuměrné množství paměti a nepracoval efektivně - což možná souvisí i s objektovým návrhem business logiky.
tydny? rofl? to boli co za zazracne kniznice co ste pouzili? :D to
not invented syndrome, hell yeah!
funky vec je, ze ak si typicky developer nad tvojimi frameworkami, tak si vo vztahu k miestnemu frameworku na tom uplne rovnako ako vo vztahu ku verejnej opensourcovej kniznici:
* mas len taku dobru dokumentaciu, aku ti vytvorili kolegovia: a uprimne, interne projekty na tom su dost casto biedne
* mas na to prave tolko supportu, kolko su kolegovia-autori ochotni poskytovat
* performance je len taky dobry, ako boli dobri tvoji tvorcovia.
co garantuje, ze tvoj vlastny webserver / orm riesenie / gui vrstva bude lepsie ako existujuce riesenia? co garantuje, ze vyviniete lepsi webserver nez taky tomcat, ktory presiel 10+ rokmi iteracii skusenosti a uprav kodu? [ale dobre, chcel by som robit v tvojej firme, kde ti manazer da rok casu na vlastny webserver, where do i apply?]
zloba je, ze ako typicky vyvojar totalnom vendor lock-ine, pretoze skusenosti nevies zrecyklovat inde a ked nahodou zamieris k inemu zamestnavatelovi, tak mu mozes povedat leda to, ze si 3 roky vyvijal nad customizovanym riesenim
cele je to o tom, aby sa vybrali overene a zname kniznice
* ktore naozaj maju za sebou dlhy vyvoj a neni to fanprojekt z githubu o jednom vyvojarovi (= najhorsie chyby su opravene, limitacie su zadokumentovanie a vie sa o nich")
* maju dobru podporu = support a dokumentaciu = clovek neodvisne na jednom probleme a nemusi debugovat vsetko jak divy
* v teame existuje clovek, ktory s nou ma skusenosti a nezacina sa na zelenej luke s limitovanym casom (predide sa "nikdo to poradne neznal")
* su open source ("na release se ceka tydny" = mozete si chybu patchnut, ked je najhorsie)
a cely tento proces sa riesi v tejto teme :-)
-
cela diskusia je o tom, ze na spravnu ulohu spravny framework, o vhodnosti javy tu nik nepochybuje okrem vas, diskobolos :-)
No já nevím, bez FW to v javě nejede (rozuměj v praxi) a žádný z jmenovaných FW není podle této diskuse "komplet" (rozuměj není dotažený pro komplexní nasazení). Takže moje pochybnosti jsou na místě. :-)
-
funky vec je, ze ak si typicky developer nad tvojimi frameworkami, tak si vo vztahu k miestnemu frameworku na tom uplne rovnako ako vo vztahu ku verejnej opensourcovej kniznici:
* mas len taku dobru dokumentaciu, aku ti vytvorili kolegovia: a uprimne, interne projekty na tom su dost casto biedne
* mas na to prave tolko supportu, kolko su kolegovia-autori ochotni poskytovat
* performance je len taky dobry, ako boli dobri tvoji tvorcovia.
No pokud je interni dokumentace na nic, pak je lepsi ji nepsat. A pokud zavrhnes svuj produkt kvuli tomu, ze byva spatna dokumentace, pak se nema smysl do neceho vubec poustet.
Co se tyce supportu, je to jasny. Ale vetsinou se implementace deli na programovani business logiky a jeji prezentaci. Business logika je predmetem analyzy, kterou dopredu dohodnes a jede se podle toho. Prezentacni vrstvu delaji stejni lidi. Pokud potrebuji novyho, zauci ho. Stejne tak jako kazdyho novyho cloveka.
Co se tyce performace, pak te nic nespasi. Jen ve vlastnim produktu mas stabilni vec, kterou muzes ladit jak je libo. A muzes nad ni delat ulpne sizing analyzy.
co garantuje, ze tvoj vlastny webserver / orm riesenie / gui vrstva bude lepsie ako existujuce riesenia? co garantuje, ze vyviniete lepsi webserver nez taky tomcat, ktory presiel 10+ rokmi iteracii skusenosti a uprav kodu? [ale dobre, chcel by som robit v tvojej firme, kde ti manazer da rok casu na vlastny webserver, where do i apply?]
Zminka o implementaci vlasniho serveru byl sarkasmus. ORM a GUI proste ladis. Nechapu co chces garantovat. Pro projekt potrebuji garantovat maximalni zdroje a odezvu systemu. Ale mas vsechno ve sve rezii (tedy vyjma serveru, který na začátku změříš a ukotvis do analyzy). Pokud do toho počítáš framework, pak ho na začátku změříš (coz zakotvis do analyzy), ale v průběhu několikrát aktualizuješ podle toho, na jake problemy zrovna narazis.
zloba je, ze ako typicky vyvojar totalnom vendor lock-ine, pretoze skusenosti nevies zrecyklovat inde a ked nahodou zamieris k inemu zamestnavatelovi, tak mu mozes povedat leda to, ze si 3 roky vyvijal nad customizovanym riesenim
To asi tak stejny, jako kdyz prijdes o firmy, kde nepracuji nad knihovnama, který znáš. Podle mě si vybíráš člověka, kterej je flexibilní. A hlavně podle mě není gró v tom jaký knihovny umíš používat ale jak umíš vymyslet objektový nebo databázový model. Jak maximálně abstrahovat společné rysy. Jak maximálně univerzální řešení umíš najít. Pokud vybíráš někoho podle toho, jestli umí Spring nebo ne, pak můžeš přijít o kvalitní lidi.
Pokud neumis zrecyklovat svoje zkusenosti, pak jsi nanic a framework ti k tomu nepomuze.
cele je to o tom, aby sa vybrali overene a zname kniznice
* ktore naozaj maju za sebou dlhy vyvoj a neni to fanprojekt z githubu o jednom vyvojarovi (= najhorsie chyby su opravene, limitacie su zadokumentovanie a vie sa o nich")
* maju dobru podporu = support a dokumentaciu = clovek neodvisne na jednom probleme a nemusi debugovat vsetko jak divy
* v teame existuje clovek, ktory s nou ma skusenosti a nezacina sa na zelenej luke s limitovanym casom (predide sa "nikdo to poradne neznal")
* su open source ("na release se ceka tydny" = mozete si chybu patchnut, ked je najhorsie)
Naprosto souhlasím s prvnima trema odrazkama. U te posledni nesouhlasim, na to bys mel mit knihovnu sakra zmaknutou (jinak nevis co se kde muze zkazit). Odpovez prosim na nasledujici dve otazky:
Kolikrat jsi si opensource knihovnu Ty sám opravil?
Kolik lidi kolem tebe je schopno knihovnu opravit?
Mir v krvy.
-
cela diskusia je o tom, ze na spravnu ulohu spravny framework, o vhodnosti javy tu nik nepochybuje okrem vas, diskobolos :-)
No já nevím, bez FW to v javě nejede (rozuměj v praxi) a žádný z jmenovaných FW není podle této diskuse "komplet" (rozuměj není dotažený pro komplexní nasazení). Takže moje pochybnosti jsou na místě. :-)
taka situacia je vsade, ukazte mi nejaky PHP framework, ktory je "dotazeny pro komplexni nasazeni". Pri kazdom rieseni bude vzdy nejake "ale", na vsetko budu vzdy ludia nadavat ze to nie je presne to co chcu, akokolvek "dotazene" a "enterprise" by to bolo ...
-
kazdy zo zmienenych fw *je* komplet a *je* realne nasadeny na mnohych projektoch, ktorych su legie. niektore su vhodnejsie na dany typ uloh, teda danu ulohu v nich vyriesite jednoduchsie nez s inymi. to vobec neznamena, ze v jave to nejede.
ano, java nie je php, kde nabuchate vo vime skript, skopirujete to do public_html a uz to ide, ale to ziadneho vyvojara webu netrapi, rovnako ako kazdy sudny vyvojar php vie, kedy ma zobrat radsej mvc framework alebo aspon templatovaci engine, ktory mu mnohe veci ulahci.
aj v jave mozete byt mwm hardcorak, zobrat java.net.serversockety a java.util.concurrent.executorservicy (= threadpooly), a urobit si to sam, ale to je vynachadzanie teplej vody.
-
sry za doublepost
Ale mas vsechno ve sve rezii
mas nejaku success story zo zivota?
lebo to je to, co je podla mna v praxi mytus. zazil som firmu, co si vyvinula vlastne orm a vlastne gui este v dobach, ked hibernate driemal v mysli gavina kinga a ajax v mysli microsoftu. v tomto pripade vyvijat vlastne veci bola ocividna vyhoda (analogicky produkt neexistoval), len niekdajsia zjavna vyhoda (veci pod kontrolou, vyzname sa) po par rokoch dospela do stavu, ze len malokto ma gule sa dotykat, nebodaj opravovat povodnu zakladnu a dnes je "mat veci pod kontrolou" uz len velmi chimericky stav.
Jen ve vlastnim produktu mas stabilni vec, kterou muzes ladit jak je libo.
To sa v opensourcovej stabilnej kniznici vari neda? otazka je, od ktoreho momentu sa ti casova investicia do vyvinu vlastneho riesenia zgruntu vyvazi so existujucimi skusenostami a znalostami existujuceho riesenia.
Kolikrat jsi si opensource knihovnu Ty sám opravil?
Asi trikrat. Not much fun. V jednom projekte preto, ze mali strasne pomaly release cycle + autori nepredpokladali, ze na take nieco sa ich fw pouzije + vydanie novej verzie bolo nepredvidatelne; v druhom preto, ze nova verzia s patchom este bola len v milestone a na staru sa uz kaslalo; a v tretom som patchoval preto, ze to bol bug, ktory sa hned v nasledovnej verzii (asi o mesiac) patchol.
v kontexte troch odrazok je to presne o tom, ze nevyberieme do projektu supercool kniznicu, ktoru ovlada len jeden clovek, alebo hardcore-alpha-stage verziu niecoho, co bohvie kto a kedy dovyvija lebo tam je riziko extremne velke.
rovnako cim obskurnejsie kombinacie kniznic a cim menej technologicky zdatny team, tym je vacsia sanca zaseku. (to je pripad wicketu, moj prvy hobby miniprojektik vo wickete isiel do kelu, lebo vdaka vtedajsej zlej dokumentacii som napisal dokonale neefektivnu aplikaciu).
-
JSF2 zbytecne slozite a kostrbate na vyvoj (zkusenost), dale jsem mel problkem se zabugovanou mojara, pokud se pouzivala v plne siri (oprava budu trva roky...). IceFaces se vyhni, nejsou dobre. Richfaces maji malo komponent. Primefaces je imho nejlepsi pro jsf.
Imho Spring MVC + freemarker+ JS framework je celkem zajimave na web (stabilni jednoduche ozkousene).
Vaadin- dokonale na rychly vyvoj webovych APLIKACI (pouzivam denne).
-
Po přečtení této diskuse nevěřím vlastním očím - že by ta skělá multifunkční java nebyla vhodná na tvorbu webu/aplikací na webu?! Rozuměj - nejde o to, že by to nešlo, ale že to je takový BIG problém/opich. Nicmoc vizitka.
Java je hezky a jednoduchy jazyk. Snadno se parsuje a proto pro nej existuji vyvojova prostredi, ktera ulehcuji vyvojarum praci. Pro Javu vznika spousta kodu, knihoven a frameworku. Diky tomu ale i spousta kodu konci v kosi a frameworky se rychle opousti.
Kdyz si projdete vsecho Javove technologie jejich zkratky za poslednich 15 let tak zjistite, ze jich prezila maximalne pulka. Proto je tak tezke vybrat framework - musite vsadit na toho spravneho kone. Navic oficialni Java standarty jsou casto tezkopadne a prekomplikovane, zatimco knihovny tretich stran jsou jednodussi na pouzivani.
<flame>To nejlepsi na JSF2 je to, ze to neni tak hrozne jako JSF1</flame>