Philipp von Weitershausen wrote:
(Note that in my original reply to ChrisW, I tried to be pragmatic. Of
course, if ChrisW has the resources to go into this refactoring, by all
means, let's do it).
No resources, sorry :-(
Just a desire to see this "done right" :-S
The pragmatic approach is just to make like Sidnei and have a zodb with
only one root object in it...
There are two parts of your question. Making it simpler to plug in a
different application root, and dealing with ZConfig.
This is true... while I'd love to have config have nothing to do with
the problem at hand, I guess, as you point out, it's currently woken in.
I guess a start would be to make it simpler to *not* use ZConfig but
use a.n.other configuration method. I have memories of Jim having a
proposal about this?
In order to implement a simpler security mechanism for grok, we had to
re-implement every single publication (though of course subclassing was
still possible, but we had to create a new variant of every publication
class). That shouldn't be necessary.
Yeah, I'm guessing there's a few places where:
-getting the root object
-setting up the component achitecture
-setting up the servers
-setting up the security policy
...all run into one and maybe now's the time to burst them open?
Simplistix - Content Management, Zope & Python Consulting
Zope3-dev mailing list