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.

>>> - 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.
>>> Jim
>> 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"?
> Jim
yes, I re-read
http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html 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

Of course it is possible for a "pagelet" to render HTML directly and
consider the HTML produced as data (that's a question of semantic), but
then other rendering engines (text-based, SVG, RSS, ATOM, etc.) won't be
able to do anything with the HTML data that they get.

Anyway, pagelets or portlets whatever they called and no matter what
data they produce (structured data or raw HTML) must be "pipe-able"
through the rendering engine, i.e. they must return some data, the more
"ready HTML" the data is the less reusable it will be.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to