[Zope3-dev] Resource Library Proposal

Fri Sep 16 16:15:00 EDT 2005

I don't understand what you just said :-)

My fault -- I haven't been plugged into the other discussion.

Is there a branch somewhere that has a simple demo to help with grokability?

 -- Garrett

On Friday, September 16, 2005 12:28 PM, Gary Poster wrote:

> On Sep 16, 2005, at 12:49 PM, Garrett Smith wrote:
> 
>> Sorry for the long delay in replying.
>> 
>> We've been using widget-specific JS and CSS for some time now and I
>> like our approach. It's quite different from the proposal.
>> 
>> We're using the same pattern used by forms/widgets -- i.e. the PT
>> is responsible for explicitly including HTML fragments provided by
>> the view. As a point of reference, here's a simple example of
>> including widgets: 
>> 
>> <tal:block repeat="widget view/widgets">
>>   <label tal:content="widget/label">Name</label>
>>   <input type="text" tal:replace="widget" />
>> </tal:block>
>> 
>> The analog for including header support (i.e. JS and CSS) is:
>> 
>> <head>
>>   <tal:block repeat="content view/headContent">
>>     <tal:block content="content" />
>>   </tal:block>
>> </head>
>> 
>> This places the burden of managing unique lists of 'head content'
>> with the view. I see this as an extension of the widget-management
>> framework. 
>> 
>> I would not personally opt for the proposal because it feels a bit
>> magical -- I think it's too indirect.
>> 
>> So, here's my argument in brief: Since widgets are driving the
>> requirements of a consolidated "resource" list in the HTML head,
>> the solution should extend the existing widget pattern. Yes, this
>> imposes more overhead on the PT and the view, but the upside (IMO)
>> is that the scheme is more transparent.
> 
> If we had a clear division between update and render stages, and all
> template elements had an update call before they were rendered (and
> so were able to register a need) then the approach you suggest would
> be generally sufficient for the kind of story we are interested in
> telling.  Pipelining, possibly combined with a modified templating
> story, can address this in a different way--one of the simplest
> configurations would support something like separate update and
> render stages.  Even there, though, the resourcelibrary API for
> clients could remain the same, whether the JS/CSS were inserted by a
> main template that rendered the gathered JS/CSS calls, in a modified
> version of your approach; or by the XML-munging (or "transformation"
> to put it in a more politically appealing light) that is the current
> implementation. 
> 
> I'd say that this proposal has two thrusts.
> 
> First, it proposes that we need a solution to the problem of stand-
> alone display components that need support from the main page.
> That's something that we (ZC) want, and for which other replies to
> the thread have also expressed desire.  It enables a drop-in rich-
> widget story, which is arguably becoming more important as user
> expectations for richer internet experiences rise, and developer
> expectations for simpler integration of rich client technology rise.
> 
> Second, it proposes that the given API can support a number of
> rendering implementations, from transforming HTML (as in the current
> implementation) to being a part of a wrapper main template during a
> rendering stage of a pipeline.
> 
> The proposal should be evaluated from that perspective, and from the
> perspective of Jim's recent pipeline discussion.  Can you see the
> need?  Can you see how the API can support several rendering
> implementations?  Developers who say yes to both can develop and use
> drop-in rich sub-page components, such as widgets.
> 
> Developers who say yes to the first but no to the second are
> urged to
> suggest improvements.
> 
> And thanks to the wonder of the more plug-and-play architecture of
> Zope 3, developers who say no to the first question don't have to
> play here, while still joining up elsewhere. :-)
> 
> Gary