portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Kuebler <tkueb...@cisco.com>
Subject RE: Generic MVC Portlet Proposal
Date Thu, 27 Feb 2003 19:21:35 GMT
I'll try one more time on the attachments, but I fear they are being 
stripped off somewhere...


At 12:02 PM 2/27/2003 +0100, Luta, Raphael  (VUN) wrote:

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

Yes.  It seems there are several advantages to this approach:

One, to support 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 pref file.   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.

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

Three, 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.

Four, all of a developers portlet action handling and context objects would 
be handled the same, regardless of view technology.

Five, the same nice action handling that the velocity portlet enjoys is 
extended to the other view types.  There is a new context object decoupled 
from velocity, and a PortletActionEvent and PortletAction that decouple 
those functions from velocity and handle the actions in the same way for 
everyone.

It was really interesting to move the code from the portlets into the 
Velocity, JSP,  RSS, and XSLT view processors for the prototype, it became 
really clear to me that this is a natural separation because most of it was 
cut and past, and the resulting cut portlets seem so common as to 
be  laughable, except for Velocity, which implements the MVC via 
actions/context, and that looked a lot like the new GenericMVCPorlet.   The 
actual view processing function seems to be separate from the core 
functionality of a portlet and more of a pluggable/interchangable 
component, thus the factory pattern.

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. :)

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

I suppose the context object could support scope in much the same way as 
the sesion object does.  In fact, this could be more easily accomplished if 
people were all using the same base portlet and a common context interface 
and not writing/extending their own for each and ever  use.  The prototype 
has a portlet instance scoped context and interportlet communication is 
handled via the normal methods in the actions.

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

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

I totally agree. :)


-tk



Mime
View raw message