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
higher level than even viewlets, let alone content providers. Both,
providers and viewlets, APIs have nothing to say about the
the view or other content providers/viewlets. This type of contract
purposefully deferred to higher level APIs. For example, in
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