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

[Jim Fulton]

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:
> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/tool.py
> 
> 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
>>>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?

> 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.

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, 'dropdown_list')

Would something like this work for you?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org