On Oct 15, 2005, at 9:52 PM, Roger Ineichen wrote:
The content provider package offers just the API for collecting
additional content. This pattern can be used directly in python
or in page templates.
There is no reason that we have to use a viewlet implementation for
this. The content provider package offers also a TALES directive
called "providers". This is only the way can use content provider
directly in TAL.
Since a viewlet depends only on the page template implementation,
there is no reason to merge this two packages together. The viewlet
package provides only a standard implementation where we use in
relation to the page template concept.
Since I use another template language (expermimental), I see no
need for the viewlet package. This was my main reason for spliting
the content provider and viewlet part in two packages.
Let's say the content provider package offers the concept and the
viewlet package offers a implementation which depends on page
OK, that makes sense. The contentprovider package offers up two
bits, then: the pattern of looking up by (context, request, view),
and the TALES directive. It sounds like your division of
contentprovider and viewlet was directly to support your use of
another template language--which is not going to need the TALES
But that sounds fine.
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 will take a look at your Readme next week ...
Zope3-dev mailing list