Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Which web framework to use with portlets?

See also Discussion of portlet development framework selection for portlets delivered as part of uPortal3

Spring

A lot to love here, a learning curve worth climbing, and what's not there you can expect to continue to improve. A framework and a project with a future. And on the learning curve worth climbing point: I think this is an important point, that investing time and energy in learning this framework gains a valuable skill that is applicable to portlet development, to other web application development, to deploying and configuring existing applications. A learning curve worth climbing.

JSF:

Dave Brondsema writes:

We've developed so far 15 of 40 portlet applications using Spring, JSF, and Hibernate. It is working quite well. I've made a sample portlet illustrating how these fit together and documentation explaining how it works and the difficulties I experienced. You can download it from the clearinghouse or directly.

I haven't encountered any of the issues from ericburke.com, although JSF still is relatively young (as are portlets) and there aren't enough JSF components out there yet (so write some!) and some of them don't work too well with portlets yet because they try to put CSS & JS references in <head> or they expect only HttpServletRequest.

The only architectural issues with JSF that I know of are discussed at Improving JSF by Dumping JSF and solved by facelets.

Julien Viet- Lead JBoss Portlet Developer, on JSF for Portlets

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.

  • No labels