Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
>> this is more a design feature than an implementation feature.
> Could you explain *why* you need relations?
yes, because adapters provide flexible relations between *components*
(interfaces, classes), but not between *content* objects. I want to be
able to say (or the user)
- this portlet uses this widget
- this portlet uses this style
not for a *class* of portlets, but for *instances* of classes. Adapters
connect interfaces, not instances.
to sum up: for exactly the same reason as why Zope2 moved to a
component-based architecture, but for the content this time. I want to
be able to connect content objects (portlets, styles, widgets, layouts)
in a flexible way.
and by the way it works, so why explain why you need something when it
works as expected?
>>>> 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
>>> 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?
the portlet data is used for syndication in RSS / ATOM too in a RSS
rendering engine (the [RSS] orange button).
if the portlet already renders HTML, there is no way to convert HTML to RSS.
>> 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.
this is just one example of a rendering engine (the HTML rendering engine)
> 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.
the widget knows nothing about the style that is going to be applied
afterwards. The portlet <-> style connection is a relation defined in
the relation store.
> Can you say why you chose this division of labor?
it is one example of a chain of filters that covers most of the use
cases to create HTML pages.
Since the engine definition is defined in a zcml file it can be changed
easily. I could go into the details of the design, but since it works as
> 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
> 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,
> 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.
what is a layout type?
> - 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?
I don't think so, because the relation portlet <-> widget <-> layout
gets hardcoded in python. I would mean that I would have to rewrite the
AJAX theme editor.
the difference with the rendering architecture that I have implemented
is that new rendering engines can be created by reusing components.
I think that your approach is not generic enough, it is too much tied
with the webpage generation paradigm (it assumes that a portlet has a
layout, or a style...) which are web-related concepts.
Zope3-dev mailing list