31. března 2009

Spring MVC: GET kontroler

Dlouho jsem neuváděl žádný můj zdrojový kód, tak to dnes zkusím napravit. Spring MVC nabízí pro zpracování požadavku GET dva základní kontrolery:

  • ParameterizableViewController - jednoduchý kontroler, který pouze vyžaduje zadání cílového view, které se následně zobrazí.

  • BaseCommandController - kontroler, který pracuje s parametry requestu přes commandy. Tedy kontroler automaticky mapuje parametry requestu do atributů objektu (commandu), je možné využívat validace, bindery apod.

V každé aplikace resp. projektu se hodí mít nějaké své předky-kontrolery, které mohou zprvu být prázdné, ale vždy se časem ukáže, že je potřeba mít nějakou společnou funkcionalitu nebo společná data pro většinu nebo všechny kontrolery. My jsme se na projektu rozhodli mít dva předky-kontrolery, jeden pro práci s formuláři (zpracování POSTu) a jeden pro práci s GETem. A právě u GETu jsem narazil na to, že bych rád měl možnost výběru - jednou mi stačí si vytáhnout parametr přímo z requestu a jindy využiji command s validací. Takže z tohoto důvodu jsem udělal následující mix dvou výše uvedených kontrolerů. Pro úplnost ještě musím zmínit použití rozhraní IDataModelProvider, které slouží k předávání modelu resp. dat společných jak pro GET, tak pro POST kontrolery.


/**
* Zakladni implementace kontroleru pro zobrazovani stranek pres GET metodu, tj. zobrazeni
* JSP stranky, pripadne predani promennych na stranku.
*
* <p>Kontroler muze pracovat ve dvou "rezimech" - s commandem a bez nej.
* Pokud chceme pracovat s commandy a tedy mapovat parametry requestu do commandu, tak pak
* je vhodne v podtride implementovat metodu
* {@link #handle(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse, Object, org.springframework.validation.BindException)}
* a nastavit tridu commandu {@link #commandClass}.
*
* <p>Pokud nam staci pristup k parametrum requestu (bez commandu), tak pak je vhodne implementovat
* v podtride metodu {@link #handleRequestInternal(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)}.
* Toto chovani je defaultni.
*
* @see BaseFormController
*/
public class BaseGetController extends AbstractCommandController {
private static final Logger logger = Logger.getLogger(BaseGetController.class);

private IDataModelProvider dataModelProvider;
private String viewName;
private boolean supressBinding = false;
private boolean supressValidation = false;

protected void initApplicationContext() {
if (this.viewName == null) {
throw new IllegalArgumentException("Property 'viewName' is required");
}
}

/**
* Metoda resi, zda se bude pracovat s commandem (a tedy request parametry se budou
* napojovat na command) a nebo zda se bude pracovat bez commandu (a tedy je nutne pracovat samostatne
* primo s parametry requestu).
*
* <p><b>Tato metoda je vhodna k implementaci v podtridach, pokud nepracujeme s commandem
* a staci nam pristup k requestu.</b>
*/
protected ModelAndView handleRequestInternal(HttpServletRequest request,
HttpServletResponse response) throws Exception {
if (getCommandClass() == null) {
//pracujeme bez commandu
this.supressBinding = true;
this.supressValidation = true;
return this.handle(request, response, null, null);
}
else {
//pracujeme s commandem
return super.handleRequestInternal(request, response);
}
}

/**
* Metoda vklada spolecna data do vysledneho modelu.
*
* <p><b>Tato metoda je vhodna k implementaci v podtridach, pokud pracujeme s commandem</b>.
* Pokud neni {@link #commandClass} definovano, tak pak vstupni parametry <i>command</i> a <i>errors</i> jsou null.
*/
protected ModelAndView handle(HttpServletRequest request,
HttpServletResponse response,
Object command,
BindException errors) throws Exception {
ModelAndView mav = new ModelAndView(getViewName());

mav.addAllObjects(dataModelProvider.getModelData());

if (logger.isDebugEnabled()) {
logger.debug("BaseGetController returns: " + mav);
}

return mav;
}

protected boolean suppressBinding(HttpServletRequest request) {
return this.supressBinding || super.suppressBinding(request);
}

protected boolean suppressValidation(HttpServletRequest request, Object command) {
return this.supressValidation || super.suppressValidation(request, command);
}

public void setDataModelProvider(IDataModelProvider dataModelProvider) {
this.dataModelProvider = dataModelProvider;
}

/**
* Set the name of the view to delegate to.
*/
public void setViewName(String viewName) {
this.viewName = viewName;
}

/**
* Return the name of the view to delegate to.
*/
public String getViewName() {
return this.viewName;
}
}

