Portlety w Sun Java Studio Creator 2
Ostatnio zainteresowałem się nieco poważniej tematyką portali - po zapoznaniu się z kilkoma darmowymi rozwiązaniami zdecydowałem, że w dalszej wędrówce będę korzystał z Liferaya ze względu na jego stabilność, dojrzałość i duże możliwości oraz zgodność z JSR 168.
Ze względu na to, iż jestem programistą głównie moją uwagę skupiłem na pisaniu portletów, a że JSP i Servlety są bardzo bliskie mej duszy, pisanie ich nie stanowiło dla mnie najmniejszego problemu - okazało się zajęciem miłym, łatwym i przyjemnym, do czasu...
Właśnie do czasu kiedy uznałem, że warto by skorzystać z jakiegoś frameworku (nawet więcej - środowiska deweloperskiego), jednak takiego w którym byłoby dużo komponentów na dość wysokim poziomie abstrakcji, graficzne środowisko deweloperskie do projektowania stron WWW np. tak jak w Sun Java Studio Creator 2. (Przypomnę, że narzędzie to posiada graficzny edytor do budowania stron JSF.)
Zanim do tego przystąpiłem zapoznałem sie nieco dokładniej ze specyfikacją JSR 168. Szczególnie zainteresował mnie rozdział CSS Style Definitions, zawarte są w nim wszystkie standardowe style CSS, które powinny być używane w portletach. Dlaczego powinny być? Otóż dlatego aby każdy portlet wyglądał tak samo pod kątem kolorystyki i stylistyki, którą narzuca wybrany przez użytkownika temat dostępny w konfiguracji portalu. Bo jakże okrutną torturą byłoby dla obiorcy gdyby zobaczył kilka różnych portletów na jednej stronie w zupełnie innej kolorystyce, które nijak nie przystają do całości, a przecież o tą spójność chodzi.
Postanowiłem sprawdzić jak to jest w praktyce i napisałem trochę kodu w JSF (korzystając ze standardowej implementacji MyFaces zgodnej z JSF 1.2). Dlaczego akurat wybrałem JSF, ponieważ już zdążyłem się zorientować, iż jest to technologia najbardziej odpowiednia jeżeli chodzi o pisanie portletów - tak wynika z opinii krążących w Internecie.
Poniżej zamieszczam przykład w JSF napisany zgodnie z rozdziałem CSS Style Definitions: Nietrudno zauważyć, że programista w powyższym kodzie skoncentrował się na tym aby używać standardowych stylów CSS ze specyfikacji JSR 168. I właśnie do tej pory było pięknie, niemal sielankowo... Aż nastąpił czas na próbę generalną Sun Java Studio Creator 2, środowiska deweloperskiego, które pozwala programiście w kilka minut (no może godzin) niemal wyklikać całą aplikację - co można zobaczyć na prezentacji Java Studio Creator 2 in Action. (Wspomnę tylko, że takie prezentacje na menadżerach robią ogromne wrażenie i nie zawsze jest im łatwo wytłumaczyć, że takie rozwiązanie posiada też pewne wady i koniecznie idealnie pasuje do realiów firmy).
Stworzyłem stronę JSF, która wykorzystywała kilka dostępnych komponentów: tabelkę, przycisk itd. Ze względu, że Sun generuje dla własnych komponetów swoje style CSS, postanowiłem w jednym z przycisków je przedefiniować na styl zgodny ze specyfikacją JSR 168: Jakież było moje zdziwienie, gdy po uruchomieniu portletu powyższa zmiana nie przyniosła skutku. W akcie desperacji zajrzałem do źródła wygenerowanej strony HTML w przeglądarce WWW. Oto efekty: Co się okazało komponent wygenerował moją klasę CSS
Występują też inne problemy związane z tym co napisałem powyżej. Jeżeli będziemy chcieli uruchomić dwa portlety napisane właśnie w środowisku deweloperskim SUN od dwóch niezależnych dostawców, z których każdy zastosował inne style CSS np. blue.css i gray.css. To wówczas obydwa portlety przyjmią style od portletu, który uruchomi się ostatni - czyli mamy do czynienia z swego rodzaju loterią, bo to użytkownik może decydować o kolejnośći ich występowania (rozmieszczanie portletów na stronie).
Problem ten można rozwiązać poprzez zastosowanie pewnego obejścia zaproponowanego na blogu pracownika Suna Conflicting Creator Themes in Portlets. Proponuje on dołączenie kolejny raz stylu CSS w stopce, czyli przy dwóch portletach będziemy mieć trzy definicje stylów oraz definicje standardowe dla danego portalu.
Wszystko podsumuję starym przysłowiem: Nie wszystko złoto co się świeci - mimo, że środowisko deweloperskie Sun Java Studio Creator 2 na pierwszy rzut oka oferuję naprawdę dużo, to poważne błędy konstrukcyjne dyskwalifikują je z użycia przy budowaniu portletów.
W czym taki razie pisać portlety skoro standardowa implementacja JSF 1.2 okaże się niewystarczająca, bo oczekiwania są większe (np. tabelki ze stronicowaniem, sortowaniem itd.) może użycie komponentów Tomahawk w połączeniu z ajax4jsf? Niektóry firmy właśnie na takie połączenie stawiają Interview with Max Katz.
Zachęcam do dyskusji W czym pisać portlety (JSR-168) w sposób efektywny, ale i zgodny ze sztuką?
Ze względu na to, iż jestem programistą głównie moją uwagę skupiłem na pisaniu portletów, a że JSP i Servlety są bardzo bliskie mej duszy, pisanie ich nie stanowiło dla mnie najmniejszego problemu - okazało się zajęciem miłym, łatwym i przyjemnym, do czasu...
Właśnie do czasu kiedy uznałem, że warto by skorzystać z jakiegoś frameworku (nawet więcej - środowiska deweloperskiego), jednak takiego w którym byłoby dużo komponentów na dość wysokim poziomie abstrakcji, graficzne środowisko deweloperskie do projektowania stron WWW np. tak jak w Sun Java Studio Creator 2. (Przypomnę, że narzędzie to posiada graficzny edytor do budowania stron JSF.)
Zanim do tego przystąpiłem zapoznałem sie nieco dokładniej ze specyfikacją JSR 168. Szczególnie zainteresował mnie rozdział CSS Style Definitions, zawarte są w nim wszystkie standardowe style CSS, które powinny być używane w portletach. Dlaczego powinny być? Otóż dlatego aby każdy portlet wyglądał tak samo pod kątem kolorystyki i stylistyki, którą narzuca wybrany przez użytkownika temat dostępny w konfiguracji portalu. Bo jakże okrutną torturą byłoby dla obiorcy gdyby zobaczył kilka różnych portletów na jednej stronie w zupełnie innej kolorystyce, które nijak nie przystają do całości, a przecież o tą spójność chodzi.
Postanowiłem sprawdzić jak to jest w praktyce i napisałem trochę kodu w JSF (korzystając ze standardowej implementacji MyFaces zgodnej z JSF 1.2). Dlaczego akurat wybrałem JSF, ponieważ już zdążyłem się zorientować, iż jest to technologia najbardziej odpowiednia jeżeli chodzi o pisanie portletów - tak wynika z opinii krążących w Internecie.
Poniżej zamieszczam przykład w JSF napisany zgodnie z rozdziałem CSS Style Definitions: Nietrudno zauważyć, że programista w powyższym kodzie skoncentrował się na tym aby używać standardowych stylów CSS ze specyfikacji JSR 168. I właśnie do tej pory było pięknie, niemal sielankowo... Aż nastąpił czas na próbę generalną Sun Java Studio Creator 2, środowiska deweloperskiego, które pozwala programiście w kilka minut (no może godzin) niemal wyklikać całą aplikację - co można zobaczyć na prezentacji Java Studio Creator 2 in Action. (Wspomnę tylko, że takie prezentacje na menadżerach robią ogromne wrażenie i nie zawsze jest im łatwo wytłumaczyć, że takie rozwiązanie posiada też pewne wady i koniecznie idealnie pasuje do realiów firmy).
Stworzyłem stronę JSF, która wykorzystywała kilka dostępnych komponentów: tabelkę, przycisk itd. Ze względu, że Sun generuje dla własnych komponetów swoje style CSS, postanowiłem w jednym z przycisków je przedefiniować na styl zgodny ze specyfikacją JSR 168: Jakież było moje zdziwienie, gdy po uruchomieniu portletu powyższa zmiana nie przyniosła skutku. W akcie desperacji zajrzałem do źródła wygenerowanej strony HTML w przeglądarce WWW. Oto efekty: Co się okazało komponent wygenerował moją klasę CSS
portlet-form-button, ale wcześniej wstawił swoją btn2 - niestandardową, niezgodną z definicją styli CSS dla portali, a że w klasie btn2 było zdefinowane mnóstwo atrybutów CSS to moja biedna klasa portlet-form-button niewiel mogła tu przedefinować. Było źle, ale czy może być jeszcze gorzej, okazuje się, że tak. Otóż zaczałem szukać gdzie się podział plik ze stylami CSS, w których znajduję się nieszczęsna definicja btn2, bo może by dało się go zwariantować osobno dla każdego tematu portalu. Wprowadziłbym oddzielny plik z odrębną definicją styli CSS i umieścił w każdym temacie. Po pewnym czasie znalazł się nieszczęśnik w jednej z bilbiliotek SUNa spakowanej do jara. Jak to działa: w momencie gdy ładowany jest portlet ta biblioteka jest dynamicznie z takiego jara wyciągana i do niego dołączana. Efekt jest taki, że każdy portlet ma swoją definicję styli CSS, co nie do końca przystaje do standardu JSR 168.Występują też inne problemy związane z tym co napisałem powyżej. Jeżeli będziemy chcieli uruchomić dwa portlety napisane właśnie w środowisku deweloperskim SUN od dwóch niezależnych dostawców, z których każdy zastosował inne style CSS np. blue.css i gray.css. To wówczas obydwa portlety przyjmią style od portletu, który uruchomi się ostatni - czyli mamy do czynienia z swego rodzaju loterią, bo to użytkownik może decydować o kolejnośći ich występowania (rozmieszczanie portletów na stronie).
Problem ten można rozwiązać poprzez zastosowanie pewnego obejścia zaproponowanego na blogu pracownika Suna Conflicting Creator Themes in Portlets. Proponuje on dołączenie kolejny raz stylu CSS w stopce, czyli przy dwóch portletach będziemy mieć trzy definicje stylów oraz definicje standardowe dla danego portalu.
Wszystko podsumuję starym przysłowiem: Nie wszystko złoto co się świeci - mimo, że środowisko deweloperskie Sun Java Studio Creator 2 na pierwszy rzut oka oferuję naprawdę dużo, to poważne błędy konstrukcyjne dyskwalifikują je z użycia przy budowaniu portletów.
W czym taki razie pisać portlety skoro standardowa implementacja JSF 1.2 okaże się niewystarczająca, bo oczekiwania są większe (np. tabelki ze stronicowaniem, sortowaniem itd.) może użycie komponentów Tomahawk w połączeniu z ajax4jsf? Niektóry firmy właśnie na takie połączenie stawiają Interview with Max Katz.
Zachęcam do dyskusji W czym pisać portlety (JSR-168) w sposób efektywny, ale i zgodny ze sztuką?
Komentarze