[EMAIL PROTECTED] wrote:
>
> Raphael Luta wrote:
> >
> > Definitions:
> > ============
> >
> > 3. Portlet
> > A portlet is the base customizable content producing unit in Jetspeed.
> > The functional description will usually not separate the portlet, as
> > portal-independent component model and the portlet, as part of the
> > Jetspeed layout system.
> > When such a distinction is necessary, the former will be called "portlet"
> > and the latter "screenlet".
>
> The meaning of the term "screenlet" cannot easily be found out without the
> definition. Perhaps we might use a more self-explaining term like
> "portlet view" ?
>
That's a defirmation of teh writing because I have the implementation
proposal written at the same time where screenlet is the base layout component
and portlet view is a subclass of screenlet which is the portlet adapter.
"Portlet view" is a totally adequate description.
> > Actors:
> > =======
> > This description may refer to the following actors:
> >
> > 1. Administrator:
> > The administrator is the owner of the portal. He's responsible for
> > designing the site templates and functionalities, configuring the
> > initial properties files and defining the appropriate permissions.
> > The administrator must understand the template language used by
> > its site screens as well as the configuration files semantics.
>
> An administrator needs not necessarily be the owner of the entire
> portal. There may be cases where a portal consists of a number of
> independent portal instances. Each of these instances may have one
> or more administrators.
>
Agreed, but I don't deal with access rights with this proposal, so
did not want to create finer roles. You can also say that the
administrator described above is also both a designer and an administrator.
> > 2. User:
> > The user is a client of the site, which is assigned specific
> > portal configurations. A user does not necessary refer to a
> > physical entity (it may be an anonymous user, a group, etc...).
> > No specific knowledge is required for the user.
>
> What does the last sentence mean ?
>
That use does not need to have any specific jetspeed knowledge before using
a portal.
> > Portal site definition
> > ======================
> > A portal site is defined by the portal administrator who needs
> > to configure different files :
> >
> > - screen templates (which may use any template language supported
> > by Turbine) defining the different pages for the site.
> > Each template may access a jetspeed toolbox object which,
> > among other functionalities, will enable the administrator
> > to include configurable panes in the site templates.
>
> What is the toolbox object ?
>
Like Jon said
@see org.apache.turbine.services.pull
> > Example:
> >
> > index.vm:
> > <table width="100%" cellspacing="0" cellpadding="0">
> > <tr>
> > <td valign="top">
> > $jetspeed.Pane("home_main")
> > </td>
> > <td valign="top">
> > $jetspeed.Pane("general_tools").Customize(false)
> > $jetspeed.Pane("user_tools")
> > </td>
> > </tr>
> > </table>
> >
> > [Note: the example markup proposed above is just used for
> > descriptive purpose]
> >
> > When browsing this portal page, the named panes defintions
> > will be loaded from the current user configuration.
>
> Is "$" used for macro-ivocation ?
>
It's Webmacro/Velocity syntax.
> > - default portal configuration files
> > These files describe the various panes available for use within the
> > site as well as the portlets included in these panes.
> >
> > example:
> >
> > default.psml
> > <configuration>
> > <panes>
> > <pane name="home_main">
> > <!-- responsible for managing the L&F (skin) of this pane -->
> > <window-manager ref="MyYahooWM"/>
> > <!-- responsible for the layout of the pane contents -->
> > <layout-manager ref="MultiColumnManager">
> > <column-max>3</column-max>
> > </layout-manager>
> > <!--
> > <entry ref="rss_jetspeed">
> > <column>0</column>
> > </entry>
> > <entry ref="rss_turbine">
> > <column>0</column>
> > </entry>
> > <entry ref="rss_jakarta.apache.org">
> > <column>1</column>
> > </entry>
> > </pane>
> > <pane name="user_tools"/>
> > <pane name="hobbies_left"/>
> > <pane name="hobbies_right"/>
> > </panes>
> > <screenlets>
> > <screenlet name="rss_jakarta.apache.org">
> > <portlet ref="RSS"/>
> > <url>http://jakarta.apache.org/overview.rss</url>
> > <show-description>false</show-description>
> > <max-items>5</max-items>
> > </screenlet>
> > <screenlet name="..."/>
> > </screenlets>
> > </configuration>
>
> I think it is a good idea to separate the layout/L&F from the definition
> of individual portlet views.
>
> > [Note; this markup is just for description purpose and may be different
> > than the one actually implemented]
> >
> > [Note: The information stored within these files may actually be
> persusted
> > in a relational SQL database or LDAP directory for complex sites
> > requiring a high-performance, distributed backend. ]
>
> Yes, potentially, the database may contain a record for each registered
> portlet, portlet view, pane, ...
>
> I think we need a carefully designed interface for accessing this
> information
> which should be equally suited for persistence in databases as well as XML
> files. Below the interface, providers for database or XML-file persistence
> should be pluggable.
>
I agree but this I don't want to tie the XML persisted markup with the
persistence mechanism used. IMO, that's one of the issues with the current
PSML which is designed to be nice with Castor but not necessarily with the
end user.
If providing user-editable XML markup is one of the deliverable of the
project, we should first design a user friendly markup and a programmer
friendly Java API and then see if there's a tool for persisting the specified
API into the speciified markup. If we don't need a user-editable XML markup,
we might just as well drop this, always persist to the DB and write
an administrative application for managing the configuration.
> >
> > Items yet to be defined
> > =======================
> > * All the markup languages used for configuration need to be completely
> > specified
>
> I think we also have to specify a portal content model and an OO API to
> access it. Then we can define a default reperesentation of that model in
> an appropriate markup language.
>
That's a programmer approach ;) The API will probably never be accessed
outside of Jetspeed layout engine whereas the markup may be used by a lot
of end users for customizing their sites. Which one is the most important
in your opinion ?
> > * The jetspeed toolbox available whithin templates must be fully
> > described
>
> Can you give examples of the functionality you would envision in the
> toolbox ?
>
I already gave 2 within the documents:
- a pane accessor
- a link builder
There are probably other functionalities that should be accessible to the
portal administrator when designing his site.
> > * Should we allow the use of variables as entry parameters within pane
> > definitions ?
>
> Can you give examples ?
>
I had something like this in mind, but I'm not sure if it's useful (and there may
be security issues associated with this construct) :
default.psml
<onfiguration>
<screenlets>
<screenlet name="rss_jakarta.apache.org">
<portlet ref="RSS"/>
<url>http://jakarta.apache.org/overview.rss</url>
<show-description>false</show-description>
<max-items><value-of select="request::items" default="5"/></max-items>
</screenlet>
</screenlets>
</configuration>
> > * Are there any specific requirements for handling form submissions ?
>
> I think we need a generic mechanism transparent to portlet programmers that
> assures that form submissions are routed to the right destination (e.g.
> portlet)
> through the portlet container.
>
Yes, there's definitely something to be done at the portlet container level
for transparently handling form submission, but is there also something to
be done at the layout level ?
--
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]
