Friday 13 March 2009

"Szkolenie" Spring 3.0

Termin: 2 kwietnia
Czas trwania: 2-3 godziny


Podczas szkolenia jeden z najlepszych konsultantów SprigSource - Arjen Poutsma, będzie starał się przybliżyć co takiego fajnego jest w Spring 3.0.

Więcej szczegółów na stronie rejestracji (konieczna rejestracja): http://springtalkcracow.eventbrite.com

Wednesday 11 March 2009

Spring WEB MVC ViewResolver Chaining


Ostatnio pracując wraz ze Spring WEB MVC (2.5.3) natknąłem się na problem z mechanizmem 'ViewResolvers Chaining'
Spring docs:
 
"...Spring supports more than just one view resolver. This allows you to chain resolvers and, for example, override specific views in certain circumstances..."

Problem był dość specyficzny, polegał na tym, iż musiałem użyć dwóch ViewResolver'ów o takim samym typie:

org.springframework.web.servlet.view.UrlBasedViewResolver
konfiguracja wyglądała mniej więcej tak:
<bean id="viewResolver1" class="com.comarch.cii.web.ite.spring.common.view.UrlBasedViewResolver">
<property name="prefix" value="../prefix/pages/"/>
<property name="suffix" value=".jsp"/>
<property name="order" value="0"/>
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
</bean>
<bean id="viewResolver2" class="org.springframework.web.servlet.view.UrlBasedViewResolver">
<property name="prefix" value="../prefix/someAdditionalDir/pages/"/>
<property name="suffix" value=".jsp"/>
<property name="order" value="1"/>
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
</bean>

...czyli w skrócie chodziło o „ładowanie” plików *.jsp z dwóch różnych źródeł, których kolejność definiowała właściwość: <property name="order" value="0"/>
Mechanizm ten niestety nie zadziałał tak jak należy :(
Spring docs:

“Note: When chaining ViewResolvers, a UrlBasedViewResolver always needs to be last, as it will attempt to resolve any view name, no matter whether the underlying resource actually exists.”

Znalazłem na to dwa rozwiązania:
Rozwiązanie 1:
W naszym pliku konfiguracyjnym Spring'a zostawiamy tylko konfigurację do jednego z ViewResolver. Do nazw logicznych, które są mapowane na odpowiednie pliki *.jsp, będziemy doklejać jakiś z góry zdefiniowany 'prefix', czyli dodatkową ścieżkę z naszymi plikami, np.:

@RequestMapping("param")
public ModelAndView initMethod(@RequestParam("id") int ID, Model model) {
final String prefix = "someAdditionalDir/";
final String viewName = prefix + "somePage";
final HashMap modelMap = new HashMap
final ModelAndView modelAndView = new ModelAndView(viewName, modelMap);
return modelAndView;
}

Czyli do nazw logicznych doklejalibyśmy prefix: 'someAdditionalDir/'.
Co nam to da?
A tylko tyle, że jedne kontrolery będą używać nazw logicznych bez prefixa i do widoku używać plików *.jsp spod katalogu: '../prefix/pages/', zaś drugie (wykorzystujące jakiś prefix) plików spod katalogu: '../prefix/someAdditionalDir/pages/'
Rozwiązanie 2:
Jeżeli jednak bardzo chcemy wykorzystać mechanizm 'ViewResolver Chaining', to będizemy musieli napisać własną klasę, która będzie rozszerzać klasę:
org.springframework.web.servlet.view.UrlBasedViewResolver
oraz implementować interfejs:
org.springframework.core.Ordered
Przykładowa klasa mogłaby wyglądać tak:

public class MyUrlBasedViewResolver extends UrlBasedViewResolver implements Ordered {
protected View loadView(String viewName, Locale locale) throws Exception {
final AbstractUrlBasedView view = buildView(viewName);
final View viewObj = (View) getApplicationContext().getAutowireCapableBeanFactory().initializeBean(view, viewName);
if (viewObj instanceof JstlView) {
final JstlView jv = (JstlView) viewObj;
if (jv.getBeanName().indexOf("somePrefix") == -1) {
return null;
}
}
return viewObj;
}
}

O co tu chodzi?
Jeżeli w nazwie logicznej (tej która mapowana jest na odpowiedni plik JSP) nie zostanie odnaleziony prefix 'somePrefix', to ładowany jest następny ViewResolver w łańcuchu.
Plik konfiguracyjny Spring'a może wyglądać tak:

<bean id="viewResolver1" class="com.comarch.cii.web.ite.spring.common.view.MyUrlBasedViewResolver">
<property name="prefix" value="../prefix/pages/someAdditionalDir/"/>
<property name="suffix" value=".jsp"/>
<property name="order" value="0"/>
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
</bean>
<bean id="viewResolver2" class="org.springframework.web.servlet.view.UrlBasedViewResolver">
<property name="prefix" value="../prefix/pages/"/>
<property name="suffix" value=".jsp"/>
<property name="order" value="1"/>
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
</bean>

Tuesday 10 March 2009

Java Express S01E03

...dwa dni poślizgu...i stało się, wyszedł najnowszy numer gazetki java Express a w nim....a zresztą zobaczcie sami :)
http://dworld.pl/2009/03/10/trzeci-numer-java-express-juz-w-sprzedazy/

...proszę o komentarze odnośnie artykułu, jakby się ktoś nie mógł doczekać następnej części to pisać na snc85@o2.pl :P

Saturday 21 February 2009

Java first art

Już wkróce wyjdzie mój pierwszy artykuł w niewątpliwie pierwszej w Polsce gazecie internetowej całkowicie poświeconej Javie...chyba każdy wie o jaką chodzi..oczywiście Java Express :) ... w sumie to mój pierwszy artykuł w życiu, więc do końca nie wiem jak to wyjdzie no ale człowiek uczy sie całe życie :) A o czym ten artykuł? hmmm...no właśnie :P Artykuł w całości poświęcony będzie serializacji w J2ME, czyli stworzenie własnego mechanizmu serializacji. Docelowo moim celem będzie stworzenie automatu do tworzenia klas DTO na podstawie plików Schema) z obsługą serializacji przy pomocy Castora, Apache Velocity, Apache Maven'a i Apache ANT'a :) ...szczegóły już wkrótce bo następne wydanie (już 3) wyjdzie 8 marca, http://dworld.pl/java-express/

Thursday 19 February 2009

Java Passion strikes again :)

Wszystkim, którzy interesują się lub chcą interesować :P...polecam bezpłatne szkolenie z JavaFX 1.1...pod tym adresem nadal można się zapisać :)
http://www.javapassion.com/javafx/#JavaFX_Media