My point is that if rich widgets are the *only* driver here, the solution below
is a better fit with the existing widgets implementation.
The transformation of the HEAD doesn't jive with existing patterns. If there's
a new pattern afoot (pipelining?), I hope we get a chance to discuss it. If
I've just missed the discussion (quite possible), I'll wait for the RC.
FWIW, we would not be able to use this new scheme exclusively as some of our
IHeadContent providers provide more than file includes. E.g. we have a menu
On , [EMAIL PROTECTED] wrote:
> Garrett Smith wrote:
>> That's right. But the view can solve these problems easily without a
>> lot of other stuff like yet-another-ZCML directive and automagical
>> transformation of the HTML head element.
>> This is what we have:
>> class IHeadContent(Interface):
>> """Something that provides head content for a page."""
>> def headContent():
>> """Returns a sequence of HTML snippets to be added to the
>> page head."""
>> class SomeView(BrowserView):
>> def __init__(self, context, request):
>> self.headContent = 
>> for widget in self.widgets():
> Like I said before, they're not always widgets. For
> something like this
> to work you have to be able to enumerate all the page components no
> matter what type of thing they were. That's not always convenient or
> even possible and seems more constraining than the proposal.
>> The applicable PT:
>> <tal:block repeat="content view/headContent">
>> <tal:block content="structure content" />
>> </tal:block> ...
> The proposed solution also does not require any dead chickens in ZPT.
Zope3-dev mailing list