Monthly Archives: February 2009

Grailsów część trzecia – statyczna zawartość i mapowanie adresów

Grails w znaczącej mierze opierają się na zasadzie ‘konwencja ponad konfigurację’. Dlatego też tworzenie aplikacji działa w oparciu o tzw. scaffolding, co można przetłumaczyć jako ‘rusztowanie’. Nie byłbym rzecz jasna sobą, gdybym nie próbował tego tematu obejść 🙂

Choć to obejście przyszło mi dość łatwo. Otóż w myśl mądrych myśli autorów frameworka wpierw powinniśmy utworzyć klasę modelu (domain class), potem napisać do niej testy jednostkowe, uruchamiać je i zmieniać klasę, aż przejdzie ona wszystkie testy z powodzeniem i dopiero po tym napisać kontroler. Ciekawe podejście – z pewnością użytkownicy RoRa znają je o wiele lepiej niż prosty koder PHP. Domyślnie bowiem używając w pracy Zend Frameworka, wpierw tworzę sobie choćby namiastkę kontrolera, gdyż gdzieś trzeba uruchomić pisane klasy modelu. Jak widać w Grails temat został trochę przestawiony, ale co z tego wynika napiszę pewnie w kolejnych wpisach.

Teraz zaś postanowiłem rozejrzeć się trochę po projekcie pozostając wciąż blisko widoku, bez zagłębiania się specjalnie w szczegóły modelu. Poprawiłem trochę CSS (wygląda dobrze nawet pod Internet Explorerem), a także zreorganizowałem menu. Okazało się, że w serwisie będzie kilka miejsc, które będą miały charakter wybitnie statyczny, to znaczy, będzie to wyświetlenie 1 widoku, który to jednakże mógłby mieć swój unikalny adres, ale z drugiej strony, nie ma sensu wrzucać luźnych plików do głównego katalogu /web-app. Przykładem takich stron są choćby odnośniki ‘O serwisie’ czy ‘Linki’. Oczywiście w przypadku tej aplikacji problem jest trochę wydumany, ale w rzeczywistych aplikacjach ilość takich stron może już trochę wzrosnąć i tym samym dobrze byłoby od samego początku mieć dla nich oddzielne miejsce.

Oto jak wygląda obecnie główna strona serwisu:

stronaobecnie

Dobrze byłoby, aby pod linkami na górze kryły się ładne adresy w postaci /strona czy /linki. Jednakże tworzenie dla pojedynczych akcji oddzielnych kontrolerów mija się z celem. Wydumałem sobie zatem, że utworzę jeden kontroler, zaś poszczególne akcje będą odpowiadały za renderowanie tych stron. Konkretne pliki widoku (*.gsp) również znajdą się w jednym miejscu (katalogu).

Wpierw należy utworzyć kontroler, który zbierze to wszystko do kupy. Klikamy zatem prawym przyciskiem na folderze ‘Controlers’ i wybieramy New->Grails Controller. W okienku wpisujemy jego nazwę (u mnie będzie to static) i klikamy Finish. Netbeans przemieli magię frameworka i utworzy nie tylko kontroler, ale też odpowiedni katalog dla widoków w folderze Views and layouts wraz z testem integracji (katalog Integration Tests). Na razie jednakże zajrzyjmy do pliku StaticController.

class StaticController {
def index = { }
}

Rozbudowane, trzeba przyznać 🙂 Kontrukcja którą widać jest tzw. domknięciem. Jest to obiekt Javy, który jednakże wygląda i zachowuje się jak metoda. Jest to o tyle ciekawy element języka Groovy, iż nie potrzeba deklaracji zwracanego typu, a także jawnej specyfikacji parametrów. W przypadku Grailsów tak stworzone domknięcie odpowiada za to, co zostanie przetworzone podczas odwołania się do adresu w postaci /kontroler/akcja. By zaś nie pozostać gołosłownym wystarczy wpisać w adresie przeglądarki odpowiedni adres – http://127.0.0.1:8080/Howtojava/static/index – i co otrzymaliśmy?

Error 500: ServletContext must not be null

