[Grok-dev] Killing zope.app from grok

[Souheil CHELFOUH]

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
>
> zope.processlifetime.IDatabaseOpenWithRoot
>
> (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
> dependencies...
>
> 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.
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>