[Zope3-dev] [DRAFT] local portlets and perspectives

[Jean-Marc Orliaguet]

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
>>>> engine.
>>>
>>>
>>>
>>> I'd like to understand how this works.
>>>
>>> Jim
>>
>>
>>
>>
>> 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:
>> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png
>>
>>
>> and documented here:
>> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt
>>
>
>
> So
>
> - 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
expected ...

> 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.
>
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,
> 'dropdown_list')
>
> Would something like this work for you?
>
> Jim
>

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.

/JM