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

- 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
 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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to