Subbu Allamaraju posted an excellent article about Node.js vs Play! for Front-End Apps.
Play! is an excellent Web framework which is quite similar to Spring MVC on the view/controller aspect and is using Groovy as the view technology.
Spring usual views (JSP, JSTL, Freemarker, Velocity) are quite outdated and I do not understand why Spring does not improve them and why Matt Raible set their as a "pro" in his comparaison.
I believe in using the Grails View as the Spring MVC View. See my previous article about the "How To" and according to the Spring MVC roadmap, Grails View support will be added to Spring 3.1.
Let's benchmark Play! vs Spring MVC with Grails View. This microbenchmark will focus only on the view/controller performance.
Thursday, April 14, 2011
Monday, February 21, 2011
Grails Taglib : The template composition pattern
Grails leverages Sitemesh, a decorator engine, to support view layouts. Sitemesh layout is restricted to page layout and are not applicable to do template layout. For example a template layout which describes the composition of a table and a toolbar.
The purpose of this taglib is to define a ui composition pattern to leverage template layout.
The purpose of this taglib is to define a ui composition pattern to leverage template layout.
Thursday, February 17, 2011
JSF2 - Benchmark datatable
In this article I will bench the datatables of 3 JSF2 components frameworks :
I will focus on efficiency : page size, ajax request/response size, server load, and not on features.
- Icefaces 2
- Primefaces
- Richfaces
I will focus on efficiency : page size, ajax request/response size, server load, and not on features.
Tuesday, February 15, 2011
Grails View as Spring MVC View
Introduction
The reference documentation of Spring 3 contains the following statements:
One of the areas in which Spring excels is in the separation of view technologies from the rest of the MVC framework. For example, deciding to use Velocity or XSLT in place of an existing JSP is primarily a matter of configuration. This chapter covers the major view technologies that work with Spring and touches briefly on how to add new ones.
The supported views are "JSP & JSTL", "Tiles", "Velocity & FreeMarker", "XSLT". Those are the major view technologies that work with Spring. The Spring MVC stack is usually : Spring MVC + JSP/JSTL + Tiles or SiteMesh. All these tools sound outdated, always usefull but outdated. On the other side there are frameworks like JSF, Grails, Play! (not exhaustive list) which come with great views more up to date.
Grails is the most logical choice because it uses Spring MVC internally. The task should be easier. To be honest this choice is not a very hard one because Grails view is elegant.
Friday, January 14, 2011
The Path to Management
From Esther Derby :
From Christopher Avery :
- For Managers: 8 Ways to Build Trust, 3 to Break It
- Real leaders make space for others to shine. So true and the word "space" is quite meaningful.
- Team Trap #5: Withholding Information
- The Blame Game
From Christopher Avery :
Tuesday, January 4, 2011
About Estimation
Scrum Project Estimation Beyond the Near-Term?
This sort of article (that summarize ML thread) is very very valuable. Thanks to Dan Puckett.
This sort of article (that summarize ML thread) is very very valuable. Thanks to Dan Puckett.
Monday, January 3, 2011
JSF beans getter with Spring AOP
Introduction
JSF can call a getter more than once per request.
For example in the following JSF file :
<html>
<body>
<h:dataTable var="car" value="#{carService.cars}">
<h:column>
<f:facet name="header">
Model
</f:facet>
<h:outputText value="#{car.model}"/>
</h:column>
<h:column>
<f:facet name="header">
Year
</f:facet>
<h:outputText value="#{car.year}"/>
</h:column>
<h:column>
<f:facet name="header">
Manufacturer
</f:facet>
<h:outputText value="#{car.manufacturer}"/>
</h:column>
</h:dataTable>
</body>
</html>JSF will call the carService.cars getter more than once inside the same request.
In this example, JSF calls it three times :
13:39:40 DEBUG : CarService.getCars:17 - qtp17489534-18
13:39:40 DEBUG : CarService.getCars:17 - qtp17489534-18
13:39:40 DEBUG : CarService.getCars:17 - qtp17489534-18
A getter obviously returns a value. This value can be a bean property or a calculated value.
If the value is calculated, this can potentially be a problem.
I googled a bit and found some workarounds.
- The first one was to include a check and see if it has already been calculated.
- The second one was to use the getter only to access bean properties
- The third one was to use Spring AOP and cache the value.
For me, the last workaround is the best one because you do not have to modify the view.
And thanks to Spring, it's quite simple to add AOP with a few annotations.
Subscribe to:
Posts (Atom)