...
- Struts
- Spring
- MVCPortlet
- JavaServer Faces
MVCPortlet
Let me start off with MVCPortlet. This framework was built by Nabh Information Systems, Inc (http://www.nabh.com/). It is the only framework that was built with Portlets in mind. The framework is available as open source, but appears to be tightly controlled by Nabh. The website itself had a strange feel to it, during navigation (appears cookies, may have tracked which pages you were on, rendering the standard back/forward buttons useless). The framework appears like many others to be based on using JSP pages for a "view" technology and providing a framework of java code for helping write the back-end logic. For me, a very significant impression was made by looking at the JSP pages presented in the documentation, and how most everything was done with scriplets. The JSP pages were more 'java' code then they were anything else. It is my recommendation that if JSP pages are used tag libraries should be used as much as possible, scriptlets should not be required.
I recommend against using MVCPortlet for three reasons. 1) The heavy use of scriplets implies a poor overall design. 2) The framework is still considered beta, and therefore could undergo fundamental api changes causing us to have to rewrite code to upgrade to a stable release. 3) There is no past history with the Nabh community to know what the life expectancy of this framework is.
JavaServer Faces
In the last year the JavaServer Faces (JSF) technology has gathered a pretty decent following. JSF 1.0 was created under the Java Community Process with JSR-127. Since then version 1.1 has been released and version 1.2 is in the works (JSR-252). The goal of JSF was to allow people to think about building web applications in a different way. Allow developers to build components and not worry about creating servlets, pages, or views. The way this is accomplished in a web environment is with the JSF technology owning the servlet that is used and playing a heavy role in the resulting HTML that is sent to the browser. JSP pages seem to be the only view technology current available (although the specification allows room for other view technologies to be developed).
...
I recommend against using JavaServer Faces for the following reasons. 1) portlets are not officially supported, and the portlet-add on library appears unstable in uPortal 2.4+. 2) memory could be a concern if all beans are always created for all user login sessions and there is no way to reuse a paticular bean acrosss different users sessions. 3) it's very different from other portlet/servlet technologies and could be harder for the uPortal community to initially support. 4) There is no apparent support for Portlet Modes or Preferences.
Struts
Struts is a very popular and widely adopted MVC framework for the web. The current stable version is 1.2.4 and 1.2.6 is currently in beta. Struts is also based on Servlet technology and does not currently directly support Portlets. There are currently two proposals for Struts 2.0.x (Shale and Jericho) and it is not clear what the timeframe is for direct Portlet support.
...
Stuts is very popular and can make creating many web applications quicker, by elinimating writing most of the dispatcher logic that is typically writtent with other frameworks. However, there are many opponents to Struts as well. Regardless, the inability to get any struts based example running in the time of this research, means it is impossible to consider struts an option for now.
Spring
Spring is component based framework that accomplishes a lot more the just an MVC Framework. Spring is being used by uPortal 3 for non-MVC activities. I researched the MVC aspects that Spring current offers. The latest stable release of Spring is 1.1.5. Version 1.2 of Spring was nearing release at the time of this research. And Spring 1.3 is intended as the next release after 1.2, with a possible timeframe of Summer 2005. One component of Spring is called the "Spring Web MVC" component, and offers a framework for Servlet based web applications. The released version of Spring Web MVC does not support Portlets. There is code available in the development area of Spring (the 'sandbox' directory of the spring cvs repository) that extends Spring Web MVC for Portlet support. I followed up on the Spring Mailing Lists, the Wiki pages, and obtained and compiled the code.
...
I do not currently recommend using Spring Web MVC for the following reasons. 1) Portlet support is not part of an official release and could potentially change before making it into one. Changes could cause any uPortal code to need to be rewritten to upgrade to a more stable version of Spring. 2) uPortal 3 is currently using Spring, however, it is being written to a version that does not include Portlet support. There is a chance the version that would include portlet support might be incompatible with the version that the other uPortal code was written to. 3) the design choice of calling both the render and action methods 'handleRequest' diminishes the significant importance of these two operations.
The Code
As part of this research I tried to create an equivalent application in the frameworks I could get running. I was able to get a version of the standard number guessing game running under JavaServer Faces, Spring and "no framework". I was able to convert my "no framework" application to a Spring Portlet based example in less then a couple of hours. I made no attempt to go to/from the JavaServer Faces code, and instead just based my examples on the funcationality provided.
...
You can see the examples in the attached code. Each .zip file contains a WAR file that can be deployed in uPortal 2.4.2 (or above). The WAR file is located in a 'dist' subdirectory for each .zip archive. When publishing the portlet channel in uPortal the portlet definition Id for each example is simply the WAR filename period WAR filename (e.g., the portlet definition id for GuessNumberPortlet.war is GuessNumberPortlet.GuessNumberPortlet). The two JSF examples (JsfGuessNumberPortlet and JsfCarStorePortlet) will NOT run in uPortal 2.4.2 or 2-4-patches (head of 2.4 branch). These JSF examples will run in the CVS Head (aproximately 2.5) version of uPortal. I believe this might have to do with a newer version of pluto in the HEAD version of uPortal CVS.
Recommendation
I recommend not using any existing framework I reviewed at this time. Instead coding our portlets with a common dispatcher pattern that can be easily converted to another framework in the future (e.g., Spring Portlet MVC). I recommend we use JSP pages for view technology to take advantage of the Portlet tag library for handling Portlet URLs within the view page. We can accomplish reusability between portlets we write by using the include mechanism of JSP pages and writing coresponding backing data beans. This approach leaves uPortal as decoupled as possible from frameworks that are still in development, and does not require us spending a large number of hours writing our own framework.
Future Considerations
Although not originally looked at by this research a couple of other projects seem related that should be considered in the future.
...