You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2006/01/02 20:34:33 UTC
Re: Aggregation Server (AKA Portal Light)
Randy Watler wrote:
> David,
>
> I step into this thread with some trepidation, but it is done
> now... :-). I'll just focus for now on what I can describe/explain
> concerning J2 components and PSML. I hope simply to save others some
> effort in replying... here goes...
Thanks for your input and guts Randy, I found your comments very useful.
>
> On Sat, 2005-12-24 at 00:30 -0500, David H. DeWolf wrote:
>
>>>>3) Ability to define a "page" or grouping of portlets at runtime but
>>>>have no layout associated with it.
>>>>
>>>
>>>Will you be using PSML or another technology?
>>>
>>
>>Excuse my ignorance here. . .
>>
>> From what I've seen in jetspeed over the past week or so, PSML is a
>>markup language which defines how pages are layed out. Is this correct?
>> If so, then know, I'd prefer not. My idea of a page is much simpler,
>>it's basically a grouping of portlets which are aggregated together. It
>>contains no layout information whatsoever.
>
>
> PSML contains elements that encapsulate the the following concepts:
>
> 1. Fragments that serve as the links to portlet instances.
> 2. Fragment hierarchies to support the J2 notion that layouts ARE
> portlets.
> 3. Pages that contain fragments.
> 4. Folders that organize groups of Pages.
> 5. Security constraints on these basic entites.
> 6. Menu/Navigation declarations on these same basic entites.
> 7. Localized metadata for PSML elements.
>
> Almost all of this markup is optional. If one wanted only to represent
> Fragments in Pages, it would be a proper subset of PSML and could
> certainly be represented by the Page Manager.
How about if one only wanted to specify *what* portlets existed in a
logical grouping -- not necessarily where they were layed out?
I think what confuses me is that the examples I see all include page
"fragments" which define layout properties such as columns, rows, etc. .
. Am I understanding correctly that this can be left out? If so, is it
possible for me to exclude the service that manages these layout
properties from my jetspeed configuration? Or is it a depdency of the
core components?
>
> Even looking at the Geronimo Admin Console, there are many of these
> concepts present... but they indeed might be coded in "content" or the
> "web page" JSP/Servlet vs. being modeled as is done here with PSML. With
> J2, we have tried to reduce, or even eliminate in most cases, page
> content authoring external to the portlets themselves.
Yes, after these discussions, I agree that jetspeed is the right portal
for geronimo. The fact that they want to support enterprise portals
(with or without the webconsole) tipped the scale for me. Having the
ability to manage the scope of jetspeed within the app server vs.
managing two totally different portals is undoubtedly a better approach.
Additional functionality such as what you describe here definately
adds to the argument.
>
> I can see why one might believe this solution is out of place in a
> portal "ME" environment. However, what confuses me on this front is why
> you would want to explicitly model the notion of a page at all? If you
> start down that path, it is easy to argue for the inclusion of all or
> most of PSML, (that is how I think we got there with J2). I mean to say:
> isn't the notion of portlets and a web page template with embedded tags
> in it where the portlets are to go sufficient in your case?
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?
>
>
>>>Also, if you don't like the Jetspeed solution, just say so.
>>>Gawd knows we are not perfect. There are problems.
>>>Just speak your mind and tell us why its just unusable for a lightweight
>>>portal solution.
>>
>>Perhaps any responses to these comments should go in another thread so
>>that we don't get off track. . .
>>
>>I can't say I don't like jetspeed. From what I can tell, it simply does
>>not meet my requirements. That said, there are two things that are not
>>ideal IMHO (and perhaps my understanding is wrong and these really
>>aren't issues):
>>
>>I don't really like is the repo layout and build -- I don't think that
>>they lend themselves to easily discovering the core components of
>>jetspeed. I found I had to research and look around quite a bit to feel
>>like I had any clue what lived where.
>
>
> Indeed, I too found the components a bit confusing when I first started
> to look at J2. Some of the components also have some deps that lead to
> further confusion. However, we have been improving the sitution over
> time. Bridges have been pulled out. Components have been decomposed. The
> core itself is now a component. It is getting better. To be honest
> though... all of the components generate a separate jar in the repo and
> live in a top level directory called 'components': I am not sure how to
> make component discovery any easier... :-). I suppose we could make the
> pipeline elements into free standing components... might that help?
Yes, I definately agree it's getting better. And there have been
additional conversations one the list lately that suggest it's still
improving -- great work :)
>
> If you have any ideas here, we are all ears. We know we need to simplify
> the build... a task you have volunteered to lead IIRC as we move to
> maven2. To be honest, builds always evolve over time and often lag
> behind the product architecture. We can fix that easily!
Sure. . .I'm definately still game for helping with a Maven2 build if
it's desired. Now that the hollidays are over, I'll hopefully be able
to provide some assistance with that.
>
>
>>The other thing I don't like is the setup required. I'd like to be able
>>to take a jetspeed war, deploy it, and go. . .I don't want to have to
>>create db schemas, build for specific app servers, etc. . .before
>>running. IMHO, either an installer should do that work for me, jetspeed
>>should initialize itself at startup, or the default build should not
>>require this prep work.
>
>
> Again, we are working on this. It is convenient from a development POV
> to have the build be able to deploy to the container, run integration
> tests with a database, etc.. I think it is safe to say that all of these
> "extensions" to the build you have listed here grew out of the
> development environment we have been living in for 2 years.
>
> J2 just had its first release and now we are working on an installer to
> help take some of the "do everything" pressure off the builds. Again,
> things should now get better on this front.
>
>
>>Beside those minor things, I really have no problem with jetspeed.
>
>
> That is good. You do not seem to have any issues with the product
> architecture itself... other than its footprint... !ME if you will. I am
> left with the impression that this is the only requirement J2 does not
> meet functionally from your POV. I have to admit that if you are talking
> about a "portal on a chip", anything seems heavy to me, even Pluto!
>
> Getting back to reality, I think we need to know how severe your
> footprint requirements really are. If you are truly shooting for a J2ME
> environment on my refrigerator, I am not sure anything can be common
> between the J2 and the Aggregation Server projects... but I dont think
> that is the case really.
>
> It seems that using J2 components that are "heavier" than you would like
> would not be a problem, as long as they scaled down gracefully to your
> needs. The same case can be made for the core J2 component... and that
> is what I think the J2 community is trying to propose.
Sure. . and I'm all for supporting that effort. Let's run with it for a
while and see if we can make it happen.
>
> Let me digress...
>
> For example... lets take the Pluto test harness example so often sited
> as a reason to need something "light". During ApacheCon, I took the
> writing portlets tutorial that was given by Noel. Because of a
> communication problem between DST and Noel the previous day, the
> tutorial was given using the Pluto test harness. Being a J2 booster, I
> did the entire tutorial on J2 using our newly minted installer. Here is
> all I had to do to get every sample portlet working on a running J2:
>
> 1. Copy build portlet apps into J2's deployment directory.
> 2. Switch the current page in J2 to edit mode.
> 3. Click on add portlet.
> 4. Select portlets I wanted to add.
> 5. Click Done.
>
> Really, it is that easy! I also ran the Pluto test harness. It was less
> intuitive IMO and certainly looked like a test harness rather than a
> portal. I had to do something like this:
>
> 1. Load the portlet app.
> 2. Define a "page" layout nxm columns/rows.
> 3. Select portlets that I wanted to see in each cell.
> 4. Tell it to continue past a few prompts and finally display the
> "page".
>
> To me, the two platforms were about equivalent functionally for the
> tutorial topics, with J2 getting the nod in my eyes because it looked
> like a portal should look and the students would have the satisfaction
> of knowing they could write portlets on a feature rich portal
> environment. (J2 losses points overall because the install can be more
> of a headache in its current form, but we have already discussed that
> above).
>
> My point here is that J2 can scale down to just about any functional
> level... even suitable for a portlet writing tutorial straight out of
> the box. In my mind, we just need to make the man behind the curtain fit
> into your ME footprint requirements and clean up the install/build
> situation.
>
> Oh well, went a bit beyond my opening charter here... better stop now!
>
> Randy
>
>
>
Re: Aggregation Server (AKA Portal Light)
Posted by Raphaël Luta <ra...@apache.org>.
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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/