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 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