On Oct 15, 2005, at 8:24 AM, Stephan Richter wrote:
What are we looking for?
- Comments on the Python API.
- Comments on the ZCML API.
- Comments on the ZPT API.
- Use cases that you might think are not covered by the design and
- Whatever you like to say about it...
Hi Stephan (and Roger :-).
I have read the contentprovider README and skimmed the viewlet README
viewlets look like a clever pattern. I can see that they can be
applied to many use cases; I'll have to think about them to see how
much I like the application compared to others we have used, but I
have a generally favorable impression so far.
contentproviders are a subset of the viewlet pattern, obviously. But
when do you think one might build contentproviders and not viewlets?
Do you have concrete use cases (or even current uses) for this division?
The most important part of my reply, though, is that I hope we can
agree to share an even lower-level interface than contentproviders.
If we do, it will address my remaining concerns (expressed below).
I have been working on a subview package off in another branch. It
addresses a class of bugs caused by subviews that affect non-
contained subviews; sets the stage for AJAX components and for
independently-configurable drag and drop between subviews; and wants
to contemplate subview persistence as an optional addition.
Of these, my biggest concern is the first. When building our portlet
system, we discovered a class of rendering bugs that occur when a
change to a subview affects other subviews (usually non-nested): the
underlying data changes as expected but it is not drawn to screen
because the data change was out of order for the rendering. The two
stage approach, calculating all state and then rendering all, is the
solution we came up with for mitigating what we called 'update
bugs'. We have significant experience with the two stage approach,
and it is our best answer so far. You do not do this, or have
another solution I can see that addresses the same problems. We
would want this.
I also really wish we could agree on a subview-addressing story (for
AJAX) and a drag-and-drop story. We have experience with our drag
and drop story, and are proposing a new AJAX story for subviews. The
subview package only sets up some small foundations so that these can
The persistence use cases are real and important, and I'd like to
agree on them, but
- we're still having internal discussions about the right way to do it,
- it's intended to be an optional part of the subview capabilities, and
- it doesn't appear to be pertinent to the viewlet or contentprovider
The rough README is here: http://svn.zope.org/Zope3/branches/
f12gsprint-widget/src/zope/subview/README.txt?view=auto . The whole
package is rough; I had to put work on this aside, but it it is
currently slated to be my next project, since we need some of the
If we could agree on everything but the persistent bits for the 3.2
inclusion then I'd be thrilled. That will mean a number of things
have to align though, including our perspectives. :-)
Zope3-dev mailing list