I thought this might be a nice place to bring hurry.resource to the
attention of more people.
resource handling libraries such as the YUI loader. hurry.resource is
server-based however. hurry.resource is designed to be web-framework
agnostic. I've recently released version 0.9 which includes a simple
WSGI middleware that can help to integrate this into your application or
What can you do with hurry.resource? We've wrapped a whole selection of
jquery (hurry.jquery), jquery-ui (hurry.jquery-ui), ExtJS (hurry.extjs),
TinyMC (hurry.tinymce) and more. There are all available on PyPI.
To use jquery for instance you could add ``hurry.jquery`` to your
project's setup.py. When installing your project hurry.jquery will then
be installed. This contains both the jquery library resources as well as
a description of them.
In your application you can then do:
from hurry.jquery import jquery
and then, when you generate a page that needs jquery support on it, you
say this somewhere in the Python code that gets executed during (or
before) page rendering:
What this will do is automatically include a <script> tag in your web
page that loads jquery.
A more interesting example is jqueryui:
from hurry.jqueryui import jqueryui
... jqueryui.need() ...
will now automatically include not only jqueryui but also jquery itself
(as this is a dependency). jquery and jqueryui are relatively simple
examples, but for YUI, hurry.yui is aware of YUI's complex internal
resources in pages when they're actually needed. Imagine a form widget
for instance that needs TinyMCE: only when that form widget is displayed
do you want to include TinyMCE on the page. Your code might not know
when the form widget is displayed at all, and therefore the right place
to express that you want TinyMCE is in the form widget itself.
hurry.resource lets you do that.
and it's easy to express this using hurry.resource:
hurry.resource also offers support for rolling up multiple resources
a page instead of in the <head> section for performance reasons.
To support hurry.resource for your application or framework you'd need
to do the following:
* have a way to publish the resources included with a
hurry.resource-based package to the web. Finding out what in a
package to publish is probably the most ungeneric feature of
hurry.resource now as it's in a configure.zcml file; I think it needs
to go into an setup.py entry point instead.
* instruct hurry.resource how to render the correct URLs to resources.
* instruct hurry.resource how to find the object that maintains the
needed resources (could be in the WSGI environ or be a thread-local).
* integrate the supplied middleware.
The steps where hurry.resource is instructed both use zope.component,
but I'm willing to change things so that this can be done using a simple
registration API instead.
I hope I've interested someone to look into this. Suggestions for
improvements are welcome.
Much more information can be found here:
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig