David Sean Taylor wrote:
>
> ****************************************************************************
> ******
> The 'Portlet API'
>
> I haven't seen much activity in this area lately...
> How does the Layout system relate to the work being done on the portlet api?
>
It's orthogonal. The portlet API is supposed to be portal implementation
independant. Once the portlet API is defined, we can start working on
implementing a "portlet runner" that can use portal neutral components.
The proposed layout system is Jetspeed/Turbine specific and interacts with
the portlet API through an adapter class, the general picture will be
something like
user <---> [ Jetspeed Engine ] <---> [portlet runner] <--- Portlet API -- developper
^ ^
| |
site configurations portlet descriptors
> Should the portlet api be accessible in the toolbox?
> Perhaps not the entire api, but just the relevant parts, or is it something
> entirely different.
>
> ****************************************************************************
> ******
>
> It would help to make some comparisons and contrast:
>
> Is a Window Manager something like a 'control'?
Yes, except that it works at least at a pane level and not a the entry level.
This makes it easier to implement general "skins" for a site and I couldn't
find any real need for the functionality at the entry level.
> Is a Layout Manager something like a 'controller'?
Yes.
Layout managers will certainly be more complex than controllers
because you can't nest panes so we'll need something like "MultiColumnLM"
whereas in PSML the simple RowColumnController was enough for any tabular
display requirements.
> Is a Configuration like a psml resource(s)?
Roughly. There are huge differences between the 2 :
- no recursive tree-like structure because it proved difficult to build
a simple, workable customizer on these kind of structures
- all the elements have id attributes for easy reference
- the scope is very different: a PSML file was basically a site page description
for a user; a configuration file describes all the customized elements for
a given user for the whole site
Example:
with PSML, you have 5 customizable pages in your site, 2 acces modes (HTML and
WML) and 2 users + default, you get
5 * 2 * (2+1) = 30 PSML files, all independent.
If an administrator wants to modify the main page, he's screwed because there are
no links between the different PSML files.
with configuration, same example, you have:
- 5 site templates (Velocity, JSP, whatever)
- 2 * (2+1) = 6 configuration files
With the added benefit that the user configuration files only store the differences
between the user customized page and the default configuration, thus any modification
made in the default configuration is automatically propagated in all the user
configurations unless they specifically customized this pane.
> Is a Pane roughly equivalent to a colection of portlets that may be grouped
> onto a layout, like the jetspeed:ecsscreen tag in the current impl?
a Pane is roughly a non recursive PortletSet.
> Its not clear what a screenlet is.
>
It's a mistake :/ The screenlet concept is part of my implementation proposal
and shouldn't have appeared in the functional description. You can treat it
as a "portlet view".
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
