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
