[Zope3-dev] Resource Library Proposal

[Gary Poster]

On Sep 16, 2005, at 6:15 PM, Garrett Smith wrote:

> On Friday, September 16, 2005 3:58 PM, Gary Poster wrote:
>
>
>> You could also be asking about the pipeline ideas, but that's not my
>> first guess. :-)
>>
>
> Yes, I suspect this is what I'm missing.

Maybe so.  Maybe you just disagree.  :-)

In a later email, you and Benji discuss how this might be used for  
dynamic JavaScript.  Benji made the point that that is not what we  
are talking about.  I agree with him, but I think I see your confusion.

We expect that the pipelining ideas will lead to a reasonable way to  
transform output.  We hope to leverage that for the resourcelibrary.   
You could certainly leverage the method yourself, for your own  
means.  The resourcelibrary use case is one of the simple stories  
that is pushing pipelining--a much larger and more exciting  
development, I think--along right now.

To explore your use case further, though, I'm not sure why you would  
need something like resourcelibrary for dynamically generated  
insertions--that is, JavaScript code that the server writes  
differently for each request.  You can just include that inline.  The  
resourcelibrary makes sure that you only include a single instance of  
the necessary libraries, makes sure that CSS is at the top, as it has  
to be, and so on.  These combined requirements led us to the current  
approach.

> There was an earlier post about Ajax. It seems an entirely new  
> approach would be needed to solidly support Ajax. I.e. we would  
> need an architecture that let components interact independently of  
> the browser view, or at least could be accessed in isolation of a  
> full page rendering. Is this the sort of thing the 'pipeline'  
> approach is getting at?

No.  Pipelining is about taking what the Zope publisher spits out,  
and then transforming it before returning it to the user.  For  
instance, views might spit out an XHTML snippet, and pipelines would  
wrap it.  Or views might spit out XML of data only, and pipelines  
would make transform it into a UI.  Or views might spit out non- 
string objects, which would be transformed.  And so on.

I don't think Ajax needs an entirely new approach--at least what I  
would mean by "an entirely new approach". :-)  I'm working out some  
proposals for that in the new widget code that was started in the  
sprint.  I'll hope to talk about that soonish (though I have a number  
of other projects I have to wrap up before I get to that :-/ ).

The use of ajax libraries will benefit from something like  
resourcelibrary.  Other than that the two are not that related.

To get back to your concerns about the resourcelibrary (and  
conclude), it is currently a drop-in component (from which you can  
easily opt out) and the pipeline plans should make that even more the  
case.  You'll just be opting out of any shared rich widgets and  
shared composite page projects that use it.  Since you've forked the  
widget code, it sounds like that sort of thing might not phase you. :-)

Gary