[Grok-dev] [hurry.resource] not including hurry.zoperesource in hurry.yui's configure.zcml
faassen at startifact.com
Wed May 27 10:26:13 EDT 2009
Jan-Wijbrand Kolman wrote:
> I'm playing with an alternative way of injecting the HTML snippets that
> hurry.resource generates into rendered views.
> hurry.zoperesource injects these snippets by registering an alternate
> Response class used when publising objects. I'd like to see if I can get
> rid of this requirement, and have the snippets rendered by a content
> provider instead.
I think you'll have an ordering issue; the content provider will be
loaded before all '.need()' statements have been executed.
What I think would be nice is a WSGI middleware that did this.
> Still, I do want to be able to use hurry.yui.
That's why I separated hurry.zopeyui from hurry.yui. :)
> By way of z3c.autoinclude, hurry.yui will be configured for me when I
> list it in my project's install_requires. However, since hurry.yui's
> configure.zcml will in turn include the configure.zcml of
> hurry.zopresource I will implicitely be using hurry.zoperesource's way
> of injecting HTML snippets.
I used to have them separate (and a very small hurry.zopeyui indeed) but
asked Uli to merge the configure.zcml into the hurry.yui package as I
didn't think it would do any harm.
> Since hurry.yui states in it README.txt that in order to use it in a
> Zope/Grok context, your project should depend in hurry.zoperesource
> anyway (and thus will be picked up by z3c.autoinclude!) I think the
> inclusion of hurry.zoperesource in hurry.yui's configure.zcml can go away.
Agreed. The configure.zcml should just make the directory resource
available and not do the include.
> This would then make it easier to reuse hurry.yui in a Zope/Grok context
> without the implication of using hurry.zoperesource.
More information about the Grok-dev