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

[Jim Fulton]

Jean-Marc Orliaguet wrote:
> 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

I'm confused. In the doctest you pointed out:

https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt

the portlet and widget are wired up by hand, not by lookup AFAICT.

> - this portlet uses this style
> 
> not for a *class* of portlets, but for *instances* of classes. Adapters
> connect interfaces, not instances.

Then why not just store the style in the portlet?


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

Because to decide if I want to use it, I need to evaluate the architecture:

- I need to know if there are hidden costs that aren't apparent in
   demos and small scale.

   Your solution requires a potentially large centralized indexing structure.
   I don't like large centralized indexing structures.  They are necessary
   sometimes, but I don't want to use them if I can avoid it.

- Your system defines a framework that I'll need to understand if
   we want to use it.  I need to understand if developers will find it
   easy to use


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

Is this a case where you are using a portlet as an application
component outside the context of a page?


...

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

The thing you specify with the widget keyword argument to the Widget
contructor in the doctest you sent.

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

In the example you asked me to look at, the portlet<->widget relation
seemed to be hardcoded in Python.

In any case, adapter definitions are not 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.

I see your point about not wanting to store a web style with a portlet
instance.  I need to think about this.

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