21. března 2009

JavaRebel - vývoj bez restartu serveru

O nástroji JavaRebel se již psalo před nějakým časem na Jirablogu. Přesto bych rád o tomto super nástroji napsal znovu a podělil se s vámi o mé zkušenosti.

Pokud tento nástroj ještě neznáte, tak se jedná o JVM plugin, který umožňuje za běhu aplikace upravovat Java kód tak, že se změny hned promítnou do běžící aplikace. To zní hodně podobně jako standardní JVM HotSwap, ale JavaRebel toho umí mnohem více, např. přidání nové proměnné do třídy, metody, změna anotace apod. Více o možnostech zde.

Vždy jsem si při vývoji vystačil s lightweight servery (Tomcat, Jetty) a tam nebyl problém server často restartovat z důvodu promítnutí změn v Java kódu. Nyní dělám na projektu, kde máme OC4J server a plně jsem pochopil, proč ty servery jsou tak heavyweight. Člověk si musí při psání kódu dávat opravdu pozor, protože náběh serveru je v řádu desítek sekund až minuty. A pro tyto případy se hodí JavaRebel.

Moje zkušenost je nyní celkem pozitivní. Používám poslední verzi 2.0-RC2 spolu s OC4J verze 10.1.3.4, k tomu IntelliJ IDEA verze 7.0.4. Intalace je velice jednoduchá - JavaRebel knihovnu se nahraje do classpath aplikace nebo serveru, upraví se spouštěcí soubor serveru a pro IDEU se ještě doinstaluje plugin, aby hezky fungovalo debuggování. Vše je popsáno zde.

S JavaRebel pracuji již přibližně měsíc a chvíli trvalo, než jsem si to vyladil. Měl jsem problémy s během aplikace, někdy mi dokonce spadnul z ničeho nic celý server. To se hodně zlepšilo s uvedením nové verze 2.0-RC2 (před tím jsem používal 2.0-M2). Také jsem musel vyloučit generované Java třídy z JSP stránek (přidal jsem při spouštění tento parametr -Drebel.packages_exclude=_oracle._jsp._tag). Teď mám pocit, že to opravdu funguje, jak bych si představoval.

Součástí JavaRebelu je i plugin pro Spring (pozn. pluginy jsou součástí JavaRebelu od verze 2.0-RC1, před tím bylo nutné si stáhnout pluginy odděleně). Ten by měl umět promítnout změny v konfiguraci Spring kontejneru v průběhu běžící aplikace. Tento plugin jsem krátce používal, ale měl jsem podezření, že mi kvůli tomu padá server, tak jsem ho zatím vypnul. Ale určitě se k němu ještě vrátím, až budu mít více času.

Díky udělátku JavaRebel se i s OC4J dá vyvíjet efektivně. Nástroj není sice zadarmo, ale cena 59 dolarů mi přijde velice příjemná, zejména když vezmu o kolik se mi zvýšila produktivita práce. JavaRebel je možné vyzkoušet po dobu 30 dní.

17. března 2009

Dynamické jazyky nejsou zase tak špatné

Pokud jste v minulosti četli mé názory na dynamické jazyky, tak jste museli cítit, že je zrovna "moc nemusím". Jak to dost často bývá, člověk je omezený díky své neznalosti.

Když jsem se vždy někoho zeptal, k čemu jsou dobré dynamické jazyky, tak jsem vždy dostal hodně podobnou odpověď - DSL, tvorba GUI, customizace. Jenže můj problém byl vždy v tom, že jsem si nedokázal sám sobě říci, kde konkrétně to můžu využít - DSL jazyky obvykle nevytvářím, pro GUI používám JSP nebo JSF (a obecně s tím nemám problém) a customizace je pěkná věc, ale také jsem ji nikdy moc nepotřeboval, protože spíše pracuji na jednorázových projektech než na produktech.

Můj názor se celkem radikálně změnil poté, co jsem si přečetl články o integraci Springu a Groovy a také po vašich komentářích v mém posledním článku o dynamických jazycích.

Díky tomu se mi moc začala líbit ta myšlenka, že pomocí Javy si vytvořím kostru aplikace (pomocí rozhraní) a ty části, které se mění resp. je potřeba upravovat per instalace, tak ty můžu implementovat pomocí Groovy (a hezky měnit za běhu aplikace bez restartu serveru). Toto není nijak obecně převratná myšlenka, ale pro mě je převratná v tom, že jsem ji dokázal aplikovat na konkrétní aplikaci s konkrétními problémy. Holt někomu to trvá trochu déle... :)