Raphael Luta wrote:
> 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 API for the content model is very important, because it represents
a clean interface between the data model on one side and layout engines
and customizers and potentially other portal components that will want
to access the content model programmatically. It should allow to implement
different customizers (e.g. drag&drop, Yahoo!-like, ...) using the content
model API, e.g. like this:
+-------------+ +------------------+
| Customizers | | Layout Engine(s) | ...
+-------------+-+------------------+----------+
| Content Model API |
+----------------------+----------------------+
| XML Pers. Provider | DB Pers. Provider |
+----------------------+----------------------+
The XML markup is important and must be easy to use. Administrators should
be able to define layout patterns using XML markup, and these patterns need
to be accessible through the content model API.
There may be different kinds of customizers that create instances of the
layout patterns and allow to add/remove portlets, flip columns, etc.
> 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.
Yes, that's true.
> 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.
That's a good approach.
> 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.
I think even if a portal uses a database for persistence, the XML markup
is useful as a medium to import layout patterns into the database.
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
Raphael Luta wrote:
> [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]
