Which web framework to use with portlets ?
Julien Viet- Lead JBoss Portlet Developer
My colleague Tom Bayens, project lead of jBPM, asked me questions regarding the web frameworks and the portlet specification. This has been debated at Javaone with the web frameworks smackdown and Stan Silvert presented a session on JSF and portlets.
The questions Tom asked were :
what is your take on portlet versus webframework ? if it takes some time for the webframeworks to support portlets, there must be some gap or mismatch between them.
do portlets need a separate framework or do you think that plain webframeworks can add satisfactory support for portlets ?
another question is how limiting is writing a webapp to a bridge so that the same webapp can be used as webapp and as portlet. will this become mainstream ? or will this never be possible without serious limitations
I am not capable to give a full comparison matrix of all the frameworks, however I can talk about what I know : interraction with a portal and I can extend on JSF and struts.
If the web frameworks want to evolve in the portlet market, they must adapt to the portlet environment and there are mismatches :
protocol mismatch : how the interractions occurs, the portlet defines a two step protocol with a clean separation between the phase where you perform an action and the phase where you render the portlet. In my opinion it is one of the best thing of the portlet specification.
API mismatch : it is different from the servlet API and less hacks are possible, like the deadly usage of HTTPServletRequest#getRequestURI()
invocation mismatch : needs to use a PortletURL to perform invocation to itself and not create URLs directly
context mismatch : portlet have portlet mode, window state and preferences which influence the markup of the producer
markup : a portlet is capable to produce markup adapted to a specific device (cellphone for instance)
JSF is slightly different in the sense that it is agnostic of the execution context (servlet of portlet). JSF is designed to run from the beginning with portlets and servlets whereas other framework not (cf. Stan's presentation).
It seems that if you need to run your apps in those two contexts, today JSF is the framework to use :
it has a spec
it is integrated in JEE 5
it should have decent tools
it can adapt its markup because it has renderers, this is a great asset for JSF to have skinnable components and have the behaviour of the component decoupled from the markup used
But I think that there is a gap for a simple framework for portlets. As said we have JSF but it is complicated. I will change my mind if someone can explain me in 1 hours how JSF works (not how to write an hello world application).
Also JSF does not care about the execution context. For instance if the window state is MAXIMIZE, MINIMIZED or NORMAL it will render the same markup.
Then we have Struts Shale a web framework that is based on JSF. I don't know if it makes sense or not. If it exists, does this mean that JSF is not sufficient by itself ? Or people want to have a Struts like programming model (Model 2) rather than of component model ? So I don't know yet what to think of that effort.
For other frameworks, I don't know them much so I will not critisize but try to comment anyway :
Tapestry has a similar model to JSF, so it cannot compete, except with technological innovation. It seems that Tapestry has always been a techonology innovator, however it has always been complicated to use it. I know that Howard simplified Tapestry a lot since the 3.x series after an constructive discussion with another colleage of mine
Struts will finish his life peacefully as it is planned, yet it should be continued to be used imho because it has lot of momentum
Webwork : I don't know it
Wicket : I haven't looked at it yet
To conclude, JSF has a satisfactory support for portlets so you can invest your resources here. However there is a place for a specific portlet framework that would leverage portlet features that are not used by othe frameworks like portlet modes and window states.