Ian Bicking: the old part of his blog

Lxml transformations comment 000

This approach looks very interesting, I like it. I gather that this could be implemented in a layer of middleware who's sole responsability would be to handle static resource's dependencies, insert their links at <head> and, possibly, serving them too, right?

Yes, that's possible. I would be reluctant to put too much in middleware, but this particular case requires very little context. Combining a server with find_library_url would also make sense. Or you could have a configured system that copies resources into a different location, e.g., where they are served by Apache or some faster server, and then make find_library_url know about that. That there's multiple useful implementations is part of what makes me like the design.

It think would be useful to agree in a protocol to pass the element stream through the stack so it plays nice with other XML transforming middleware so the markup only needs to be parsed and serialized once, with any number of transformations in between (Deliverance, etc...) I remember some discussion along this lines in TG's trunk ML some time ago.

I have been exploring this some in HTTPEncode, but it's been somewhat difficult. But there's been some progress since then (not a lot, but some) -- after some thought I wrote up a strategy for it using WSGI, but no one on the Web-SIG list seemed very interested; I'll probably just move the implementation back into HTTPEncode when I have time.

ToscaWidgets could piggy back on this to handle its static resources needs. Which brings up the idea that some sort of central registry to map js-require (and css-require) attribute values to files in the filesystem so any library used by a downstream app could regsiter their resources so they can be served and their urls generated.

Clearly the nature of that naming becomes pretty important; you want to avoid clashes, but seek out correct overlap. I'm more inclined to use something like OpenJSAN, as it represents a kind of central repository with unique names. Another option is to use some kind of URL/URI, which generally speaking is probably better.

It often annoys me that entry points can't be applied to non-Python objects, like a directory or resource in the package. It might be nice to use a URI, but actually tell the system that the content is provided locally. Then you get better chance of overlap (if two packages require MochiKit, for instance), but you don't make the installation process more complicated (by actually requiring the install to fetch the libraries, for instance).

If going down this track, it would be nice to provide some setuptools extensions for it. E.g., python setup.py refresh_javascript, which would read [refresh_javascript] in setup.cfg and update the package, and maybe (not sure) put another file in .egg-info.

Comment on Re: lxml Transformations
by Ian Bicking