A colleague presented me with this question today: Under what conditions does it make sense to use JSF portlets and when doesn’t it? This is a good question and can be applied to several frameworks, such as Struts and Spring MVC.
Now before I answer, let me give you some of my background. I’ve been working in IT for almost 30 years. I pride myself on never having to work on a mainframe (hard to do in the early 80s!) and never having to learn Cobol. In the early 90s I avoided the Visual Basic craze (it seems as though there was one). So I’ve always tried to find ways not to do conventional things.
When it comes to portlet development, I’ve always tried to adhere to the mantra: small footprint, low complexity. So when designing a portlet application, I’m always looking to break it into small, lightweight components that I can link together at run time. This is opposed to building large portlets with lots of JSPs and flows between them in the portlet.
I think that JSF (and Struts and Spring MVC) are hardly ever needed for portlet development. Those frameworks were originally built to help developers simplify complexity of managing big applications with lots of screens and actions. In my view, portlets were intended to help solve the complexity problem by splitting applications into more discrete units.
For example, if you are building a claims system, you may have lots of screens and actions when you look at the whole system. But if you break that system into portlets, you have much simpler development within each portlet. A portlet that does a search for existing claims should only be a couple of screens and one action. Or submitting a claim is one form, one action, and a results screen. Who needs JSF to manage those simple flows?
If you have a portlet application that truly needs lots of screens and actions, then use JSF or other frameworks to manage the flow of the application. For me, I look for ways to avoid using those big frameworks. A simple AJAX-enabled form with services to process the data is what I try to create.
That’s an excellent way of looking at it. The baseline I use for most of my recommendations is “what do you know already?”
Many of the development teams asking that question are new to portal. Their job is going to be complicated in the short-term (at least) due to having to learn portal, portlet development, probably some theme/skin development, and who-knows-what-else, so why add in something else (JSF, Spring MVC, etc) that will complicate further instead of simplify.
If the dev team already knows JSF, Spring MVC, etc, and they only have to learn how to use it in a portlet, then there’s less downside to using one of those frameworks.
I totally agree with your mantra “small footprint, low complexity” and with your conclusion.
Mixing JSF and Portlet lifecycles add no values and is ot very intuitive. And integration between JSF/Portlet bridges and application servers is a bit chaotic.
As you suggested, Ajax frameworks and REST apis are making things easier for developers, and provide a better experience for the end users.
With he Dojo Toolkit and its custom widgets features for instance, it is very easy to reuse the same views in standalone JSF web aplication and in plain portlet without having to maintain distinct server side code.