-----Original Message-----
From: Neeme Praks
Sent: Saturday, August 26, 2000 9:49 PM
To: Java Apache Framework
Cc: Jon Stevens; Kevin A. Burton
Subject: RE: Some Questions on Avalon, Turbine, Cocoon, etc.
[snip]
Well, I've also been playing with the idea of Jetspeed2 for a while now
and maybe it would be the right time to share my ideas... ("release
early, release often" :-) )
I'm mainly concerned with the "front-end" of jetspeed, the part that
manages user interface (portlets, controls and controllers), and this
will be most affected by cocoon2, so I'll concentrate on this. When
moving to Cocoon2, the "back-end" won't probably change very much
anyway.
Each portlet will become stand-alone, containing UI generation code and
if there is user interaction, then also contain user input handling
logic. (Right now the UI generation is in portlets and form input
handling is in Turbine actions and I don't really like this.) This means
that any resource in the sitemap could potentially become a portlet,
given that it is capable to generate required content-type.
As a result, besides providing simple dynamic URI generation (inherited
from Turbine), Jetspeed needs POST/GET variable namespacing. Basically
it means that jetspeed should provide totally transparent form variable
name rewriting to avoid name clashes between different portlets on the
same page (similar to URL rewriting provided by servlet engine). This is
useful when I'm generating URL with some variables in querystring: if
you put variable names without any namespacing, there will be no way to
find out to which portlet these variables were meant for. Also it is
good for security if portlets have access to only their own variables.
This could possibly be achieved with simple XSLT stylesheet that
transforms all the variable names.
Also the UI building facilities should be enhanced: right now our
company has written our own solution to achieve pretty complex user
interface with Jetspeed and Cocoon. We'll contribute back our experience
from this and I believe that we'll be able to add the following things
to Jetspeed:
* pop-up window handling - you can specify that if you click on some
button, a window pops up and the result from form submission or some
link is loaded into that window
* error handling - we have already contributed some of our code back to
Turbine, but there are still some more things to come and I would like
Jetspeed to take advantage of this.
* probably missed some things...
This way Jetspeed+Cocoon starts to look like a pretty good platform to
build portals and "portal-like" web applications on...
Cocoon role: Cocoon2 provides mapping of requests based on URI and
content-type. All portlets become part of the sitemap and each has a
unique URI/URL associated with it.
Jetspeed front-end will basically consist of bunch of XSLT stylesheets
that aggregate internal content that is generated by sitemap pipelines.
Any external content will also go through the sitemap.
The PSML files will be descriptions of the content to aggregate, and
they also contain the instructions for laying everything on screen. Here
would be one hypothetical example of PSML:
<?xml version="1.0" encoding="UTF-8"?>
<portlet-set>
<controller type="xslt" src="cardcontroller.xsl"/>
<control type="xslt" src="panedcontrol.xsl"/>
<portlet-set>
<parameter name="name" value="email and slashdot"/>
<controller type="xslt" src="columncontroller.xsl">
<parameter name="cols" value="100, *"/>
</controller>
<portlet-set>
<controller type="xslt"
src="flowcontroller.xsl"/>
<control type="xslt"
src="psml/titlecontrol.xsl"/>
<portlet src="/portlets/email-app/folders"
format="text/psml"/>
<portlet
src="/portlets/email-app/folder-contents" format="text/psml"/>
</portlet-set>
<portlet-set>
<controller type="xslt"
src="flowcontroller.xsl"/>
<control type="xslt"
src="psml/titlecontrol.xsl"/>
<portlet src="/portlets/news?channel=slashdot"
format="text/psml"/>
</portlet-set>
</portlet-set>
<portlet-set>
<parameter name="name" value="favourite web clippings"/>
<controller type="xslt" src="columncontroller.xsl">
<parameter name="cols" value="50%, 50%"/>
</controller>
<portlet-set>
<controller type="xslt"
src="flowcontroller.xsl"/>
<control type="xslt" src="html/copy-html.xsl"/>
<portlet src="/portlets/webclip"
format="text/html">
<parameter name="url"
value="http://www.sun.com"/>
</portlet>
<portlet src="/portlets/webclip"
format="text/html">
<parameter name="url"
value="http://www.cnn.com"/>
</portlet>
</portlet-set>
<portlet-set>
<controller type="xslt"
src="flowcontroller.xsl"/>
<control type="xslt" src="html/copy-html.xsl"/>
<portlet src="/portlets/webclip"
format="text/html">
<parameter name="url"
value="http://www.delfi.ee"/>
</portlet>
</portlet-set>
</portlet-set>
</portlet-set>
This would generate something like this (sorry for my ASCII art :-)):
---------------------------------
| header |
|-------------------------------|
| |
| -------------- |
| |pane1|pane2 | |
| | ---------------------- |
| |--------------------------| |
| ||folders | || |
| ||--------| ./ news || |
| ||folder | || |
| ||contents| || |
| |--------------------------| |
| |--------------------------| |
| |
|-------------------------------|
| footer |
---------------------------------
The header and footer were not included in my XML markup (I haven't
really figured out how they fit nicely in the picture), maybe they
should also become portlets? Dunno yet...
Anyway the idea here is that the whole page is generated with XSLT,
probably by taking advantage of XSLT extensions. Individual portlets
will most preferably be generated with XSP. But the only requirement
would be that they output SAX events, so someone could write an adaptor
for backwards compatibility and convert ECS (and other currently used
methods for generating HTML) to SAX events.
The portlet tags refer to sitemap URIs and then the pipeline can
generate appropriate response, depending on the content type requested.
The content type does not need to be any "final" markup, it could also
be something more abstract (some subset of PSML?) that is transformed to
approprite markup further down the Jetspeed pipeline (in portletcontrol
stylesheet, for example).
After the portlet has generated the response, the result goes through
(doesn't have to, though) "portletcontrol" stylesheet that decorates the
portlet with a border and a title for example. The result from
portletcontrol stylesheet goes through portletcontroller stylesheet that
determines the layout of different portlets and portletsets. And this
nested process continues until response is serialized and sent back to
client.
Actually, after writing the above description, I realize that the
process in reversed in reality: the topmost controller starts processing
the XML file and then hands of requests to controls to generate
themselves.
Of course, there are still many pieces missing from this picture:
* where to store portletregistry? Sitemap will take over most of it's
functions (storing portlet, control and controller information), but I'm
not sure if everything should go to sitemap (especially recently
proposed security).
* how to exactly map the requests for different media types and
where/how to store user profile PSML. Any news on prowler front?
* probably missed some more...
Uhoh, turned out to be a pretty long response... hopefully makes some
sense.
Neeme
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
