[Grok-dev] grokproject + hurry.resource wsgi resource injection

[Jan-Wijbrand Kolman]

On 11/15/10 15:17 , Souheil CHELFOUH wrote:
>> 1) Now that hurry.resource (in the newer versions) use entry points for
>> defnining resource libraries *and* hurry.zoperesource uses these entry
>> points for registering the DirectoryResource components, we might "lose"
>> some of the ZCA-flexibility. For example, I do not see a way to override
>> a DirectoryResource registration based on layer or ISite.
>
> To resolve that problem, i now use Resources Viewlets, that can "need"
> the resources you want according to 3 discriminants : the context, the
> request (therefore the skin) and the view, (and also the
> viewletmanager, but that's an implementation detail).

Hmm, I didn't explain myself well enough I think.

What I mean is: hurry.zoperesource will itself register 
DirectoryResource components. It will do that according to the 
entry_point information. This entry point information does not say 
anything about layers for example (in other words, the DirectoryResource 
is always registered for IBrowserRequest).

Besides that, it cannot say anything about _locally_ registered 
DirectoryResource components.

The second point is probably not such a big deal. I don't think many 
people override DirectoryResource registrations in sub sites. The first 
point however, could maybe troublesome in some cases.

>> 2) I'm fooling around in JJ's work to try and integrate the injection
>> and publihser middleware's into one. I have the gut feeling it should be
>> possible to not use a "composite application", but the merely wrap a
>> Grok application in one middleware that knows when it should either pass
>> through to the actuall grok app, or when it has to serve a resource.
>
> I agree. it's doable, the question is : is it needed ? One or 2 middle
> wares, it doesn't make much difference.

It is not so much about one or two middlewares, I should've left that out.

It _is_ about having to have a separate "URL namespace", for example 
called "/resources" that the publishing middleware knows about for 
publising the resources. It implies any frontend server (say Apache) has 
to know about this "split" between to real app and the resources as well 
for the rewrites.

regards, jw