Drop-in rich (JS/CSS-dependent) view components: Please review (was Re: [Zope3-dev] Resource Library Proposal)

[Gary Poster]

Benji posted this last week and we don't have any feedback yet.  We  
would really like some, even if it is to ask us to clarify what the  
heck it is about.  Some of our other code that we want to contribute  
depends on this.

The use case for this tool is to allow rich view components, such as  
form widgets (but there are many other examples), that rely on JS and  
CSS to work in a more componentized, drop-in way.

It is centered on the idea of reusable client-side libraries--such as  
pdlib, the mishoo calendar, prototype, ricoh, mochikit, epoz, kupu,  
fckeditor etc.--that many view components may want to use, without  
knowledge of the other view components, but coordinated with them.

For instance, imagine you have a widget that wants to use the mishoo  
calendar JS library.  That involves JS and CSS, and CSS is only legal  
in the head (some browsers allow it elsewhere, yes).  You want to  
package up your widget as a drop-in component for use in applications.

Without the tool, you have to tell client developers to explicitly  
include the JS and CSS on the head of the main form template: not  
exactly drop-in, especially if the widget is sometimes drawn and  
sometimes not.  With the tool, when/if the widget is rendered, it  
simply requests that the necessary necessary JS and CSS be included  
in the head.

Further, imagine that you have another widget that needs the same  
library.  Sometimes, they might be drawn on the same page.  This tool  
makes sure you only get the library once (I believe browsers handle  
this for efficiency, actually, but still this is reasonable).

Further, imagine that you need a library that relies on another  
library (Ricoh on Prototype, for instance).  One view component needs  
Ricoh, and another needs Prototype.  This is also handled nicely.

The current implementation uses a custom request/response pair to do  
the HEAD rewriting; this is arguably a bit hacky, and we will  
probably explore WSGI pipelines once they are available.  This should  
be largely transparent to developers relying on it.

Later plans for this include optionally compressing JS and CSS.

We think this will allow for a much nicer rich sub-view (i.e., rich  
widget, among others) story.  We're eager to get some feedback,  
including ideas for improvements.

Gary


On Aug 31, 2005, at 3:55 PM, Benji York wrote:

> I've added a proposal for Zope 3.2.  Read at http://www.zope.org/ 
> Wikis/DevSite/Projects/ComponentArchitecture/ResourceLibrary.
>
> WARNING: zope.org exhibiting some serious caching strangeness, so  
> please comment on the list instead of the wiki.