On Fri, Oct 24, 2008 at 09:56:49AM +0200, Zdenek Tronicek wrote: > Cituji Oto Buchta <[EMAIL PROTECTED]>: > >>> >>> Az bude chtit smenarna webovou sluzbu, tak se prida webova sluzba. Proc by >>> se kvuli tomu melo prepisovat JSP opravdu nevim. >> >> a) JSP vracejici SOAP Envelope je SOAPova WebServisa, JSP vracejici XML >> je mozno povazovat za XML WebServisu >> b) pokud bude implementace pomoci JAXB, JavaWS ci neceho podobneho, ano, >> nebude se prepisovat JSP, ale "copy&paste z JSP" do nove vzniknuvsi Java >> tridy asi delat budes, ne? Nebo to budes znova vymyslet a psat? >> > > Ahoj Tapiku, > > musim priznat, ze nechapu jak se bod a) vztahuje k tomu, co jsem napsal a
Protoze pises: "Az bude chtit smenarna webovou sluzbu, tak se prida webova sluzba". JSP vracejici data automaticky zpracovatelne a ktera vyhovuje elementarni definici WebServisy (napr viz http://tapikuv.blogspot.com/2008/06/webservisovn-dl-prvn-webservisa.html ) je mozno za WebServisu povazovat. Ale ot jen tak na okraj. > JSP vracejici SOAP jsou pro me novinkou. Pokud jde o JSP vracejici XML, tak SOAP v doclitu neni nic jineho nez XML podle SOAPoveho schematu. > to samozrejme jde. Ale proc by se kvuli tomu prepisovalo puvodni JSP jsi mi > nevysvetlil. Kdyz chces misto HTML vracet XML, asi ho prepises, ne? Mozna bys udelal jiny postup, ja nikoli ;-) > Ohledne implementace v Java WS: zadne copy&paste tady nebude. Tedy krome > SQL prikazu, pokud bych pouzil JDBC. Pri pouziti JPA ovsem ani to ne. Ono C&P bylo v uvozovkach. Ja osobne bych si v jendom okne otevrel JSP, v druhem Java tridu, zobrazil okna vedle sebe a "prepisoval" bych logiku presne podle toho, co mam uz jednou napsano v tom JSPcku. > > To JSTL SQL, ktere jsem pouzil v predchozim mailu, melo 13 radku. Opravdu > mas pocit, ze je efektivni vytvaret sofistikovane reseni, abys budoucnu pri > souhre nekolika okolnosti (ktere mohou, ale nemuseji nastat) nemusel tech > 13 radku zahodit? Problem natava, kdyz tech 13 radku zahazujes poseste a poseste musis vse znova odladovat. Ale i ono "sofistikovane" reseni lze napsat jednoduse. >>> Nehlede na to, ze vytvareni slozitejsiho reseni na zaklade >>> vlastni uvahy (v zadani to neni) "co kdyz nekdy mozna...", je ekonomicky >>> jen tezko zduvoditelne. >>> >> >> Bohuzel mam pro tebe spatnou zpravu: naopak je to velice JEDNODUSE >> zduvodnitelne. Ono totizto "co kdyz mozna..." v sobe zahrnuje i neco, jako je >> nasledny vyvoj aplikace. Rozsirovani a udrzba software zabere vetsinou vice >> casu nez prvotni vytvareni. A neustalym psanim stejneho software znovu a >> znovu >> si jiste ve vysledku nic neusetris. >> > > K tomuhle mam jednu poznamku: vyvoj "univerzalnich" komponent, ktere jdou > nad ramec zadani, je pomerne castym duvodem selhani projektu. Tady je jadro pudla. Neexistence definice jakekoli univerzalni knihovny v ramci zadani od zakaznika. Jemu je burt, jestli ti nakodujes vsechno do jendoho servletu nebo to bude bezet ve dvaceti abstraktnich vrstvach. Pro nej je dulezite: a) aby to fungovalo a nepadalo b) aby to bylo hotovo co nejrychleji c) aby nebyl problem do toho v budoucnu sahout Je tedy ciste na tvem rozhodnuti, co zvolis za technologii, co si napises sam, co hotoveho pouzijes a jakym stylem to napises. Ja osobne prosazuju deleni na co nejmensi autonomni samostatne testovatelne jednotky a vrstvy. V prvni fazi si to naprototypuju a behem prototypovani mi vypadnou pozadavky na dalsi modularizaci. V principu je mi jedno, jestli jsou onemi jednotkami metody, tridy, EJBcka, JSPcka ci cele aplikace. V ramci prototypovani tveho prikladu bych si asi udelal jednoduchou beanu, ktera mi bude vracet to, co chces tahat s databaze, napsal bych si jednoduchy testik, ze to opravdu vraci, a pak bych si hral s xichtem. Minimalne bych predesel tomu, ze bych nekde neco spatne zazobakoval a pak pracne hledal, proc mi to vraci neco jineho... Oto 'tapik' Buchta PS: Ale je take treba rict, ze jit s kanonem na vrabce je taky nanic. Viz onen priklad s Hello,World!. Pred 15 lety koloval mailem vtip, ve kterem se ukazoval prave na Hello,World! aplikaci rozdil mezi ruznymi pristupy. Nejtrivialnejsi byla aplikace v shellu, ktera obsahovala jenom echo "Hello, World!" Na druhe strane pak stala 7 stranek dlouha aplikace v Borland Pascalu, ktera wrapovala vystup z TurboVision a retezec Hello, World! posilala ven pres bufferovany stream, na kterem byly povesene nejake hooky... Oba dva to jsou extremy.
