I guess as a rule, I often can't really afford to have an opinion
about whether some configuration style is "better" in any specific
circumstance. The answer is always "it depends".
In particular, I don't think imperative vs. declarative configuration
is an either-or choice. Using ZCML is good for creating frameworks
and other extensible applications. Grok-style declarative
configuration is good for providing better locality of reference to
configuration statements. But both under the hood eventually call
into imperative code to get their jobs done. Exposing this imperative
code via a nice API I think is useful, because it centralizes and
canonizes the definition of what the framework actually does.
The framework shouldn't make an arbitrary decision about which sort of
configuration goes where based on opinion; I'd rather just make all of
it available in both an imperative and a declarative form and let
folks make up their own minds about which kind they prefer. I don't
believe it's my place (nor am I really smart enough) to impose any
limitations on how a developer chooses to work with the framework. If
he wants to use all-imperative config, fine. If he chooses to use
all-declarative config, same. If he chooses a hybrid, also fine.
It's easy enough to offer him the option of using one or the other, or
both. The BFG docs do recommend using ZCML, but this is only because
most examples already in the wild use ZCML; recommending ZCML isn't a
statement of opinion.
I also think a lot of the talk about servicing "integrators" just sort
of muddies the waters. Integrators are really just inexperienced
programmers; the fact that they don't really *want* to be programmers
doesn't really change the fact that they are. Limiting the set of
configuration options available to all programmers based on an subset
in their ranks is sometimes useful, but not *always* useful.
Sometimes its nice to be able to just bash to fit without taking an
integrator into account, because taking the integrator into account
often leads to premature generalization. On many projects, there is
exactly no one playing the integrator role at all; on these sorts of
projects, I think it makes sense to ignore the integrator until a
genuine person playing this role appears. It's not like you can't
later change the code to be more general, and make use of ZCML, and
other bits that make parts of the application overrideable.
All that said, to me, it's obvious in hindsight that a "canonical"
configuration API should be an imperative API, and the declarative
helper stuff should just use it.
Why must I put a title in here?
Posted byoptiludeat
2010-01-02 07:28 PM
Hi Chris,
I think we agree. It's quite useful for someone like me to draw a line between working on an open source application like Plone, where we do have a lot of "integrators" who really just want to customise a few things without being programmers at all (and a whole bunch of shades in between, like being programmers but not comfortable with Python, or being Python developers but not comfortable with Zope), and working on client projects.
When I write open source Plone code, I have to think about how easy it is for people to customise the policy I put in, whether the means of customisation are discoverable, and whether there is adequate documentation for various audiences. In this case, imperative configuration is probably an anti-pattern, because it makes it harder to discover or introspect the configuration. For that reason also, we are (still) using ZCML for all configuration in Plone core.
When working on a client project, it's often easier to cut corners. In particular, I usually work with development teams now already experts in Zope or Plone (or even Python or web development). That has opened my eyes to a lot of things. One of those things is that needing two files open in your editor makes it twice as difficult to complete a task. Here, I find the "locality" of grok-style configuration useful. I also subscribe to Martijn's view that if the framework has an opinion on how you should lay out your code, that makes it easier to use, because inexperienced programmers are both less set in their ways, and more confused by more choices.
Obviously, having a sane API for your configuration and not tying it up with the exact expression of that configuration is useful. I think zope.component delivers on this view. Zope's browser view configuration doesn't, but it should. In Zope 2, that's confounded by some evil acquisition-related stuff that's only become unnecessary in Zope 2.12. So I think we're getting there. :)
I guess as a rule, I often can't really afford to have an opinion
about whether some configuration style is "better" in any specific
circumstance. The answer is always "it depends".
In particular, I don't think imperative vs. declarative configuration
is an either-or choice. Using ZCML is good for creating frameworks
and other extensible applications. Grok-style declarative
configuration is good for providing better locality of reference to
configuration statements. But both under the hood eventually call
into imperative code to get their jobs done. Exposing this imperative
code via a nice API I think is useful, because it centralizes and
canonizes the definition of what the framework actually does.
The framework shouldn't make an arbitrary decision about which sort of
configuration goes where based on opinion; I'd rather just make all of
it available in both an imperative and a declarative form and let
folks make up their own minds about which kind they prefer. I don't
believe it's my place (nor am I really smart enough) to impose any
limitations on how a developer chooses to work with the framework. If
he wants to use all-imperative config, fine. If he chooses to use
all-declarative config, same. If he chooses a hybrid, also fine.
It's easy enough to offer him the option of using one or the other, or
both. The BFG docs do recommend using ZCML, but this is only because
most examples already in the wild use ZCML; recommending ZCML isn't a
statement of opinion.
I also think a lot of the talk about servicing "integrators" just sort
of muddies the waters. Integrators are really just inexperienced
programmers; the fact that they don't really *want* to be programmers
doesn't really change the fact that they are. Limiting the set of
configuration options available to all programmers based on an subset
in their ranks is sometimes useful, but not *always* useful.
Sometimes its nice to be able to just bash to fit without taking an
integrator into account, because taking the integrator into account
often leads to premature generalization. On many projects, there is
exactly no one playing the integrator role at all; on these sorts of
projects, I think it makes sense to ignore the integrator until a
genuine person playing this role appears. It's not like you can't
later change the code to be more general, and make use of ZCML, and
other bits that make parts of the application overrideable.
All that said, to me, it's obvious in hindsight that a "canonical"
configuration API should be an imperative API, and the declarative
helper stuff should just use it.
I think we agree. It's quite useful for someone like me to draw a line between working on an open source application like Plone, where we do have a lot of "integrators" who really just want to customise a few things without being programmers at all (and a whole bunch of shades in between, like being programmers but not comfortable with Python, or being Python developers but not comfortable with Zope), and working on client projects.
When I write open source Plone code, I have to think about how easy it is for people to customise the policy I put in, whether the means of customisation are discoverable, and whether there is adequate documentation for various audiences. In this case, imperative configuration is probably an anti-pattern, because it makes it harder to discover or introspect the configuration. For that reason also, we are (still) using ZCML for all configuration in Plone core.
When working on a client project, it's often easier to cut corners. In particular, I usually work with development teams now already experts in Zope or Plone (or even Python or web development). That has opened my eyes to a lot of things. One of those things is that needing two files open in your editor makes it twice as difficult to complete a task. Here, I find the "locality" of grok-style configuration useful. I also subscribe to Martijn's view that if the framework has an opinion on how you should lay out your code, that makes it easier to use, because inexperienced programmers are both less set in their ways, and more confused by more choices.
Obviously, having a sane API for your configuration and not tying it up with the exact expression of that configuration is useful. I think zope.component delivers on this view. Zope's browser view configuration doesn't, but it should. In Zope 2, that's confounded by some evil acquisition-related stuff that's only become unnecessary in Zope 2.12. So I think we're getting there. :)
Martin