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

[Jean-Marc Orliaguet]

Jim Fulton wrote:

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

sorry this is a doctest that does not take into account relations. It
only describes the way in which elements are rendered, i.e. moving from
content -> view, from data to HTML.

>> - 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?
>
Again you are making the assumption that a portlet *has* a style. If the
portlet is rendered in RSS it has no style ...

Also this is as bad as storing browser view related attributes in a
content class - otherwise we are back to the Zope2 old days, where every
possible attribute was stored on the objects themselves.

Then OK: if you store the style attribute on the portlet itself, I
suppose that this information will be indexed and cataloged. In what way
is it different from having a separate relation store that does not
duplicate information?

Honestly, Zope3 makes some sort of schizofrenic separation between
content and view, in a way that you sometimes cannot get access to the
request object because you haven't adapted (context, request).

the Zope3 philosophy has to be coherent: if you create a waterproof
separation between components, then having a waterproof separation
between content elements, i.e. portlets / widgets / styles / layout /
visibility options / caching parameters is just as important.

>
>> 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.
>
I don't know about yours, but I guess that you will store all the
information in the portal catalog? what is the difference?


> - 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
>
the number one target audience is end-users, and application developers.
The Zope2 version is already appealing to both users and developers. At
the university we can't afford to create a product that only developers
understand. Content creators, graphic designers don't think as
developers, they see things differently and this is what I'm trying to
integrate into cpsskins, i.e. *their* knowledge.


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

yes, of course, content is often syndicated. Creating a syndication
adapter that gathers data, extract data and renders it in RSS when you
only need to create a filter and add /++engine++rss/ in the url is worth
a lot.

>>>
>>> - 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.
>
OK, this is not really important, this is only used by the vocabulary
items to not propose a "box layout" to a user when it makes no sense to
apply a "box layout" to an element. This is just a way of categorizing
widgets / layouts.

>>> - 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.
>
yes indeed, the doctest does not use relations, so the link is hardcoded
to avoid having to set up the relation stores.

generally speaking I have nothing against adapters, in the rendering
engine I use:

- adapters
- interfaces
- relations
- containment

... where it makes sense.

I have no particular preference for any given relation store, so maybe
you should consider the one implemented as a lightweight store that
requires no extra software installation, and that is optimized for
speed, but that can be replaced with an RDF, SQL, store or portal
catalog, maybe?. (at the expense of getting worse performance), I don't
like the idea of having to query portal catalog in the Zope2 version of
CPSPortlets for instance. The only mistake that I don't want to do this
time is storing relation information in the objects themselves
(annotations, attributes, ...)

/JM