Jean-Marc Orliaguet wrote:
Jim Fulton wrote:

Jean-Marc Orliaguet wrote:

Jim Fulton wrote:

Jean-Marc Orliaguet wrote:

basically if the "slot" that you're thinking about contains portlets
then it's a sort of slot not a sort of portlet.

Cool. So we can define new slot-like things (for example,
for JSR 168-style slots) and use your slots or not, as we wish.

In particular, we can use CPS skins without being forced to
install triad registries unless we want to use your slots.

In that case it is possible to plug in other relation store backends
(e.g RDF) that do not support genuine triadic predicates, which means
that only "local folder" types of slots will be available, but some
relation storage is required for the dyadic relations between elements
and styles, widgets... because the relations between the elements are
not stored on the elements themselves.

Sigh.  Is this documented anywhere?

Currently the application adds relations into the relation store using a
relation tool, there is not definite documented interface though, since
not all the use cases are defined yet:

The idea is to allow any relation store back-end (RDF, SQL, ..) to be
plugged in.

If the relation information was stored in the elements themselves (e.g.
annotations, attributes, ...) this would make it very difficult to move
the storage from the ZODB.

this is more a design feature than an implementation feature.

Could you explain *why* you need relations?

yes, I re-read and
while going through the different definitions I saw that not two
implementations are done in the same way, which is fine.

The important aspect is that "portlets" or  "pagelets" as they are
implemented in cpsskins separate model and view.
They implement the "data model" part only,  not the view itself, which
is done later by widget, layout and style filters inside the rendering

I'd like to understand how this works.


A portlet / pagelet generates some data (a list of menu items, for
instance) as a data structure in python.

- the data goes through a widget filter that convert the data into HTML.
Depending on what widget is being used, the same data is displayed
differently (vertical list, horizontal list, drop-down list...).

- a style filters add the style information (class="..."),

the portlet can then be displayed in HTML

if other combinations of filters are used (a RSS filter for instance),
the same data is displayed in RSS instead of HTML.

Why would you want to generate RSS in a portlet?

which is shown on the following diagram:

and documented here:


- You get a widget of a particular type.

- You adapt the widget (with a request) to get a widget filter.

- You call the portlet to get some data.

- You call the widget filter with the data to get HTML markup.

I guess the widget filter somehow decides how to generate HTML based
on the widget and data. Similarly, it somehow chooses a style.
It's unclear how this is working.

Can you say why you chose this division of labor?

I agree that, given a model where portlets only generate data, "pagelett"
is not a good name. Perhaps "applet" would be a better name.

IMO, the choice of the term "widget" is unfortunate, both because it clashes
with the Zope 3 use of the term and because it clashes with common usage in
GUIS, where widgets are responsible for UI generation, whereas here, AFAICT,
widgets are responsible for UI specification in some fashion.

Here's an alternate suggestion that follows Zope 3 style a bit more:

- We have applets that provide application functionality.  These are
  like your portlets.

- We define layout types.  These extend something like ISubPage (as defined in
  formlib).  Alternatively, we use named adapters.

- We adapt the applets with the request to the layout type:

     view = component.queryMultiAdapter((applet, request), IDropDownList)

  or, with named adapters:

     view = component.queryMultiAdapter((applet, request), ISubPage, 

Would something like this work for you?


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to