Śliczny komunikat o błędzie. Hmmmm, cóż to mogłem przegapić. ServletContext to pojęcie, które znam z JSP. Konkretnie jest to obiekt, który odpowiada za konfigurację całej aplikacji (można tam choćby umieścić dane dotyczące połączenia z bazą danych). Plikiem konfiguracyjnym aplikacji jeszcze się nie bawiłem, zatem może sprawdźmy jeszcze czy to może dlatego, że nie mamy pliku widoku. O dziwo po skopiowaniu pliku index.gsp do katalogu Views and layouts (podkatalog static) i ponownym uruchomieniu aplikacji – viola! Działa. Ciekawe… Zadanie na następny wpis – zapoznać się z konfigiem aplikacji. (PS. Okazało się, że to bug występujący w pewnych okolicznościach związany z pewnym kształtem UrlMappings.groovy. Zasadniczo nie przeszkadza i nie pojawił się więcej).

Plik kontrolera po małych zmianach wyglądał tak:

class StaticController {

def index = { }

def linki = {}

def strona = { }

}

Utworzyłem także 2 widoki – jeden to ‘linki.gsp’, a drugi to oczywiście ‘strona.gsp’. Oto jak wyglądają (zmienia się tylko napis na środku):

Informacje o stronie

Wpisuję adres http://127.0.0.1:8080/Howtojava/static/strona no i proszę. Jak ślicznie to wygląda:

linki

Wygląda całkiem ładnie, problem tylko z adresem, jemu trochę do ładnego wyglądu jeszcze brakuje. Należy zatem odwiedzić katalog Configuration i tam znaleźć plik UrlMappings.groovy. Świetny tutorial dotyczący mapowania adresów można znaleźć na stronie projektu Grails i tam odsyłam zainteresowanych tematem. Natomiast u mnie plik po edycji wygląda następująco:

class UrlMappings {
static mappings = {
"/$controller/$action?/$id?"{
constraints {
// apply constraints here
}
}

"/strona" (controller: "static", action: "strona")
"/linki" (controller: "static", action: "linki")

"500"(view:'/error')
}
}

Zostawiłem domyślną ścieżkę, co mi tam 🙂 Ponownie odwiedzamy przeglądarkę, tym razem jednak wpisując adres http://127.0.0.1:8080/Howtojava/strona i… error 404. No i tu leży pies pogrzebany – należy zastopować serwer i uruchomić go ponownie, aby zmiany w kodzie aplikacji zostały wdrożone. Cóż, taka cena, którą póki co trzeba zapłacić (trzeba będzie poszukać na ten temat informacji). Po restarcie pod powyższym adresem ukaże się naszym oczom dokładnie taki sam widok jak na obrazku powyżej. Znowu sukces 🙂

Na koniec pomyślałem, że byłoby dobrze od razu zająć się stronami błędów. W pliku UrlMappings.groovy jak widać mamy regułę routingu dla kodu “500”. Przydałoby się jeszcze dla odróżnienia zdefiniować inny widok dla kodu “404” no i najlepiej stworzyć dla nich wspólny kontroler. Jeszcze nie wiem jak to wygląda w Grails, ale w takim kontrolerze możnaby dla przykładu podpiąć logowanie błędów, wyświetalnie wyrzuconych wyjątków, itp. Trzeba jednakże przyznać, iż renderowanie całości dotychczasowego layoutu na stronie o błędach mija się z celem. Dlatego też postanowiłem stworzyć odchudzoną wersję layoutu dla renderowania tylko dla komunikatów o błędach (choć może i przyda się później).

Chwilka pracy (myślę, że nie muszę wklejać listingów, wszystko odbywa się tak samo jak w tym i poprzednim wpisie) i powstał nowy lekki layout, a także stosowny kontroler Errors i widoki do niego. Domyślnie Grails tworzy widok, który jest odpowiedzialny za renderowanie błędów (error.gsp). Zostawiłem go, tylko zmieniłem nazwę na servererror, aby wyrzucał wyjątki w sposób ‘widoczny’ dla mnie (na serwerze produkcyjnym oczywiście takie coś należy wyłączyć). Dodałem też ładny widok dla kodu błędu 404. Restart, uruchom i znowu problem. Okazuje się, że przy błędzie 404 – Grails w dziwny sposób nie potrafi odwołać się do zewnętrznego pliku layoutu! Czyli mój piękny odchudzony plik z layoutem na niewiele mi się zda. Po prostu renderowany jest zwykły widok (nopageerror.gsp), ale tylko tyle! Nie jest w ogóle startowany plik layoutu. Grrr, posiedziałem nad tym, poklęłem no i nic – musiałem wrzucić zmiksowany kod layoutu i samej strony do jednego pliku. Pewnikiem gdzieś jest jakaś zagowzdka z obiektem renderującycm widok, no ale na razie nie za bardzo mam czas się w ten problem zagłębiać. Najważniejsze, że mam piękną stronę dla błędu 404.

