V jednom prispevku? To teda nevim... Jsou to frameworky, kazdej je trochu jinej, existuje spousta dalsich, zadnej z nich neni nejlepsi na vsechno, jako vubec vsechny veci. Neco se hodi na jeden problem, neco jinyho na jiny. Vyber si nejakej kterymu rozumis, ve kterym se ti dobre dela a kterej zvladne to co po nem chces (v tomhle poradi). Rozhodne nepouzivej neco jen proto ze si cetl clanek kterej tvrdil ze je to nejlepsi.
otazku som skor myslel tak, ze ak by som nevedel ani jeden a rozhodol by som sa vytvorit napr. vlastny portal, ze ktory by som sa mal zacat ucit a preco ?
Já osobně bych konkrétně na portál spíše volil Cocoon Obsahuje na to speciální frameworky a jeho architektura je na to též docela vhodná. Ovšem je nutné se smířit s dosti strmou učební křivkou a pokud se nejedná o týmovou projekt, tak je třeba počítat s tím, že jeden člověk musí toho zvládnout opravdu hodně. Ale opravdu záleží nejvíce na tom, jake jsou výchozí podmínky a požadavky daného projektu.
prave ta prva veta je zaujima, ze preco by ste sa rozhodli pre Cocoon, a nie pre Struts, ved aj struts na to ma "nastroje". Existuje niekolko firiem na Slovensku, ktore maju vytvoreny portal pomocou Struts s vysokou navstevnostou.
Predem musim varovat, ze Struts znam jen povrchne. Ale rekneme, ze budu chtit vytvorit nejaky portal. Pokud vim, tak Struts zadnou primou podporu portalu neobsahuje (existuje vsak nekolik portalovych enginu zalozenych na Struts - viz napr. http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java/view - asi bych se na ne take kouknul). Samozrejme mi nic nebrani tomu, abych pomoci Struts nebo jen JSP, servletu nebo treba Perlu, PHP, C (nebo VisualBasicu :-)nenaimplementoval funkcionalitu portalu. Ale to uz je v Cocoonu (presneji v Cocoon Portal Frameworku) (skoro) hotove a rekl bych, ze je v tom opravdu hodne prace, kterou bych jinak musel udelat sam. Pak bude nejspise potreba nejak sjednotit datove zdroje (nemluvim ted o jejich prezentaci), ktere budu prezentovat na portalu. Zde mi nahrava architektura a hotove komponenty Cocoonu, ktere by 40-80 % me potreby mohly pokryt (v zavislosti na tom, jak exoticke datove zdroje budu chtit prezentovat). Ale par jich budu asi taky muset vytvorit. Pak musim udelat navrh a implemetaci logiky a grafiky jak portalu samotneho, tak jednotlivych portletu. V Cocoonu to bude znamenat napsani nekolika XSL a CSS stylesheetu, nejake fragmenty XHTML a vytvoreni konfiguracniho souboru. Nejvice mi praci bude komplikovat fakt, ze k tomu Cocoon portal frameworku (ani k jednomu z tech dvou) neni moc dokumentace, takze se budu muset obcas podivat do kodu komponent. Nicmene, pokud si to nekdo u mne objedna, tak mu prototyp (bez hezke grafiky a osetreni chyb) dodam, rekneme, do tydne a ve dvou, trech lidech by to mohlo byt hotovo a odladeno do mesice az sesti tydnu. Cocoon mi zajisti, ze portal bude opravdu flexibilni a udrzovatelny, takze pokud bude zakaznick chtit nejakou rozumnou zmenu (rekneme pridat portlet s podobnym datovym zdrojem), bude mi to trvat maximalne par hodin.
Rozhodnu-li se pro hole Struts, zacnu tim, ze se to poradne naucim (no, dobre, rekneme, ze to je muj problem :-), pak zacnu hledat, jake standardy jsou pro portaly a zacnu to programovat. No, rekl bych, ze tak za dva mesice budu moci rict zajemci, ze sice zatim nic nemuze videt, ale ze uz mam skoro odladene API, knihovny tagu a podobne veci, ktere budu pro ten portal nutne potrebovat. Ale je mozne (ci snad dokonce pravdepodobne), ze to cele nakonec bude mit o neco lepsi (o 10-20 % ?) vykonnost nez reseni zalozene na Cocoonu.
Nerad bych poslednim odstavcem podnitil nejaky flame. Struts neznam do detailu, takze je mozne, ze moje predstava je prilis pesimisticka (nebo taky optimisticka). Konec koncu Struts a Cocoon nemusi byt jen konkurenty, podivejte se treba sem: http://struts.sourceforge.net/struts-cocoon/ .
