Stefan Reich wrote:
> Hi everybody - sorry for the long posting -:
>
>
>
> We are a group of students taking part in a course focused on web
> application
> development. We've been working on/with jetspeed for some time now, focusing
> on extending the possibilities in portlet development. We have a working
> implementation of our ideas.
>
> We'd like to hear some feedback from you, regarding:
> * what do you think about our work?
It is great to see people experimenting and using Jetspeed code.
> * are there other existing approaches to solve the same problems?
We have been thinking about these issues. For instance, your "worklet" stuff could
be integrated into Turbine pull model, so that a worklet populates the Toolbox of one
or more related portlet views. The namespace issue, I think, needs more work, but your
ideas go in the right direction.
> * if not, is there a chance to integrate these things? how would the
> next steps for doing so look like?
I think people here would like to see how your implementation looks (you speak later
about a demo site).
Also, you could make your code available for download, to discuss on changes...
>
> Basically, the main tasks we adressed were
>
> 1. that all portlets on a page share a common namespace, which may lead to
> unwanted collisions between independent portlets
>
This is a big issue. Nevertheless, I think it should be done transparently to the
portlet, i.e.
via the future PortletRequest and PortletResponse
(or PortletRunData) objects. A portlet should not be concerned with namespaces.
> 2. that portlets currently can not hold any state information
This is the "model" in a MVC implementation. a portlet is now model+view. As Raphaël
said,
we should separate. Raphaël spoke about portlet ---> model , screenlet ---> view. You
seem
to speak about worklet ---> model, portlet ---> view.
>
> 3. that there might be portlets which take a long time to compute their
> results, but the user should get a page immediately
>
> 4. two portlets on one page may work on the same set of data - when that
> happens, inconsistencies can occur when one portlet updates the data from
> user input while the other has already rendered its output
>
> * To solve problem 1., we added a parameter called namespace into the
> psml file:
>
>
> <entry type="ref" parent="NamespaceTestPortlet">
> <parameter name="namespace"
> value="namespace_1"/>
> <layout position="4"/>
> </entry>
>
> <entry type="ref" parent="NamespaceTestPortlet">
> <parameter name="namespace"
> value="namespace_2"/>
> <layout position="5"/>
> </entry>
>
> Our Portlet then uses a function for separating its variables into the
> different
> namespaces (withNamespace("name") would return "namespace_1.name" in the
> first
> portlet, and "namespace_2.name" in the second portlet).
>
I would prefer having it in a more transparent way. But it goes in the right
direction.
> * To solve problems 2 and 3, we introduced a new concept called Worklet.
> Worklets
> are independent objects, which are kept in a central worklet repository. The
> portlets can lookup and insert worklets into the repository. These can
> be used
> to preserve state information and to let computations run in the background.
>
I think there are two different concepts going on here. One is the model/view
separation.
A different one is having non-display related tasks running in the background.
If we say portlet ---> model, screenlet ---> view, your worklet would be tasks
started by the portlet, that hold and modify portlet stace (like session EJBs).
The screenlet ---> view would query the model (which holds the state changes that
the worklet ---> daemon/worker threads did) and display.
> Also, different portlets may access the same worklet, and that way share
> state.
>
> We have standardized mechanisms for expiring worklets started by users who
> are no longer active. On the other hand, we have also encapsulated the usual
> "isrunning", "isdone", "shouldbeterminated" and so on states used for long
> running worklets (MarathonWorklets).
>
> * For the first three problems, we have not changed the Jetspeed framework.
> However to adress problem 4, we added a new function, called update, and
> processing a request works in two phases now:
>
> - call update on all Portlets (there is a dummy implementation for backward
> compatibility)
> - call getContent on all Portlets
>
> That way, we can ensure that the results of the requests are consistent when
> the actual output is generated.
>
>
>
> If anyone is interested, we can set up a demo page on one of the
> university's servers here.
>
Pleae, do it (+1)
> Cu... Stefan, Stefan, Jens
>
Regards,
Santiago
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
