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

[Jim Fulton]

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.

Jim


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.
> 
> 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.
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
> 


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org