portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luta, Raphael (VUN)" <Raphael.L...@groupvu.Com>
Subject RE: Generic MVC Portlet Proposal
Date Thu, 27 Feb 2003 11:02:55 GMT

De : Todd Kuebler [mailto:tkuebler@cisco.com]
> 
> Hi folks,
> 
> 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.
> 

I quite like the idea but your attachements don't seem to get through 
to the mailing-list... If this persist I'd suggest you either go and
post them on a webserver somewhere or send them to me and I'll make
them available from my cvs.apache.org account so that anybody can access
these.

> 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
> 

Does that mean that you want to support multiple view technologies
within the same portlet ? If no, what advantages do you see to
have ViewProcessors rather than simple subclasses like we currently
have ?

> 4) Developers will typically only write actions and templates 
> (JSP,velocity,XSLT,etc).

++1

> 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
> 

One of the key issue to address with this kind of proposal is context
scoping: how to easily enable collaboration between portlets in the
same page while at the same time preventing context corruption/overlaps.

> 
> * 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.
> 

I don't think XSLT has actually a lot of benefits in the current Jetspeed
architecture so I won't not personnally invest a lot of time in a convoluted
implementation of this view type. If someone *really* wants to use XSLT
for its portlets he'll probably be better off using Cocoon Portal features
than Jetspeed...

--
Raphaƫl Luta - raphael@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/

**********************************************
Vivendi Universal - HTTP://www.vivendiUniversal.com: 
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material of Vivendi Universal which is for the exclusive use of the
individual designated above as the recipient. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, 
this information by persons or entities other than the intended recipient 
is prohibited. If you received this in error, please contact immediately 
the sender by returning e-mail and delete the material from any computer. 
If you are not the specified recipient, you are hereby notified that all 
disclosure, reproduction, distribution or action taken on the basis of this 
message is prohibited.

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message