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:

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

Would something like this work for you?


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

Reply via email to