Generic MVC Portlet Proposal:

This actually refers to a set of classes that implement the idea.
 
MVC refers to the 'Model View Controller' design pattern .  This idea is basically that you keep separate the data (Model) you want to display from the format the data is being displayed in (the View).  The merging of the two is handled by the Contoller.   More info on this design pattern can be found at Sun's Site.

As I see it the portlet should really be the implementation of a MVC system, and not actually hold any of the user developed components, simply implement the MVC, providing the developer with a framework to do her work in, and isolating her from the details of portal life in much the same way a servlet + struts does for the servlet world.

That is not to say however that the other portlets and way of developing can't co-exist happily with this new porlet.  I'm only proposing a new portlet, not doing away with all the others. :)

1. Simplify portlet development lifecyle by removing one of the three components from the developer landscape.
• The (MVCPortlet) Generic Model View Controller Portlet). simplifies portlet development by removing one of   the classes/APIs that the developer needs to know, namely the Portlet API.  This allows the developer to concentrate on the two things directly applicable to the portlet in question; the View and the Model.


2. Make the MVC design pattern available to all  portlet types in a consistent manner.
• The Velocity portlet that ships with Jetspeed has a MVC implementation tied into Turbine actions.  The MVCPortlet extends that to all portlet types and improves it by making the portlet the MVC container/controller and pushing the View processing over to a ViewProcessor, which is a plugable interface responsible for processing the view with a MVCContext passed to it containing all the data it needs


3. Supporting a new view technology becomes simpler, all a developer has to do is read and implement the ViewProcessor interface and add the entry into the registry or prefs file



4. The view is cleanly abstracted and clear, ie you dont' read a portlet API to figure out how a template gets processed.



5. It doesn't tie you to the 1 portlet = 1 view technology scenario, you could easily add the ability to set the template type and name as part of the request parameters, mixing view technology for a single portlet, all controlled by the action and requiring no new portlet.



6.  If the function of the current subclassing approach is to provide the same functionality (ie view processing) over and over again, that sounds more like a pluggable component factory pattern to me.