David H. DeWolf wrote:
> <snip>
>
> Well, for my usecases (and I suspect others like an embedded webconsole
> in felix or something similar), the concept of a page is simply a
> grouping of portlets -- it has no control over the page layour
> whatsoever -- the layout itself is static - only which portlets are
> displayed changes.
>
>>
>> Perhaps a simple example of what you'd like a "page" to be would be very
>> instructive for us all. I am imagining a Aggregation Server page is
>> something like this:
>>
>> <html>
>> <body>
>> <table>
>> <tr>
>> <aggregator:portlet
>> webapp="myPortletApp"
>> portlet="myFirstPortlet"/>
>> </tr>
>> <tr>
>> <aggregator:portlet
>> webapp="linksys"
>> portlet="linksys-admin"/>
>> </tr>
>> </table>
>> </body>
>> </html>
>
>
> You hit the nail on the head. That's exatly it. The only thing I would
> add is that the portlet definitions within the tags are dynamic -- they
> come from the "portlet grouping". so it may look like:
>
>> <html>
>> <body>
>> <table>
>> <tr>
>> <aggregator:portlet
>> webapp="${portlets.[0].appContext}"
>> portlet="portlets.[0].portletName"/>
>> </tr>
>> <tr>
>> <aggregator:portlet
>> webapp="portlets.[1].appContext"
>> portlet="portlets.[1].portletName"/>
>> </tr>
>> </table>
>> </body>
>> </html>
>
>>
>> Is this the idea? To me, it looks closer to a J2 layout decorator than
>> J2 PSML data model... especially if you imagine our current decorator
>> templates written in JSP... :-)
>
>
> I think I'm still missing the line between these decorator templates
> that the layout information which is included into the PSML.
>
> For instance, this PSML fragment seems to include a lot of what I would
> think should belong in the decorator:
>
>
> <fragment id="100345" type="layout"
> name="jetspeed-layouts::VelocityTwoColumns">
> <property layout="OneColumn" name="row" value="1"/>
> <property layout="TwoColumns" name="sizes" value="33%,66%"/>
> <fragment id="100121" type="portlet" name="j2-admin::LoginPortlet">
> <property layout="TwoColumns" name="row" value="0"/>
> <property layout="TwoColumns" name="column" value="0"/>
> </fragment>
> <fragment id="100171" type="portlet" name="demo::UserInfoTest">
> <property layout="TwoColumns" name="row" value="0"/>
> <property layout="TwoColumns" name="column" value="1"/>
> </fragment>
> </fragment>
>
> Can someone explain to me where the line is drawn between the two?
>
I'll try to clarify the PSML thing:
- The PSML page lists all available *page fragments* that need to be
displayed on a given portal page. These fragments can be nested
in *fragment groups* if it make sense from a layout point of view
- these fragments are usually *portlet instances* but could be in theory
anything that can produce a compatible output stream (servlet, etc...)
- each of these fragments can be associated with *layout hints* (the
<property> elements) . These hints are specific to each layout
component (in the example above, you only provide hints for the
TwoColumns layout component) and of course, you're free to provide no hints.
- additionally, PSML allows to specify on any fragment optional
*security restrictions* (which you could think as a specialized type
of layout hint) and optional *decorators* (these decorates the portlet
output with default portal controls like minimize, maximize, edit
buttons, etc...)
In jetspeed, the aggregation implementation is done by specialized
layout portlets that read the PSML page to load all the portlet
instances they should aggregate, apply the appropriate layout hints if
available and then draw the aggregated page. In the above example, the
layout portlet used is "jetspeed-layouts::VelocityTwoColumns"
If we wanted to apply your use case to PSML you would have something
like this:
<fragment id="100345" type="layout" name="my-layouts::JSPLayoutPortlet">
<property layout="JSPLayout" name="pagename" value="mylayout.jsp"/>
<fragment id="100121" type="portlet" name="j2-admin::LoginPortlet" />
<fragment id="100171" type="portlet" name="demo::UserInfoTest" />
</fragment>
And your JSPLayoutPortlet would simply read the JSP page to use from
PSML pagename property, read the fragment definitions handled by your
JSPLayout and create a set of parameters that your JSP can use and then
delegate everything to the JSP.
It may seem a bit cumbrersome in this situation and it indeed adds some
complexity but keeping the PSML as a layout neutral portlet aggregation
descriptor enables you :
- to keep the declarative security constraints and implementations
- the ability to switch your layout strategy easily in your requirements
grow in complexity
- a standard storage format for your aggregation properties (in your
case, your list of portlet instances).
I hope it helps.
--
Raphaël Luta - [EMAIL PROTECTED]
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
