[Grok-dev] Killing zope.app from grok
trollfot at gmail.com
Fri Jan 8 17:22:12 EST 2010
Yes, sure, I'll have to dive deep into it.
Up to now, grokui.admin has been remodeled and I was hoping to include
some introspection back into it.
We'll need both that and the cleaning before we can release anything.
Oh, and i'm still stuck with that shifted namespace :-/
2010/1/8 Martijn Faassen <faassen at startifact.com>:
> Souheil CHELFOUH wrote:
>> Currently, grokui.admin still depends on :
>> zope.app.applicationcontrol and zope.app.appsetup
> Also zope.app.testing (which pulls in a ton of stuff)
> And when I run the buildout I also get grok and such. The buildout
> contains old-style grok instance recipes - I think we want to update
> these to the new ones.
>> I don't see any alternative for these. Any advices on this ?
> I'm going to describe some of the process of analysis I go through here..
> It's important to look at the state in SVN, in case versions that grok's
> KGS depend on are still lagging behind in the refactoring.
> First zope.app.appsetup:
> zope.app.appsetup.IDatabaseOpenedWithRootEvent is now
> (you can see the BBB imports if you look at these)
> getInformationFromEvent is also used from that package. Maybe there's a
> way to avoid it?
> If not, we have do something else. We could move
> getInformationFromEvent. We could lift it up into grokui.admin, but we'd
> like to avoid that. Plus it also depends on something from
> zope.app.publication. An alternative is to move it into
> zope.app.publication then. That would also allow us to break up dependency.
> Perhaps zope.app.publication is something we can't break the link with
> that easily in general with Grok (though grokui.admin should ideally
> still break it..). In this case we should break the dependencies of
> zope.app.publication. The main dependencies of this package are already
> okay, but it still has tons of test dependencies which we should try to
> break by working on the tests of zope.app.publication to try to break
> Now zope.app.applicationcontrol
> IServerControl is an interface. Don't see a quick way to get rid of it.
> You shouldn't be using the RuntimeInfoView directly in grokui.admin. You
> should use the IRuntimeInfo adapter directly. Not that this breaks the
> dependency on zope.app.applicationcontrol, but it will make it easier to
> do so in the future. Same with ZODBControlView. Can you take care of
> that in grokui.admin?
> I'll look at extracting some of this stuff from
> zope.app.applicationcontrol into something more reusable.
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev