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 
component that dynamically builds JavaScript and includes it directly in the 

 -- Garrett


> 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:
>>     <head>
>>         <tal:block repeat="content view/headContent">
>>             <tal:block content="structure content" />        
>>         </tal:block> ...
>>     </head>
> The proposed solution also does not require any dead chickens in ZPT.

Zope3-dev mailing list

Reply via email to