Hey Tres,
[Martijn]
I don't think something being policy means it's automatically a bad
candidate for automation. Information about the policy may after
all be elsewhere in the system, for instance in a buildout.cfg.
Tres Seaver wrote:
You don't see cases already where you want to use something from
somebody else's package / egg, but don't want to accept every
configuration choice they make? This is pretty hard to do if the
system automagically wires in every pacakge's 'configure.zcml'. One
of the big knocks against Zope2's 'product" story was exactly this:
there was no way to use a product without accepting its entire
"configuration."
There are always cases in software where automation gets in the way, and
I see cases. That doesn't mean I don't want automation in the first
place. It means I want a way to get rid of automatic behavior. David
wasn't proposing getting rid of manual configuration, but have an option
to have it automatic as well.
I agree that we need better ways to selectively use Zope 3 extensions. I
would for instance like to use Zope 3 extensions without having to use
their browser registrations, I don't think we're there yet, as having to
manually copy all of an extensions's ZCML *without* browser
registrations leads to maintenance difficulties.
Often when using a Zope 3 package though I'm fine with using all
registrations in it.
I would cheer if somebody proposed writing a UI which introspcts
packgaes for such suggestions, and allows the site manager to
merge / override them to create an appropriate 'site.zcml'.
Until then, I don't want package authors dictating to site
managers.
Who are these ZCML-using site managers you are speaking of? Anyway,
are you saying you want some form of ZCML UI to be created before
*any* automation can be implemented? Asking for the creation of a
UI on the Zope 3 mailing list is paramount to waiting forever...
*I* am the user I'm talking about: I want to be able to use others'
components without swallowing whole their configuration choices;
today, that means copying and modifying their 'configure.zcml' files.
Okay. I read "site manager" as a non-developer user who needs a UI. I
have a hard time imagining non-developers doing much with ZCML.
If you never automate policy, you'll be writing a lot of stuff by
hand. That may be fine for you, but I myself would prefer to write
less boring code and focus on more interesting problems.
Automation which is hard to understand and override is the source of
the "Z shaped learning" curve which plagued Zope2; it also plagues
other convenience-oriented frameworks outside of Zopeland.
I think there are a number of causes why Zope 2 is hard to learn, and
this is one of them. I don't consider it to be the only one - were it
only that simple. :)
Another one is inconsistency: there quite a few different spellings and
ways to do things, different per product. This makes it harder to learn.
Zope 3 has done a good job avoiding this problem.
Another reason Zope 2 is hard to learn is that it presents people with a
ZMI that eventually limits them, and switching to filesystem-based
development is a big transition. Zope 3 in not offering a ZMI based
development pattern has avoided this problem, though unfortunately
filesystem-based development with Zope 3 is still not that easy to get into.
Another reason Zope 2 is hard to learn, at least traditionally, is that
it introduced a ton of concepts people weren't used to. This problem
Zope 3 still shares with Zope 2, though some of the concepts are
different. We can work on this problem by smoothing out the learning
curve, not requiring people to understand a lot of concepts before they
can get simple things done. Automation can be of help in accomplishing
this, by providing people with reasonable default behavior that they can
later override.
Another problem with Zope 2, in my opinion, is *lack* of automation - it
sometimes takes way too much work to get something set up. There is
simply a lot to do. This is a problem that Zope 3 hasn't always avoided
either, and in some places has enhanced. Flexibility and automation are
pulling in different directions at times, and we should be careful about
a balance here.
While exposing people to explicit configuration (ZCML) and dependency
information greatly increases flexibility and avoids some problems with
automation, it does that at the mental overhead of having to deal with
these things in the first place. Modularization can help there - you do
not need to deal with the ZCML or sub-dependencies of a package as
you're just a user of it (unless you have some special requirements).
That modularization is partially broken if you have to understand a
package's dependency structure just to be able to install it.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
