Parallel-processing stuff (cont. from j-user)

[Josh Hone <ic...@hotmail.com>]

Hi all -

FYI, this is my first dev post.

Raphael wanted me to talk about what I have that can work on parallel 
processing of portlets.  Basically what I have is like a hack that 
subdivides the Velocity Context and helps a user decide what on their page 
should work together.  I started this when I started with Jetspeed this 
summer and needed some added functionality, as follows:

Whenever you submit a form in a Velocity portlet and there is more than one 
Velocity portlet on the page, then ya know what happens.  Out of the box, 
any portlet that cannot find a variable in the Context with a name (and 
type) that it needs immediately forgets what it was doing.  You get 
$something in text boxes and etc.  I needed a couple of things:

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.

The long term fix to this problem lies with recognizing that it is 
inherently a workflow issue.  As soon as we incorporate a data structure 
like the GGF workflow schema or alternate solution then that seems like a 
nice long term thing.  So not only does it address parallel processing but 
any type of time scheme (asynchronous, etc.) and goes a bit further with 
what it can do.

I have time to answer any questions and clarifications and comments, so feel 
free.

Josh Hone

BTW, I have another set of posts out there asking if a portal user being 
able to create portlets is a good idea.  I know you are busy with the 
upcoming release but please please respond.

_________________________________________________________________
Unlimited Internet access for only $21.95/month.  Try MSN! 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>