[Zope3-dev] RFC: Content Providers and Viewlets

[Gary Poster]

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

Gary