On Oct 17, 2005, at 11:59 AM, Stephan Richter wrote:

On Saturday 15 October 2005 15:48, Gary Poster wrote:

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.

Note that I think that AJAX, drag-and-drop and all of this stuff is much, much higher level than even viewlets, let alone content providers. Both, content providers and viewlets, APIs have nothing to say about the interaction with the view or other content providers/viewlets. This type of contract was purposefully deferred to higher level APIs. For example, in SchoolTool we
have no need for those type of things.

Right, which is why the contract in subview is all about the parts of the decisions necessary for interoperability, rather than actual AJAX or drag and drop implementation. SchoolTool and other similar projects should have to do nothing or virtually nothing to "get along". The subview package includes no JS, for instance; some might live in zope.app.subview as an example of one way to use the agreements.

You also include "all of this stuff": not sure what you are including there. If you mean prefixes and a two-stage update/render pattern, I flat out disagree with you. From another reply, I don't think you do.

If you mean a persistence mechanism, then this is an opt-out part of the pattern that nonetheless is important to define at a low level: if a subview is not persistent or otherwise stateful then it dirties any containing subviews so that it is no longer persistent, even if the container thinks it is.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to