[Grok-dev] [hurry.resource] not including hurry.zoperesource in hurry.yui's configure.zcml

[Martijn Faassen]

Hey,

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.
> 
> Thoughts?

+1

Regards,

Martijn