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

[Jean-Marc Orliaguet]

Jim Fulton wrote:

> Jean-Marc Orliaguet wrote:
> ...
>
>> 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.
>
>
> There are advantages in storing data on the object, if you can do it
> in a controlled way.  I understand and agree that you don't want the
> implementation of portlets to know about (depend on) styles.  Zope 3
> provides a mechanism, annotations, for storing data on an object
> without affecting the object's implementation.
>

here is the use case:

- the style of portlets located in slots is associated to the slot (not
to the portlets). Why? because content creators focus on content not on
CSS styles, when they add a portlet into a slot someone else has already
designed the style for the portlet.

- the same goes with widgets (the actual presentation of portlets)

here is an animation that demonstrates the idea:
http://www.z3lab.org/sections/front-page/design-features/slot-formats

- the default behaviour for portlets is to inherit formats (styles,
widgets, etc) from the slots.

- it means that slots (not portlets) should in principle store the
format information.

- but if you do this (store the style information on slots), there is no
way to override slot styles in some given context or perspective only.
Maybe you want your end-users to be able to customize the color of the
boxes? If you store the information in the slot, there is no way to
display portlet boxes in a slightly different way (e.g. add min/max
buttons on boxes)

- so basically if you store some style information on some given content
class (portlet, slot, ...) you will already have shot yourself in the
foot, after the third use case only:-)

This is why cpsskins uses the notion of "display", which is an object
that stores all format information (style, widget presentation,
visibility, ...) Different displays can be associated to a same slot or
a same portlet.

>> 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?
>
>
> Why would it be indexed?  Why would I advocate one centralized storage
> scheme over another?  I don't like centralized data structures.  They are
> necessary sometimes.


do you mean that all information is stored on objects and that you don't
index the information in any catalog to get access to it fast? how many
pages per second can you render?

>
>> 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).
>
>
> I don't really understand what you are objecting to.  Requests are
> necessary for user interaction. Why should anything but presentation
> code have access to the request?  We obtain presentation code
> by adapting the request.  Why would you want the request elsewhere?
> How is this schizophrenic?


This could be the subject of another thread, but basically I end up in
some cases having to pass the request object to methods (as in Zope2)
because the code is neither 100% presentation nor pure content. Maybe
I'm doing things in the wrong way ... I need to implement a Read / Write
containers (slots) that since that are Containers know nothing about
requests, but also need to get some information stored in the request to
decide how to store the information. ..


>> 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.
>
>
> Agreed. I'm slowly getting an inkling of what your architecture is and is
> trying to achiev.  As I learn more, I'm liking many aspects.
>
>>>> 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,
>
>
> We don't have anything that does exactly what your system does
> (assuming that I know what your system does ;).  But we've faced
> similar sorts of design decisions.


I'm really interesting in learning about your use cases, because it
could be that you have use cases that are very different. Rob 
mentionned that it was important to save historical information on all
content changed in the sites for some legal reasons, for instance. This
is not a use case that we have I think.

>
> > but I guess that you will store all the
>
>> information in the portal catalog? what is the difference?
>
>
> I wasn't suggesting storing anything in the catalog.  I was suggesting
> storing data on the objects.


OK, that's an implementation issue.

>>> - 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.
>
>
> These are two audiences. Are these number one and number two?
>
> I suggest you have a number of audiences:
>
> - site designers
>
> - application developers
>
> - content managers (who you call end users).


yes all of them, what I meant was that cpsskins is targeted for
productivity, to be easy to understand and to have a coherent UI, which
might not necessarily mean that the system is easy to understand by
developers who are used to thinking about an application in terms of a
series of web pages. The paradigms used are closer to those used in
desktop applications (MVC, ...)

I think that desktop application developers would not be surprised by
the design.

>
>> The Zope2 version is already appealing to both users and developers.
>
>
> Cool. I'm a developer and after all this discussion, I have only a loose
> grasp on what you are trying to do.  I think you've indicated that the
> system you're describing me has evolved from the Zope 3 version.
>
> > 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.
>
>
> Great.  BTW I'm still unclear whether you are still trying to satisfy the
> use case of allowing portlet assignments by folder with aggregation along
> a folder path.  I thought you said yes, but it sounded that was not done
> when you supported perspectives.  Do you support by-folder and
> by-perspective
> portlet assignment at the same time?  How have you addressed the
> confusion
> that arises when a user adds a portlet to a page in a folder and it
> appears
> on subfolder pages as well?


both are going to be supported. I think that it is the use case that
determines what works best in a given situation.

let me give you an example: your users are working on a news portal, and
they change the portlets located on the front page of the site. If they
do it using the by-folder method they will have to do it "live" and the
changes will be seen directly (even their mistakes). If they do it using
the by-perspective way, they can work on the "front-page" perspective,
maybe even collaborate on the portlets that will be shown, and update
the perspective to change all the portlets at once, and not do any
mistake. This is the way the polopoly news sites (www.svt.se) work, when
a set of portlets (perspective) is ready it replaces the old one.

The by-folder approach works better when the portlets on a page are not
tied to a given section of the site at all. In CPSPortlets there is a
"site structure" to better see where the portlets are actually located:

see http://www.medic.chalmers.se/~jmo/z3lab/z3lab-site-structure.png

>> 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.
>
>
> OK, that's what I thought. The use of the term "portlet" here is a bit
> confusing here, I don't think most people would expect portlets to be
> used this way.
>

I don't know actually, the "pagelet" definition in
http://www.urbancode.com/products/pagelets/index.jsp is what "portlets"
are in cpsskins. I think that it is worth thinking about portlets from
that perspective, because the other layers (widget, layout, style) are
already treated separately.
 

> ...
>
>>>> 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.
>
>
> As I mentioned before, I'm unclear how appropriate layouts for portlets
> are determined.


layouts are used not only with portlets but with all displayable
elements (page, page blocks, cell, portlets).
it is not just the portlet's layout that we are speaking about, but the
"layout" filter that add some layout markup to some displayable element
(margin, padding, alignment). The portlet when rendered through the HTML
default rendering engine goes through a layout filter.

here is the code that adds the widgets:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/browser/renderers/filters/widget.py

here is the actual code that adds some layout to elements:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/browser/renderers/filters/layout.py

here is the code that adds the styles:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/browser/renderers/filters/style.py

>
> ...
>
>> 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, ...)
>
>
> And we disagree here. Given what you said, I agree that portlet
> implementations should not be responsible for storing styles.
> I do think annotations would provide a good alternative to a centralized
> store (such as a relationhip system or a catalog).
>
> This discussion is getting pretty tedious over email.  I'd like to
> learn more
> about what you're trying to accomplish and about some of the reasons
> you've
> made the decisions you've made.  I look forward to discussing some of
> these
> ideas in person some time.
>
> Jim
>

Yes. I think that it would be easier to discuss all these things in real
life with some demo. The trickiest issues are related to the user
interface and what users expect from the application, not so much the
technology underneath. I'm mostly concerned about the overall design and
not so much whether it works better using a giving implementation or
another - if it works with relations, then it works with relation....
This is nothing compared to all the UI problems that are required to be
treated for the application to work.

/JM