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: Parallel-processing stuff (cont. from j-user)
Date Fri, 25 Oct 2002 12:02:55 GMT
De : Josh Hone [mailto:icsad@hotmail.com]
> 
> FYI, this is my first dev post.
> 

Hi there :)

> <snip>
> 
> 1.)  To have more than one Velocity portlet on the page, since I like 
> Velocity a lot, both for interactivity and for design 
> purposes.  Its great.  
> So I needed to interact with one portlet and still be able to 
> interact with 
> others immediately after that.  Users, and especially newbie college 
> students as I may be dealing with, probably would get 
> confused by seeing $ 
> signs in front of stuff they didn't type.
> 
> 2.)  For true reuse of templates with code (many templates to 
> one class, 
> many classes with one template) you need to subdivide which 
> variables feed 
> information into which matchups of code and template.  For 
> example, $job (my 
> own class) will be something I use a lot.  I would like to 
> use templates 
> with $job referenced and have them be on the same page.  
> However, everytime 
> I change some info in one portlet I don't necessarily want to 
> change things 
> in another.  However, put something into the Context with a 
> handle and that 
> is it.  Everything that looks for that handle picks up the 
> info it carries.
> 
> So, in short, I set up some stuff that allows me to have the 
> categories or 
> groups or some other descriptor of the portlet determine 
> whether it should 
> interact with the data that is being sent into the Context.  
> This code is 
> incredibly simple and can quickly be integrated to the system 
> as I have it.  
> I am kinda busy but I will send in some code and template 
> samples as soon as 
> the weekend hits.  For long-term fixes see below.  The clean 
> short term fix 
> may be adding an official space in the portlet definition 
> (registry, xreg) 
> that can define the scope within which it should interact.
> 


So if I understand correctly waht you have implemented is shared
contexts between portlets that share a same "scope" as defined within
the portlet registry. Correct ?

I quite like this idea, because it fits nicely into another work
that I was planning to propose: portlet tools.

Currently, Jetspeed portlets can leverage Turbine tools which may
have different lifecycles (request, session, persistent, etc...) 
but are globally shared by all the portlets.

Since our current portlet model has a broken lifecycle because it
was *not* thought out initially to be used as a servlet-like component
but a simple graphic widget, using portlet scoped tools would enable
a proper lifecycle and development model for subclasses of the
Velocity and JSpPortlet:

- business logic would be implemented and tools and can have an 
  appropriate lifecycle managed by Turbine
- presentation would live in the JSP/Velocity portlet
- controller would be split between Action and the template logic 
  itself depending on the developer taste...

Adding a "portlet group" scope would enable a related set of portlets
to automatically share these tools in a common context between these
portlets

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

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


Mime
View raw message