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

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

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

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

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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to