Jetspeed Proposal: MVC Portlet
Version: $Revision$
Proposed by: Tod Kuebler (tkuebler@cisco.com)
URL: http://www.kuebler.org/MVCPortlet/MVCPortlet.html (also see http://issues.apache.org/bugzilla/show_bug.cgi?id=17756)
Status: Revised Proposal
Date: February 23, 2003

I've noticed that one of the barriers to entry for portlet development is 
learning all the different portlets including their inconsistencies in 
handling events, etc.   I have a proposal that might help that and wanted 
your input.  IMHO it would be extremely useful to have a base portlet that 
would implement the MVC paradigm in a portlet context and de couple the 
action handling  and context idea from the specific templating language.

I've got a working prototype including a hello world example that uses the 
same portlet and action for JSP and Velocity templates.  I have included 
the UML diagrams for your perusal.  The package names, ect would obviously 
be different.

Summary:
========

1) A base portlet that includes common action handling and context support 
for all MVC type portlets such as JSP,Velocity,etc.
2) It should encapsulate/implement the basic MVC idea and provide action 
event handling similar to the current velocity portlet.
3) Support for different View technology will be through a 
ViewProcessorFactory that returns a ViewProcessor (JSPViewProcessor,etc)
	- consumes the context
	- init during portlet init cycle with the portlet object
	- evoked after action handling
	- view type, etc is determined by portlet registry entry
	- the mapping of the type to class/module will happen via a ViewFactory 
properties file
	- returns the same type as the getContent() method of the Portlet

4) Developers will typically only write actions and templates 
(JSP,velocity,XSLT,etc).
5) There will be a common context object for all templating types containing *
		- rundata object reference
		- portlet object reference
		- js_peid string
		- portlet config object reference

6) The initial implementation should provide support for JSP, Velocity, 
RSS, HTML, and XSLT.
7) Future versions should include support for WebServices, etc
8) It will extend the jetspeed AbstractInstancePortlet


* note on #4: The XSLT ViewProcessor will be a little different/difficult 
due to XSLT's runtime-static-variable nature (ie, you can't do things like 
use variable substitution from the data source to do XPath pattern 
matching) and lack of context idea.  Maybe the context objects listed will 
be added to the xml input as xml (limited) or the xalan-java extensions 
will be used to allow them to be accessed within the style sheet via custom 
tags.  Another option would be to support template chaining and 
pre-processing (parse the data to create a style sheet to be used on the 
data). Another option would be to use some other templating technology to 
create the style sheets dynamically (jsp templates to create the xsl 
templates).  Ideas here are definately welcome.