[Grok-dev] grok mini-sprint progress
faassen at startifact.com
Thu Jan 21 08:56:54 EST 2010
Hanno Schlichting wrote:
>> This sets up the database, puts a root object in there, sets up
>> sessioning, etc.
> Would it make sense for Grok to move this kind of setup into the Grok
> package itself? Does Grok already have any kind of custom setup or
> changes this setup in some way?
No, there's a lot of stuff going on there and it's shared with Bream.
>> We need to cut the dependency on zope.app.zcmlfiles in all packages. We
>> experimentally tried this in grokcore.view. It turns out that if we
>> include enough package's ZCML by hand, it works. It's a long list of
>> includes, however.
> The couple of times I did this in Zope packages, I came up with long
> list each time as well. Unfortunately those lists where never quite
> exactly the same. In principle these dependencies should more or less
> reflect the package dependencies and the "ZCML dependency tree" should
> be very similar to the "package dependency tree". It should be
> possible to distribute those testing dependency declarations
> throughout the tree, much like the ftesting.zcml approach worked.
Yeah, I was thinking in the same direction. Perhaps the package's
configure.zcml should just follow the dependency tree and life would be
easy. You'd get too much configuration sometimes, but we've lived with
getting far too much configuration through zope.app.zcmlfiles for a long
>> And if we take the browser tests out, we might want to
>> move them elsewhere, but where? Grok itself?
> You will have to have one place that does integration testing and
> makes sure all the parts fit together as a whole.
> I think that's the role of the "Grok" package. It's probably a place
> for some default policies and integration tests, but shouldn't contain
> any functionality of its own. That's what I tried to do for Plone when
> trying to dismantle the dependency bomb ;-)
Yeah, probably Grok itself would be that place. Of course grokcore.*
packages are also used outside of Grok, but perhaps that's not something
to worry too much about.
More information about the Grok-dev