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

[Jim Fulton]

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

You clarified this later in the earlier message. I should have moddified
my question a bit.

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

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

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

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

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

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

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

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

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.

...

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

...

> 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

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