--On 22. April 2007 02:52:58 +0100 Martin Aspeli <optilude@gmx.net> wrote:
Christopher Lozinski wrote:
I think I have figured out how to do it. This looks like a ZMI based ZClass, you can define it through the ZMI, you can add instance variables, you can add instance methods, all through the ZMI, but you can change inheritance, because it is really a product created on the file system.
If there is such an easy translation from ZMI-based ZClass to filesystem product, then why not write the filesystem product in the first place?
Check out the proposal. http://wiki.zope.org/zope2/ZClassesNGAndProductNG
... the names ZClassNG and ProductNG (especially the latter) are bad, to begin with, but oh well. You wouldn't be the first. :)
You're assuming there is an obvious one-to-one mapping between ZClass syntax and non-ZClass products on the filesystem, which may or may not be true.
He's trying to reinvent wheels? Reads a bit like GrokNG :-)
You're relying on code generation, so you'll run into trouble when the two versions (ZODB and filesystem) diverge for whatever reason (someone edited the code, say).
Generating code is a one-way-road. Either your internal model is executable somehow or better write the code by hand.
Also, Zope needs a restart to load a new product, which will mess with the workflow.
But the bigger picture here is that an awful lot of people are telling you that spending your time on this is a bad idea, that you'll probably find it more difficult than you imagine, and that if you are going to invent new things, your time may be better spent pulling the same direction that most other people are.
By all means, give it a go, but you will probably find it difficult to get help when you are stuck because (a) no-one else seems to care and (b) not many other people seem to even know how this should work.
Amen. Sorry Christopher but the quality of this proposal is more than poor. Andreas