You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Homeijer <M....@devote.nl> on 2002/01/15 10:29:07 UTC
Cocoon and Jetspeed portal
Hi,
For a portal prototype I am trying to describe how it should be built using
Cocoon. I have read about jetspeed and I tried to implement a portal page in
Cocoon. If i could use the portlet mechanism from jetspeed, this would
really simplify building a portal with Cocoon.
I can see two ways of achieving this:
- Access cocoon from jetspeed. This would mean producing portlet contents
from Cocoon. This would be possible by parsing serialized output, but this
way you would probably lose a lot of benefits portlets in jetspeed have.
Another way would be to call the Cocoon environment (something like the
CLI?) and outputting the SAX events in jetspeed. I haven't seen a clean way
to output the sax events in jetspeed, but haven't look at it detailed yet.
- Build portal actions, portal layout stylesheet, portlet logic sheets and
portlet configuration layout in Cocoon. This would be a lot more work and
the overlap with jetspeed would probably be very big. I cannot see if
jetspeed is "componentized" enough to use these components in Cocoon.
Can anyone comment on this or give me some hints on the approach.
TIA,
Michael Homeijer
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon and Jetspeed portal
Posted by Santiago Gala <sg...@hisitech.com>.
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
RE: Cocoon and Jetspeed portal
Posted by Vadim Gritsenko <va...@verizon.net>.
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?
Vadim
> On the other hand, the user management is crucial to any portal
> implementation, as you are managing resources per user (like the
default
> home page, etc.).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon and Jetspeed portal
Posted by Santiago Gala <sg...@hisitech.com>.
Nicola Ken Barozzi wrote:
>----- Original Message -----
>From: "Santiago Gala" <sg...@hisitech.com>
>To: <co...@xml.apache.org>
>Sent: Tuesday, January 15, 2002 1:22 PM
>Subject: Re: Cocoon and Jetspeed portal
>
>
>>Nicola Ken Barozzi wrote:
>>
>>>----- Original Message -----
>>>From: "Michael Homeijer" <M....@devote.nl>
>>>To: <co...@xml.apache.org>
>>>Sent: Tuesday, January 15, 2002 10:29 AM
>>>Subject: Cocoon and Jetspeed portal
>>>
><snip/>
>
>>>>I can see two ways of achieving this:
>>>>- Access cocoon from jetspeed.
>>>>
>>>I haven't seen jetspeed recently, but it's how jetspeed usees/d cocoon.
>>>
>>Current cocoon support is broken in Jetspeed, and it is better that it
>>continues broken until we devise better mechanisms.
>>
>
>Yes, good point.
>
>>>>- Build portal actions, portal layout stylesheet, portlet logic sheets
>>>>
>and
>
>>>>portlet configuration layout in Cocoon. This would be a lot more work
>>>>
>and
>
>>>>the overlap with jetspeed would probably be very big. I cannot see if
>>>>jetspeed is "componentized" enough to use these components in Cocoon.
>>>>
>>>This is very interesting. As for layout, you can see that cocoon examples
>>>mimic a dashboard, a personal portal.
>>>IMHO porlets are conceptually a Reader; cocoon pipelines are more
>>>
>flexible,
>
>>>but it could be a great idea to be able to use ready-made portlets in
>>>cocoon.
>>>What is really missing in Cocoon, IMHO, is user handling. This is what is
>>>really needed.
>>>Authentication, authorization and preferences.
>>>There was a suggestion back then to make it possible to use Turbine (IIRC
>>>it's what jetspeed uses) in Cocoon too.
>>>
>>We have had some discussions around the issue back (with Ricardo Rocha,
>>Stefano, and other people around in ApacheCons).
>>
>
>Well, hope you remember me ;-) , I'm the guy that needed to configure his
>WAP phone.
>
Yeah, then somebody said "Look at the kiosk for a Phone magazine", and
we noticed that the kiosk was really www.google.com ;-)
>
>I remember the discussions well :-)
>
>>Jetspeed uses PSML to describe the page structure. It is a XML file
>>format which specifies the page layout in terms of portlets, portletsets
>>(group of portlets), portletcontrols (decorations, such as title bar,
>>etc) and portletcontrollers (ways to handle a portletset like menu, tab,
>>column, ...)
>>
>>While the format of the PSML is not satisfactory, I think it is a place
>>where cocoon effort could hook with our effort. A cocoon generator could
>>be implemented that interprets a PSML resource in terms of other cocoon
>>generators (portlets) and transformers (controls).
>>
>
>+1
>
>>There is a lot of work missing here, and I'm sure that both the PSML
>>syntax and jetspeed and cocoon developers pre-conceptions will change in
>>the process. But I think we are getting to the point where it is needed.
>>I don't think Jetspeed people would be against it either, at least if
>>changes are proposed incrementally in ways that will not break a lot of
>>existing implementations.
>>
>
>+1
>
>>In discussions we had in Jetspeed list, there were two differents points
>>of view:
>>
>>- people that thought that a portal was made by aggregation at the byte
>>stream level (like what jsp or velocity does, like what current jetspeed
>>does).
>>- people (I count in this group) that thought that the approach to
>>aggregate SAX event streams (a la cocoon) was much sounder, in that it
>>would allow multidevice support and a lot of added benefits while
>>simplifying the global design. I am working for a company that has a
>>tool to make portals this way, based on jetspeed (http://definete.com),
>>and we are quite satisfied with the results.
>>
>>A consensus was reached, and the original Portlet API proposal (I don't
>>know yet if the jsr has changed it a lot) included two portal container
>>classes: the *classic* one and the SAXPortlet based one. It included
>>also SAXPortletRequest, SAXPortletResponse, ... SAXPortlets were
>>required to return whole documents (no markup spec), not fragments.
>>
>>I agree that a lot of the authentication, authorization and preferences
>>part of cocoon is missing currently. But this should not refrain us from
>>starting moving in the right direction.
>>
>
>I agree.
>What roadmap do you propose?
>
I don't have such clear views. To get something working fast, a PSML
Generator could be written that uses services in jetspeed/turbine to
authenticate, get a PSML file and then would aggregate the referenced
portlets, controllers, ... But these also would need to be rewritten as
Cocoon generators. The output of the PSML generator could be any XML
(something like (Basic)XHTML for inline and block markup at the portlet
level, XLINK for links, maybe XFORMS for forms, PSML-like markup for
controls and controllers). Transformers later on would take care of
handling the XFORMS (see the exformula project), and resolving the links
in meaningful ways. A serializer would turn it into wap or html,
depending on the request capabilities.
It could be tricky, but I think a working toy implementation could be
delivered in a reasonable time. This depends a lot on resources
available, time, etc. This implementation could serve as a testbed for
the concepts, and suggest changes to the architecture, etc.
>
>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.
On the other hand, the user management is crucial to any portal
implementation, as you are managing resources per user (like the default
home page, etc.).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon and Jetspeed portal
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
To: <co...@xml.apache.org>
Sent: Tuesday, January 15, 2002 1:22 PM
Subject: Re: Cocoon and Jetspeed portal
> Nicola Ken Barozzi wrote:
>
> >----- Original Message -----
> >From: "Michael Homeijer" <M....@devote.nl>
> >To: <co...@xml.apache.org>
> >Sent: Tuesday, January 15, 2002 10:29 AM
> >Subject: Cocoon and Jetspeed portal
<snip/>
> >>I can see two ways of achieving this:
> >>- Access cocoon from jetspeed.
> >
> >I haven't seen jetspeed recently, but it's how jetspeed usees/d cocoon.
> >
> Current cocoon support is broken in Jetspeed, and it is better that it
> continues broken until we devise better mechanisms.
Yes, good point.
> >>- Build portal actions, portal layout stylesheet, portlet logic sheets
and
> >>portlet configuration layout in Cocoon. This would be a lot more work
and
> >>the overlap with jetspeed would probably be very big. I cannot see if
> >>jetspeed is "componentized" enough to use these components in Cocoon.
> >
> >This is very interesting. As for layout, you can see that cocoon examples
> >mimic a dashboard, a personal portal.
> >IMHO porlets are conceptually a Reader; cocoon pipelines are more
flexible,
> >but it could be a great idea to be able to use ready-made portlets in
> >cocoon.
> >What is really missing in Cocoon, IMHO, is user handling. This is what is
> >really needed.
> >Authentication, authorization and preferences.
> >There was a suggestion back then to make it possible to use Turbine (IIRC
> >it's what jetspeed uses) in Cocoon too.
> >
> We have had some discussions around the issue back (with Ricardo Rocha,
> Stefano, and other people around in ApacheCons).
Well, hope you remember me ;-) , I'm the guy that needed to configure his
WAP phone.
I remember the discussions well :-)
> Jetspeed uses PSML to describe the page structure. It is a XML file
> format which specifies the page layout in terms of portlets, portletsets
> (group of portlets), portletcontrols (decorations, such as title bar,
> etc) and portletcontrollers (ways to handle a portletset like menu, tab,
> column, ...)
>
> While the format of the PSML is not satisfactory, I think it is a place
> where cocoon effort could hook with our effort. A cocoon generator could
> be implemented that interprets a PSML resource in terms of other cocoon
> generators (portlets) and transformers (controls).
+1
> There is a lot of work missing here, and I'm sure that both the PSML
> syntax and jetspeed and cocoon developers pre-conceptions will change in
> the process. But I think we are getting to the point where it is needed.
> I don't think Jetspeed people would be against it either, at least if
> changes are proposed incrementally in ways that will not break a lot of
> existing implementations.
+1
> In discussions we had in Jetspeed list, there were two differents points
> of view:
>
> - people that thought that a portal was made by aggregation at the byte
> stream level (like what jsp or velocity does, like what current jetspeed
> does).
> - people (I count in this group) that thought that the approach to
> aggregate SAX event streams (a la cocoon) was much sounder, in that it
> would allow multidevice support and a lot of added benefits while
> simplifying the global design. I am working for a company that has a
> tool to make portals this way, based on jetspeed (http://definete.com),
> and we are quite satisfied with the results.
>
> A consensus was reached, and the original Portlet API proposal (I don't
> know yet if the jsr has changed it a lot) included two portal container
> classes: the *classic* one and the SAXPortlet based one. It included
> also SAXPortletRequest, SAXPortletResponse, ... SAXPortlets were
> required to return whole documents (no markup spec), not fragments.
>
> I agree that a lot of the authentication, authorization and preferences
> part of cocoon is missing currently. But this should not refrain us from
> starting moving in the right direction.
I agree.
What roadmap do you propose?
Is authenticaion-authorization-userprefs more important than PSML use?
Ken
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
Re: Cocoon and Jetspeed portal
Posted by Santiago Gala <sg...@hisitech.com>.
Nicola Ken Barozzi wrote:
>----- Original Message -----
>From: "Michael Homeijer" <M....@devote.nl>
>To: <co...@xml.apache.org>
>Sent: Tuesday, January 15, 2002 10:29 AM
>Subject: Cocoon and Jetspeed portal
>
>
>>Hi,
>>
>>For a portal prototype I am trying to describe how it should be built
>>
>using
>
>>Cocoon. I have read about jetspeed and I tried to implement a portal page
>>
>in
>
>>Cocoon. If i could use the portlet mechanism from jetspeed, this would
>>really simplify building a portal with Cocoon.
>>
>
>Apart from any opinion on portlets, there is a JSR too that wants to
>standardize portlets, headed IIRC by IBM.
>
Latest news! There are *two* jsrs 162 and 167, which looks like there is
a political fight around the area... ;)
I don't know what will come out of this thing. I'm trying to be present
(either as individual, or appointed by Soluziona Software Factory) in
the process.
>
>>I can see two ways of achieving this:
>>- Access cocoon from jetspeed.
>>
>
>I haven't seen jetspeed recently, but it's how jetspeed usees/d cocoon.
>
Current cocoon support is broken in Jetspeed, and it is better that it
continues broken until we devise better mechanisms.
>
>>- Build portal actions, portal layout stylesheet, portlet logic sheets and
>>portlet configuration layout in Cocoon. This would be a lot more work and
>>the overlap with jetspeed would probably be very big. I cannot see if
>>jetspeed is "componentized" enough to use these components in Cocoon.
>>
>
>This is very interesting. As for layout, you can see that cocoon examples
>mimic a dashboard, a personal portal.
>IMHO porlets are conceptually a Reader; cocoon pipelines are more flexible,
>but it could be a great idea to be able to use ready-made portlets in
>cocoon.
>What is really missing in Cocoon, IMHO, is user handling. This is what is
>really needed.
>Authentication, authorization and preferences.
>There was a suggestion back then to make it possible to use Turbine (IIRC
>it's what jetspeed uses) in Cocoon too.
>
We have had some discussions around the issue back (with Ricardo Rocha,
Stefano, and other people around in ApacheCons).
Jetspeed uses PSML to describe the page structure. It is a XML file
format which specifies the page layout in terms of portlets, portletsets
(group of portlets), portletcontrols (decorations, such as title bar,
etc) and portletcontrollers (ways to handle a portletset like menu, tab,
column, ...)
While the format of the PSML is not satisfactory, I think it is a place
where cocoon effort could hook with our effort. A cocoon generator could
be implemented that interprets a PSML resource in terms of other cocoon
generators (portlets) and transformers (controls).
There is a lot of work missing here, and I'm sure that both the PSML
syntax and jetspeed and cocoon developers pre-conceptions will change in
the process. But I think we are getting to the point where it is needed.
I don't think Jetspeed people would be against it either, at least if
changes are proposed incrementally in ways that will not break a lot of
existing implementations.
In discussions we had in Jetspeed list, there were two differents points
of view:
- people that thought that a portal was made by aggregation at the byte
stream level (like what jsp or velocity does, like what current jetspeed
does).
- people (I count in this group) that thought that the approach to
aggregate SAX event streams (a la cocoon) was much sounder, in that it
would allow multidevice support and a lot of added benefits while
simplifying the global design. I am working for a company that has a
tool to make portals this way, based on jetspeed (http://definete.com),
and we are quite satisfied with the results.
A consensus was reached, and the original Portlet API proposal (I don't
know yet if the jsr has changed it a lot) included two portal container
classes: the *classic* one and the SAXPortlet based one. It included
also SAXPortletRequest, SAXPortletResponse, ... SAXPortlets were
required to return whole documents (no markup spec), not fragments.
I agree that a lot of the authentication, authorization and preferences
part of cocoon is missing currently. But this should not refrain us from
starting moving in the right direction.
I hope this helps.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon and Jetspeed portal
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Michael Homeijer" <M....@devote.nl>
To: <co...@xml.apache.org>
Sent: Tuesday, January 15, 2002 10:29 AM
Subject: Cocoon and Jetspeed portal
> Hi,
>
> For a portal prototype I am trying to describe how it should be built
using
> Cocoon. I have read about jetspeed and I tried to implement a portal page
in
> Cocoon. If i could use the portlet mechanism from jetspeed, this would
> really simplify building a portal with Cocoon.
Apart from any opinion on portlets, there is a JSR too that wants to
standardize portlets, headed IIRC by IBM.
> I can see two ways of achieving this:
> - Access cocoon from jetspeed.
I haven't seen jetspeed recently, but it's how jetspeed usees/d cocoon.
> - Build portal actions, portal layout stylesheet, portlet logic sheets and
> portlet configuration layout in Cocoon. This would be a lot more work and
> the overlap with jetspeed would probably be very big. I cannot see if
> jetspeed is "componentized" enough to use these components in Cocoon.
This is very interesting. As for layout, you can see that cocoon examples
mimic a dashboard, a personal portal.
IMHO porlets are conceptually a Reader; cocoon pipelines are more flexible,
but it could be a great idea to be able to use ready-made portlets in
cocoon.
What is really missing in Cocoon, IMHO, is user handling. This is what is
really needed.
Authentication, authorization and preferences.
There was a suggestion back then to make it possible to use Turbine (IIRC
it's what jetspeed uses) in Cocoon too.
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon