[Zope3-dev] Resource Library Proposal

Fri Sep 16 13:28:00 EDT 2005

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