Neeme Praks wrote:
> -----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.
>
Regarding this point: we have already discovered that the layout process
should pass the request & session info down. What I propose it to wrap
Turbine's RunData object into a JetspeedRunData for each portlet, that will
have the original behaviour, but:
(One idea for content expiration) If a portlet adds an "Expires" field, this
object will take the minimum of the current Expiration time and the
argument, to ensure that, in a piecemeal screen, the expiration is set to
the minimum value.
We could also decorate the "addParameter" calls with a portlet name/id, so
that namespace issues are resolved.
It will again be a kind of "piecemeal" rundata, so that each portlet can
safely believe that it is being drawn as a turbine screen, but the output is
handled up there.
>
> 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...
>
I hope this is not difficult to merge into the changes for rundata
passing...
<snip of nice ASCII-art :-)>
>
> 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.
>
I hope that Cocoon 2 passes request and session data some how (XSL
parameters? vars?)
>
> 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.
>
> 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.
>
I had already thought about this way to generate turbine screens. SAX is
clearly more stream oriented than DOM.
>
> 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]
--
--------------------------------------------------------------
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]
