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 directive?

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

OK, cool.

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

Reply via email to