[Zope3-dev] Resource Library Proposal

Garrett Smith garrett at mojave-corp.com
Fri Sep 16 18:09:00 EDT 2005


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

 -- Garrett


On , zope3-dev-bounces+garrett=mojave-corp.com at zope.org 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:
>> 
>>     <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.




More information about the Zope3-dev mailing list