[Grok-dev] five.grok and static resource directory (grokcore.view)
faassen at startifact.com
Mon Aug 25 07:48:37 EDT 2008
Sylvain Viollon wrote:
> 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
> 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. 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.
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?
> 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..
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.
So, you better write clear upgrade notes for grokcore.view if you're
going to take out the static support too.
More information about the Grok-dev