[Grok-dev] five.grok and static resource directory (grokcore.view)

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Sylvain Viollon wrote:
> [snip]
>>    But I still have a problem, because basically I need to replace the
>> registered DirectoryResourceFactory of Zope 3 by the one of Five, but I
>> don't see how to overrides the grokker which do it in grokcore.view.
>>
>>    There is two way I think to fix that:
>>
>>    - To move back the StaticGrokker to the grok package, so I can
>> create one in five.grok which don't conflict with it.
>>
>>    - To set different priority on both grokkers, the one in
>> five.grok will have on higher, and the on in grokcore.view will
>> register the resource directory only if there is no registration done
>> yet.
>>
>>    I prefer the first one, because it's cleaner I think, but that's
>> means if people use grokcore.view without grok or five.grok, they are
>> not going to have a static resource directory registered.
> 
> It's an important usecase for us that grokcore.view works without Grok 
> or five.grok.

Yes. I would also like to stress again that while I acknowledge 
five.grok being a driving factor behind grokcore.view, I don't think we 
should have Zope 2's sometimes butchered way of looking at things 
dictate the way we split up Grok.

> That said, it might indeed be that the 'static' story is 
> something that is more related to Grok itself than that it belongs to 
> grokcore.view; people using straight Zope 3 would register their own 
> resource directories using ZCML, for instance.

Then perhaps we should give them the opportunity to do so? Just removing 
the functionality again now doesn't seems fair. grokcore.view 1.0 has 
been released a while ago and I've heard some people are happily using 
it in Zope 3.

> This would mean that it could be moved back into the Grok trunk and out 
> of grokcore.view. (Again I'd like Philipp's opinion on this...) Could 
> the logic that 'static' is available in page templates be safely moved 
> back into Grok core?

Yes, from a technical point of view it could easily be moved back to the 
core.

>>    If you can give me your opinion, I would like to merge the branches
>> I have made with trunk, because I would like to use this feature !
> 
> It's not easy to decide.. I think I'm in favor of your first plan; 
> moving the StaticGrokker back into the Grok package. We can, I think, 
> always move it out again into its own grokcore.static package later if 
> we wish, though it'll be hard to make it be as integrated into 
> grokcore.view as it is now..

Exactly.

>   This might mean documentation updates for grokcore.view, and those 
> people who are already *using* grokcore.view in straight Zope 3 packages 
> might have a problem. I hope we don't have too many of these people yet.

Yes, we'd need documentation *and* test updates for grokcore.view. I 
haven't seen either on Sylvain's branch yet.

> So, you better write clear upgrade notes for grokcore.view if you're 
> going to take out the static support too.

My Solomon's Judgement would be to agree to the moving back static to 
Grok, but to demand that in its place, grokcore.view was given a general 
way of registering resource directories. Grok's static thing would then 
just be a special case of that.