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
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/
WARNING: zope.org exhibiting some serious caching strangeness, so
please comment on the list instead of the wiki.
Zope3-dev mailing list
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