pluto in Cocoon

[Ralph Goers <Ra...@dslextreme.com>]

We would like to support JSR-168 portlets in Cocoon but do not want a
full-blown portal – i.e. we want to have some pages that just render
regular html and others that have portlets on them.  It seems like this
should be doable, but I'm not sure how much of the portal engine is
required or what classes in the pluto subdirectory are needed.  The
Javadoc for org.apache.cocoon.portal.pluto(.*) (at least in 2.1.5) isn't
particularly helpful in figuring out what the classes do, so any help
would be appreciated.

RE: pluto in Cocoon

[Carsten Ziegeler <cz...@s-und-n.de>]

Ralph Goers wrote: 
> 
> Thanks Carsten,
> 
> I'm not sure if I want/need to strip it down or not.  What we 
> want is a "normal" web site that can also display JSR-168 
> portlets.  We'd like a common layout across all the pages 
> though.  I've just started looking at this, but it looks like 
> most of the portlet functionality is handled by the 
> PortalGenerator, so it would appear that this should be 
> fairly easy to do.  The PortalGenerator calls a 
> PortalManager, which I haven't really looked at yet. I assume 
> the PortalManager needs the portal configuration to do its work.
> 
Yes, for web sites you can use the static profile manager. By
this all users of your website get the same profile with the
same content (no user/role based personalization).

> We also have the case where a single webapp will be hosting 
> multiple portal sites. From what I can tell this should also 
> work since the portal configuration looks like it uses cocoon 
> pipelines.  
> Here, the issue would
> be how to do personalization differently.   The portal 
> documentation says
> that you can use your own persistence layer but doesn't explain how.
:) 
This is done by own components. E.g. the ProfileManager manages the 
profile (obviously ;) ) You can make your own implementation
that fetches the profiles in the manner you want.
Or you can provide your own implementation of a ProfileLS component,
for loading/saving of the profile.

In general, for each task a specific component is available that
you can customize for your needs.

HTH
Carsten

RE: pluto in Cocoon

[Ralph Goers <Ra...@dslextreme.com>]

Thanks Carsten,

I'm not sure if I want/need to strip it down or not.  What we want is a
"normal" web site that can also display JSR-168 portlets.  We'd like a
common layout across all the pages though.  I've just started looking at
this, but it looks like most of the portlet functionality is handled by
the PortalGenerator, so it would appear that this should be fairly easy to
do.  The PortalGenerator calls a PortalManager, which I haven't really
looked at yet. I assume the PortalManager needs the portal configuration
to do its work.

We also have the case where a single webapp will be hosting multiple
portal sites. From what I can tell this should also work since the portal
configuration looks like it uses cocoon pipelines.  Here, the issue would
be how to do personalization differently.   The portal documentation says
that you can use your own persistence layer but doesn't explain how.

So again, any advice would be helpful.

Thanks


Carsten Ziegeler said:
>
>

>>
> If I understand you correctly, you want to strip down the portal
> engine and remove the unused classes?
> For using Pluto in Cocoon you need all classes in
> org.apache.cocoon.portal.pluto(.*) - this is the implementation
> required by Pluto to connect Cocoon and Pluto.
>
> Carsten
>
>

RE: pluto in Cocoon

[Carsten Ziegeler <cz...@s-und-n.de>]

 

> -----Original Message-----
> From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com] 
> Sent: Monday, August 09, 2004 5:28 PM
> To: dev@cocoon.apache.org
> Subject: pluto in Cocoon
> 
> 
> We would like to support JSR-168 portlets in Cocoon but do 
> not want a full-blown portal - i.e. we want to have some 
> pages that just render regular html and others that have 
> portlets on them.  It seems like this should be doable, but 
> I'm not sure how much of the portal engine is required or 
> what classes in the pluto subdirectory are needed.  The 
> Javadoc for org.apache.cocoon.portal.pluto(.*) (at least in 
> 2.1.5) isn't particularly helpful in figuring out what the 
> classes do, so any help would be appreciated.
> 
If I understand you correctly, you want to strip down the portal
engine and remove the unused classes?
For using Pluto in Cocoon you need all classes in
org.apache.cocoon.portal.pluto(.*) - this is the implementation
required by Pluto to connect Cocoon and Pluto.

Carsten