Hi Roger. You make great points here for why those serious about zope's
potential really ought to consider explicit configuration. I also
believe taking time to understand configuration, dependencies and what
is actually being configured is better that implicitly trusting
something automatic to do the right thing.
Implicit automatic configuration is a good starting point howeverfor
folks just starting z3 as you have pointed out but it is best for to
learn this for the reasons you cited and more.
Good points about concise packages with specific functionality also.
Roger Ineichen wrote:
I guess it's better to learn what's going on then to
develope for newcommers. I guess Grok is the right place
for them. Not that Grok is bad, but the target of Grok,
as far as I can see, is the ability to develop with minimal
effort and everything should just work.
I guess this is not true for zope as "the component system".
There you really have to know what's going on. Or at least
you need to learn that if it comes to speedup optimisation.
There is no Zope3 which fits for everything and z3c packages
which most of them are base libraries are not the level to
blow them up. I realy like to have small independent packages
with minimal dependencies which I can assamble to the right
thing for each project.
Feature separation can be made at different levels: an egg
contains several packages that contain several modules that
contain several classes, and I think you will always have
unused classes in a module, unused modules in a package and
unused packages in an egg, unless there is one egg per class...
What you really want is having control on what is eventually
loaded. Isn't it already possible with zcml?
The exclude directive form zc.configuration helps a lot
to exlude configuration loading. But independent eggs
make it more explicit and let people think one more
time about their dependencies which is allways a good thing.
Zope3-users mailing list