stronabledu

Grailsujemy dalej, czyli początki aplikacji w Grails

W poprzednim wpisie powiadomiłem wszem i wobec o nowym projekcie na blogu. Przyszedł zatem czas na konkrety – oto początki tworzenia aplikacji internetowej w Grails.

Wbrew wcześniejszym zapewnieniom użyte IDE to ponownie Netbeans, tyle tylko, że w wersji 6.5, która posiada wsparcie dla projektów pisanych w Groovym i Grailsach. Należy zatem zaopatrzyć się w wersję 6.5 Netbeans’a i z menu wybrać File->New Project->Groovy->Grails Project (oczywiście wypadałoby mieć w tym czasie również zainstalowane Grails i Groovy, ale jak tego dokonać napsiałem w poprzednim wpisie. IDE pobuduje nam projekt i oto co powinno pokazać się naszym oczom:

Projekt Grails

Projekt Grails

Jak na rasowy framework przystało, Grails odwalił kupę dobrej roboty, aby tworzenie projektu odbyło się łatwiej i przystępniej. Mamy zatem na razie puste katalogi z kontrolerami, modelami (domenami), usługami sieciowymi, a także kilka ciekawych rzeczy. Standardowo framework ten jest dostarczany z szeregiem bibliotek JavaScriptu, które mają w zamyśle wspomagać pracę z AJAXem. Widać tam i Prototype, a także opartą na nim bibliotekę Scriptaculous, z którymi miałem okazję pracować, ale jednak obecnie korzystam z JQuery i za nic nie chcę widzieć alternatyw 🙂 Zmianą używanych bibliotek zajmę się później.

Mamy też katalog ‘Views and layouts’, którego przeznaczenie jest raczej oczywiste. Widoki w Grails są tworzone z użyciem Grails Server Pages (swoistej odmiany JSP). Do tematu jednakoż jeszcze za chwilkę powrócę. Warto rozejrzeć się trochę po projekcie w jego początkowej fazie. Daje to pojęcie od czego zaczynamy na samym początku pracę i da obraz zmian i ogromu pracy jaką wykona za nas Grails.

Teraz może kilka słów o projekcie, który zamierzam zrealizować. Nie raz dało się słyszeć głosy (na różnych forach), iż społeczność javovców w polskim internecie (podkreślam INTERNECIE), nie ma tak mocnego ośrodka jak choćby forum php.pl, na którym zawsze można znaleźć odpowiedzi na masę pytań i nie tylko (HydePark rządzi). Pomijając kwestie natury społecznościowej, to dobrze byłoby mieć jedno miejsce, gdzie na 99% znajdzie się odpowiedź na większość swoich wątpliwości. I tak kiedy jechałem do pracy przyszedł mi do głowy ciekawy pomysł. Może należałoby stworzyć prosty serwis (prosty, bo też tworzony w ramach nauki), w którym możnaby zamieścić pytanie z prośbą o poradę, a użytkownicy portalu mogliby na nie odpowiadać. Czyli takie forum, ale nastawione tylko i wyłącznie na porady dotyczące języka programowania, a także pokrewnych technologii. Podobne portale istnieją w odniesieniu do wielu dziedzin życia, ale moje ambicje nie sięgają tak daleko. Rozwiązań tego typu w polskim internecie przeznaczonych TYLKO DLA JAVY, jakoś nie mogłem się doszukać, zatem i ciekawy pomysł, a i może przyda się komuś 🙂 Jakby jeszcze ktoś chciał wesprzeć tanim hostingiem to w ogóle byłoby miodzio.

W tym wpisie opiszę tylko dwa kroki – ‘oprawienie’ aplikacji w inny niż standardowy wygląd, a także dodanie biblioteki JQuery i usunięcie istniejących. To tyle na rozruch, poważniejszymi zadaniami zajmę się niedługo. Wpierw zatem wygląd. Przejrzałem szereg ciekawych propozycji i z pomocą żony wybrałem taki, który najlepiej moim zdaniem nadaje się do moich celów. Pobrana paczka składa się z obrazków, kodu CSS oraz przykładowej strony HTMLa. No i teraz po kolei.

Kod CSS wrzucamy do katalogu /css. Konkretnie znajduje się on KATALOG_APLIKACJI/web-app/css. Domyślnie tworzony jest w nim plik main.css, ale nie przejmumy się tym – zapisałem CSS dla całego layoutu pod nazwą layout.css. W tym samym katalogu (KATALOG_APLIKACJI/web-app) mamy także katalog /images. Tam zgodnie z nazwą wrzucamy pliki graficzne dla ściągniętego layoutu.

Grailsy ucieleśniają dość standardowy mechanizm – mamy zarówno layout, jak i konkretne szablony dla obecnie wyświetlanej akcji. Domyślnie (zaraz po stworzeniu projektu) posiadamy dwa pliki. Jeden to plik layoutu w katalogu Views and layouts/layouts/main.gsp, a także pierwszy plik szablonu w katalogu Web Application/index.gsp. Dla celów instruktażowych należy stworzyć kopię pliku index.gsp w tym samym katalogu – wypada tylko zmienić jego nazwę, na np. example.gsp. Na nim będziemy eksperymentować. Na razie jednakże zajmijmy się plikiem layoutu. Jego zawartość powinna wyglądać mniej więcej tak:

kodlayout1

Wygląda to na standardowy kod HTMLa ze specjalnymi tagami GSP. I właśnie te tagi są dla nas najważniejsze. Należy uruchomić naszą stronkę (prawy przycisk na projekcie->run). Netbeans puści w ruch całą maszynerię wdrożenia aplikacji i na końcu zastartuje serwer i odpali przeglądarkę (przynajmniej u mnie tak to działa :). Naszym oczom powinna ukazać się strona powitalna Grails. Zachęcam do spojrzenia w kod źródłowy strony (w przeglądarce), a następnie zapozanie się z treścią pliku index.gsp w katalogu /web-app. Ciekawe prawda? Nie jest potrzebna większa znajomość frameworka, aby zobaczyć, iż w miejsce znaczników i zostały ‘wstrzyknięte’ kawałki kodu z wyświetlanego obecnie widoku.

Zatem uzbrojeni w tę wiedzę należy teraz poinformować aplikację, aby wczytywała również kod CSS z pliku layout.css. W tym celu do pliku main.gsp należy dopisać tę linijkę:

	<link rel="stylesheet" href="${createLinkTo(dir:'css',file:'layout.css')}" />

Edycja: Dzięki mejlowi od Mariusza Pieniążka zdałem sobie sprawę, że poniższy fragment jest totalnie nielogiczny i zagmatwany. Stąd nowa wersja.

Należałoby też wyczyścić zawartość znacznika w naszym pliku layoutu (main.gsp) – zostawiamy tylko znacznik GSP . Z kolei w naszym pliku (dla przypomnienia: example.gsp) należałoby wkleić zawartość widoku ściągniętego ze strony z templejtami (link podałem gdzieś wcześniej). Jedyną rzeczą do dopisania w samym widoku jest linijka:

To co ostatecznie musimy osiągnąć to plik layoutu (main.gsp), w którym znajdują się maksymalnie rozbudowane sekcje HEAD (wszystkie znaczniki META oraz importy plików, np. CSSów czy JSa), a także dość krótka i nienarzucająca się sekcja BODY. Oczywiście w ostatecznym wyglądzie HowToJava plik layoutu trochę rozbudowałem (głównie dla obsługi sidebara), jednakże zasada jest ta sama.
Zaś plik widoku (aktualnie renderowanego) powinien zawierać w sekcji HEAD taki oto znacznik:

<meta name="layout" content="main" />

Dzięki temu layout z main.gsp zintegruje się z naszym widokiem. Do pełni szczęścia okazało się, że trzeba wyedytować plik layout.css – przy odnośnikach do plików graficznych trzeba dopisać “../”, aby Grails zobaczył obrazki. Póki co dziwne (nie wiem pod kątem czego odbywa się przeszukiwanie katalogów, no ale rozwiązanie to na razie działa). Z pewnością dowiem się już niedługo więcej na temat routingu w tym frameworku. Oto co uzyskałem po małych przeróbkach ze swojej strony (adres pod którym uruchamiam aplikację to: http://localhost:8080/Howtojava/example.gsp):

howtojava

Wygląda to już dość przyzwoicie, teraz przyszedł czas na JQuery. Ja po prostu usunąłem katalog Prototype z folderu /web-app/js i wgrałem tam ‘czystą’ bibliotekę JQuery. W pliku main.gsp dodałem tylko tę linijkę ( w sekcji <head>):

<g:javascript library="jquery-1.3.2.min" />

Przetestowanie czy JQuery jest banalnie proste. Króciutki kod wklejony bezpośrednio do pliku example.gsp powiedział prawdę:

jQuery().ready(function(){$('#logo').fadeOut();});

I po przeładowaniu strony napis ‘HowToJava.pl’ powinien powoli sobie zniknąć. Krótko mówiąc – podpięliśmy inną bibliotekę JavaSCriptu niż dostarczane standardowo. To tyle na dziś. W następnej części przedstawię technologię rusztowania (ang. scaffolding), która zgodnie z nazwą umożliwia stworzenie znacznej części aplikacji automatycznie. Na pewno będzie ciekawie.

Grailsujemy

Dziś będzie szybko – za radą Jacka Laskowskiego postanowiłem zabrać się za Grailsy. Po przejrzeniu kilku stron w necie wiem już jedno – tak, to jest konkretne narzędzie. Jeszcze bardziej podoba mi się motto ze strony głównej projektu – Grails – the search is over.

Znikam zatem na jakiś czas by zagłębić się w ten temat. O tyle jest to problematyczne, że przy okazji ruszam Hibernate i na pewno choć podstawy Springa. Do tego dochodzi język Groovy i wszelakie dobrodziejstwa Grailsów (ich własny ORM, własna ‘implementacja’ widoku). Dodam jeszcze, że całość będzie pisana w NetBeans w wersji 6.5, a Grailsy będą w ostatniej stabilnej wersji, czyli oznaczonej numerkiem 1.0.4. Celem zaś jak już mówiłem będzie stworzenie w pełni funkcjonalnej aplikacji internetowej.

PS. Jak postawić sobie środowisko pracy w okienkach jest całkiem przystępnie opisane w necie. Nie żeby to jakoś trudne było, no ale…

Swinguj z nami czyli piszemy aplikację cz.2

Po kilku miesiącach od pierwszego wydania przyszła kolej na krok dalej – oto druga wersja klienta do gry w Arkadię, opartego na Swingu i mojej niedostatecznej znajomości Javy 🙂

Przyznaję, że wydanie to mogłoby pojawić się wcześniej. Jednakże wpierw mały romans z JEE, a potem wypadki losowe odwlekły ten fakt w czasie. Przez kilkanaście ostatnich dni przysiadłem fałdów i oto jest – druga wersja ChlebikClient. Wiele jeszcze jej brakuje do optymalnego funkcjonowania jako wymarzony klient, jednakże widać już pewne zarysy jak mogłaby wyglądać taka aplikacja, kiedy bierze się za nią newbies. Jednakże postanowiłem, że wydanie drugie będzie również i ostatnim – gdyż kolejne wydania byłyby po prostu dokładaniem bardzo podobnych do obecnych cegiełek. Czyli kolejny JInternalFrame, kolejny plik XMLa i tak dalej – ani to wiele już nie rozwija, a i sensowności dalszej w tym nie ma zbyt wiele.

Popracowałem z NetBeansem używając jego pomocy do tworzenia GUI, mam mniej więcej pojęcie o wątkach aplikacji pisanej w Swingu (choć i tak niewiele jak znam życie), operowanie podstawowe na plikach XML, poszczególne komponenty też obejrzałem sobie z kilku stron. Na dzień dzisiejszy dalsze prace zostają wstrzymane i odłożone na czasy obfitujące w wolny czas (może kiedyś nadejdą). Póki co zapraszam na podstronę projektu, gdzie można przeczytać listę zmian oraz ściągnąć najnowszą wersję.

Co zaś do przyszłości – zmierzam w kierunku JEE. Dla nauki rozpoczynam pisanie aplikacji internetowej. Wstępnie technologie użyte to JSP, Hibernate/JDBC, wszystko zapakowane w Tomcata. Być może tym razem spróbuję użyć do pracy Eclipse’a wraz z jego rozszerzeniem WTP.

JSF i dlaczego jestem zdumiony

Jak wspomniałem w jednym z poprzednich wpisów nabyłem trochę ciekawych książek o wiadomym temacie. No i po tym jak ‘prześlizgnąłem się’ po Head-First JSP i Servlety zabrałem się od razu za Core JSF. I ZONK! Po raz kolejny podejście wzięte z PHP sprawiło, że uderzyłem o ścianę. Ale tym razem cholera miało być inaczej.

Tok mego rozumowania był prosty – mamy JSP i serwlety. Służy to do pisania aplikacji webowych dla platformy JEE (nie całych, ale na pewno widoku i kontrolera). Znaczy się może służyć, bo wiadomym jest, że dzisiaj raczej w czystych językach nikt nie pisze – używa się różnych bibliotek i komponentów, których połączenie często okazuje się na tyle fajne, że powstaje framework. I takie coś mamy w PHP – język językiem, no ale w okolicy wersji 5.1 kiedy to OOP przestało być czymś na papierze, a stało się rzeczywistością pojawiły się pierwsze frameworki. Kiedy rozpoczynałem pracę jako koder PHP dostałem się w szpony Zend Frameworka i wciąż w nich tkwię. Po drodze bawiłem się trochę Symphony, a także RORem (choć to inny język). Dla mnie zatem framework to zestaw przynajmniej gotowych komponentów, które rutynowe czynności w budowie aplikacji sprowadzają do inicjalizacji kilku obiektów i wywołania ich metod. To co potrafi momentami Symphony czy ROR to już w ogóle kosmos i nic dziwnego, że ludzie tego używają.

Wracając do Javy – myślałem, że JSP to takie PHP, no a JSF to framework, czyli liznę tego pierwszego na razie byle się tylko orientować, przepatrzę książkę o JSFie i wezmę się za pisanie projektu łączącego tę wiedzę w jednym. Może to wina książki, albo i samego narzędzia. Jednakże załamało mnie to, iż po lekturze 100 stron to wiem na pewno, że wszystko o czym czytam zostanie omówione w następnych rozdziałach. No nic, przepatruję z ciekawości spis treści. Przerobiłem na chwilę obecną wstęp, coś o beansach, rozdzialik o nawigacji (XML rządzi) i zacząłem znaczniki standardowe. Zostaje mi rozdział o znacznikach niestandardowych, weryfikacji danych, obsłudze zdarzeń i… w sumie nic. Bo następne rozdziały to niestandardowe elementy, potem JDBC/LDAP, AJAX no i omówienie bardzo pokrótkie inych frameworków!!! Na koniec mam rozdział zatytułowany ‘Jak to zrobić?’. Mam pomysł by na tym pytaniu oprzeć ćwiczeniowy projekt pisany w JSP (aplikacji internetowej) zatem przerzuciłem te 400 stron i wziąłem się za szybkie przeglądanie rozdziału. ZONK!

Rozbiło mnie już pytanie trzecie (sic!) na łącznie około 35. Jak zaimplementować obsługę wysyłania plików na serwer?. O nareszcie coś z bliskich mi klimatów. Dla niezorientowanych w temacie PHP wyjaśniam – w tym języku jest to kwestia sprawdzenia czy przesłano element “file” z formularza, po czym sprawdza się czy plik doszedł i zapisuje się go w docelowym katalogu. W wersji spartańskiej robi się to może 5 linijkami kodu (wliczając po nawiasach klamrowych na linię). W Zend Frameworku mam do tego jego element w postaci Zend_File, a w nim cuda niewidy – walidatory, filtry, plus adaptery dla wysyłania plików. Można to łatwo zobaczyć – kilka linii kodu i działamy.

A co mamy w JSF? Chwilka, już liczę… Serwlet filtrujący (109 linii kodu) plus klasa renderująca (89 linii) plus klasa dla znacznika ( 28 linii ) plus sam plik JSP ( 18 linii ), ale to można pominąć. Szybkie dodawanie i okazuje się, że by wysłać plik na serwer i wiedzieć, że dotarł cały i bezpieczny muszę sklepać ponad 200 linii kodu!!! Cholera no to jest framework czy jakiś #$@#@%^^%? Jak można nazywać taką technologię frameworkiem, skoro zamiast usprawniać tworzenie aplikacji niewiele ona w sobie zawiera? No niby co poza jasno określonym MVC (ale przecież JSP też to ma, a tu jeszcze od cholery XMLa na ścieżki nawigacji), pomocą z renderowaniem widoku (View) czy w końcu znacznikami JSF technologia ta może zaoferować?

Ufff, przepraszam, uniosłem się, to był przedostatni raz. Naprawdę zaczynam rozumieć, dlaczego w ogłoszeniach o pracę dla javowców wymienia się po 4 elementy z każdej dziedziny (Struts, Spring, JSF, Ant, Maven, Hiberante, TopLink, iBATIS, JBoss, WebSphere, Tomcat). Nie wiem, ja generalnie młody jestem, zaczynam bawić się w te klocki, ale błagam, niech ktoś mi powie: “potem będzie lepiej”. Framework będzie frameworkiem z zapleczem, a nie tylko ulepszonymi grabiami czy łopatą. Proszę niech ktoś powie: “młody jesteś, ucz się dalej”. Jak już poznasz to zrozumiesz.

Proszę 🙂