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?

- Use of the term "portlet" here leads to confusion with JSR 168
portlets, which are different.   I would prefer to see a different
term used for what CPS calls portlets. Absent that, we'll need to
find some modifiers to disambiguate.


yes, any term, "boxes" are not OK, since they refer to the portlet's
display (view) with the frame and the decorations but any term that is
understood by users / developers is ok.

Cool. "Pagelets"?


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.

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

Reply via email to