I'll note that I think this overlaps with Roger's pagelet system.
Dealing with resources needed by multiple page components seemed to
be a major motivation for pagelets.


Gary Poster wrote:
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.


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.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com

Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to