cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Cocoon and Jetspeed portal
Date Tue, 15 Jan 2002 14:45:05 GMT
Vadim Gritsenko wrote:

>I'm trying to follow on this one...
>
>>From: Santiago Gala [mailto:sgala@hisitech.com]
>>
>>Nicola Ken Barozzi wrote:
>>
>>>Is authenticaion-authorization-userprefs more important than PSML
>>>
>use?
>
>>In terms of "doing it right", no. In terms of "delivering something
>>
>real
>
>>soon now", yes. So, it depends a lot of the pressure you are under.
>>
>What
>
>>is important about PSML is that it tries to abstract aggregation at
>>
>the
>
>>rendering level, so you have a language to express that a group of
>>portlets should be shown in column, or the selected one should be
>>
>shown
>
>>and the others accessible like in tabs. This can be done at the
>>
>sitemap
>
>>level, but it will break concerns if you try to do it dynamically , as
>>the sitemap is *not* dynamic.
>>
>
>Correct me if I'm wrong, but isn't something like:
><map:generate src="frontpage.psml"/>
><map:transform src="psml2include-page"/>
><map:transform src="xinclude"/>
><map:transform src="page2html"/>
>
>is what you need here?
>What more dynamic is required here?
>

I'm not completely sure. The controls/controller do have 
request/session/persistent state (is the current portlet minimized?, can 
the user close it? which pane is selected?).  So either the 
PSMLGenerator has to take care of this or somewhere further along the 
path. This is specially true in complex PSMLs, where calls to invisible 
portlets should be avoided to keep performance. So, while the upper 
sitemap is esentially what I proposed, I don't think a simple XSLT 
transformation is desirable.

The way I see it, rendering of a page from components and state is the 
concern of the aggregator. While you can implement it as a set of 
complex transformations, it will make the concepts fade.

I see aggregation engines as window managers. While you can manage a X11 
display using only the Root window, it is better to abstract, and use 
different windows managed by the Xserver. This is the area of concern of 
the aggregation engine: isolating different 
web(apps/modules/newsitems/components...) and having them cooperate 
under the control of a user, much like a window manager in a computer.

Note that the aggregation engine is recursive: a window is a screen, 
where you could aggregate again. I think we desperately need to think of 
the web browsers (in a loose sense, as in "I request a resource and I 
get a document") as the windows of our internet operating system. So, we 
need a window manager, widgets, and a standard way to deploy 
applications in it. This is my long term vision.

Jetspeed is very far from there, but I'm satisfied, since it is moving, 
albeit slowly. The strength of Open Source is that it moves forward most 
of the time. I share the same feeling looking at Cocoon, Turbine, and 
the basic components like ant, commons, avalon, etc.



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message