zope3 configuration
so, i feel like my mental abs are sore. the tagline "xml situps" is an apt one.
zcml. the debate rages on in mailing lists, and probably will continue to. I've read arguments on both sides, and I don't really disagree with either side. but this is what i'm thinking about...
i read an email of Stephan Richter's recently where he said that he does all site configuration in python code. I'd considered that before, but didn't know if it was the "right" way to do it. if it is, then I'll probably start doing it that way too. Stephan is probably the right guy to take Zope3 queues from, if you're going to pick someone.
but it makes me wonder if the zmi should even exist. or if maybe it should be included in zope3 packages only if the developer wants it there. like "from zope.app.zmi.admin import controlpanel" or something. or "from zope.app.zmi.error import errorpanel".
which leads, sorta, to my next point. all of the zmi default display pages... they make things fast, certainly. but i think that they're almost immediately a crutch, too. i think they keep the developer from really having to dig into the zope3 page creation machinery, and i think that the page creation machinery (now formlib, which i like a lot) is something that any zope3 developer needs to be fluent in.
i'd like to see the day where "bin/runzope" just starts up a very small shell of functionality, with whatever the developer has included. maybe we could move the zmi to "zope3admin" or something. i don't know that i think the zmi has any real place "being there" in a live app. i don't see any reason that it couldn't be started on it's own port, and hook into the zodb on it's own. i know when i need to do any real debugging of zope3, i do it from zopectl debug anyway, not through the errors page.
so I don't know. there's a lot that the zmi does, certainly. but i think it prevents the "simplicity" that's necessary to get new developers on board for zope3. I know if I hadn't had to learn how to use zcml, zpt, the zope3 framework, AND the zmi all at once, i'd have been in better shape. zcml, zpt, and the framework are all non-domain-specific in their implementation. and it's enough to learn on it's own, even being basically just code and markup.
but then to learn the right order to register new utilities, deregister them, delete them, add them, chain the dependencies...
I am now, just now and I hadn't thought of it before, propsing a "Zope3 Site Builder" set of markup or template code. some way to set up a chain of dependencies, registrations, and necessary content objects. I haven't thought about it that much yet, but I can't imagine it wouldn't be doable. some new pythonic template that could set up and tear down a site in the right order.
zcml. the debate rages on in mailing lists, and probably will continue to. I've read arguments on both sides, and I don't really disagree with either side. but this is what i'm thinking about...
i read an email of Stephan Richter's recently where he said that he does all site configuration in python code. I'd considered that before, but didn't know if it was the "right" way to do it. if it is, then I'll probably start doing it that way too. Stephan is probably the right guy to take Zope3 queues from, if you're going to pick someone.
but it makes me wonder if the zmi should even exist. or if maybe it should be included in zope3 packages only if the developer wants it there. like "from zope.app.zmi.admin import controlpanel" or something. or "from zope.app.zmi.error import errorpanel".
which leads, sorta, to my next point. all of the zmi default display pages... they make things fast, certainly. but i think that they're almost immediately a crutch, too. i think they keep the developer from really having to dig into the zope3 page creation machinery, and i think that the page creation machinery (now formlib, which i like a lot) is something that any zope3 developer needs to be fluent in.
i'd like to see the day where "bin/runzope" just starts up a very small shell of functionality, with whatever the developer has included. maybe we could move the zmi to "zope3admin" or something. i don't know that i think the zmi has any real place "being there" in a live app. i don't see any reason that it couldn't be started on it's own port, and hook into the zodb on it's own. i know when i need to do any real debugging of zope3, i do it from zopectl debug anyway, not through the errors page.
so I don't know. there's a lot that the zmi does, certainly. but i think it prevents the "simplicity" that's necessary to get new developers on board for zope3. I know if I hadn't had to learn how to use zcml, zpt, the zope3 framework, AND the zmi all at once, i'd have been in better shape. zcml, zpt, and the framework are all non-domain-specific in their implementation. and it's enough to learn on it's own, even being basically just code and markup.
but then to learn the right order to register new utilities, deregister them, delete them, add them, chain the dependencies...
I am now, just now and I hadn't thought of it before, propsing a "Zope3 Site Builder" set of markup or template code. some way to set up a chain of dependencies, registrations, and necessary content objects. I haven't thought about it that much yet, but I can't imagine it wouldn't be doable. some new pythonic template that could set up and tear down a site in the right order.
posted by baldtrol at 4:01 PM
0 Comments:
Post a Comment
<< Home