On 3/15/06, Tres Seaver <[EMAIL PROTECTED]> wrote:
> I wonder if there isn't a sore spot which is driving a lot of the
> discussion here, but isn't being mentioned:  the experiment in form
> definition (browser:addform / browser:editform).  The interesting thing
> about that experiment is that it *almost* worked, as magic;  its failure
> was not in what it made easier (generating a view from a schema *and* a
> policy), but in what it made harder (changing the behavior of the
> generated view).

Isn't that always the case though? Besides - I don't think there's
anything more vague than the concept of 'policy'. What policy? Where
did it come from? Who wrote it? In what?

Anyways, I don't mind if someone wants 'browser:addform' as an add-on.
But I don't think those things belong in the core. If someone wants to
make a package that lets them "build a web site using nothing but ZCML
to glue a bunch of crap together!" then lets have it. But not in the
core. It's limiting. It's restrictive. The bit that it makes hard is
the bit that most people get to at some point in the lifecycle of
their web application. Why make them switch paradigms at that point?

ZCML can only carry people so far. And we can only push it so far (if
that's the path we follow) before it starts developing the needs for
more programming language type features like full expressions. I say
we cut it down to size now.

> Developers who are the only admins for the sites they deploy are *not*
> representative of the intended audience for ZCML;  they are much more
> comfortable with "back to Python" as a solution than more traditional
> admins / integrators would be.  "Big" directives, with clearly
> documented knobs for specifying policies, are likely to appeal more to
> folks sho are *not* inclined to write Python.

But the developers have to write the ZCML for their products. That's
the current story. The bigger and weirder and harder that universe
becomes, the less likely that the developers are going to actually use
it 'correctly'. Initial experiments with viewlets and content
providers were the first things that proved the flaws of browser:page
versus browser:view. In browser:view you can specify a 'provides'
attribute. It becomes very useful when you want to allow for viewlets
to show up or not show up for certain pages. It's a powerful feature
of extensibility and integration, I think, to support viewlets/content
providers. But if developers don't know that:

(a) Any implements() statement on their view class is likely to be ignored.
(b) Only browser:view (and zope:view) allow specifying a provided interface
    that a viewlet or content provider can match against. browser:page
    does not.
(c) Writing for viewlets and in small code / small fragments (and using the
    update/render paradigm in general) is the easiest way to make the
    interface extensible.

That makes the integrators job much harder. If browser:view,
browser:page, and zope:view all went away today in favor of
subclassing from formlib.Page, BrowserView, or something else common
that provided the core full-view-page pieces (publishTraverse,
browserDefault, __call__) and only zope:adapter was used as the ZCML
directive, it would be much easier (I think) to start providing views
that can be better augmented by integrators. (Besides, I think
'integrators' are better served by the programming language. Anyone
who thinks they can just download a bunch of random components and
build a unique web site with nothing but XML is deluding themselves).

"Administrators" (if we're talking about system administrators) may be
better served by tools and components that expose certain
configuration options to ZConfig (or whatever might replace it), along
with the tools to generate the skeletons for that. RDBMS connections,
"tag blacklists" if you will, whatever. I don't see anything in the
current ZCML that actually makes it obvious from downloading and
installing Product X (especially if installing means checking out from
subversion or unpacking a .tgz) which elements in it need special
configuration like - which mail server to use, which MySQL login to
use, etc. Instead the ZCML is full of <content>, <adapter>, <utility>,
<browser:*> directives, most of which are essential to that package or
application. You may not want to custom configure 95% of that stuff.
Most of that's just to load the application up into Zope. If there's a
tag blacklist or RDB connection or other hypothetical "administrative"
feature, it's buried amongst all of the developer stuff anyways.
There's no nicely commented file like the default Zope 2 ZConfig file
that details all of the options, why they're there, how to change
them. Instead it's 500 lines of code registering 27 views, 14 menu
items, and a nice chinchilla. How does that ZCML benefit an
administrator or integrator that you feel must be protected from all
of the Python code? Don't you think that, to an outsider, digging

  <viewlet name="kbase.importzipform" for="kbase.interfaces.IKnowledgeBaseSite"

on line 294 of browser/configure.zcml is NOT going to be foreign? It's
only marginally (and I mean *marginally*) better than the following

  <adapter name="kbase.importzipform"

What kind of non developer are either of those options going to appeal
to? If I'm deploying an application, I'd probably prefer to have:

'import zip = off'

As a developer, I can at least from the second ZCML example above, I
can translate that 'for' into a 'getMultiAdapter' call. Which any
'integrator' whose doing their integration in Python may care about
more anyways when they're trying to look something up
programmatically. Besides, looking at any of the above, you're
probably going to have to consult code at some point to really know
what's up with the above. I don't see anyone who doesn't understand
Python and Zope 3 as someone who would prosper in a land ruled only by
ZCML. And I don't see anyone who understands Python as not getting
infuriated with ZCML's roadblocks at some point of ZCML grows towards
a more specialized language.

> The fact that such developer-admins are the primary users of ZCML so far
> is due to the small size of the Zope3 market to date.

I actually see very little of ZCML as it stands now as being
beneficial to admins who don't have some degree of developer in their
blood. ZCML feels more developer oriented. But it also feels like it
tries to coddle the developer to help them get up to speed faster. The
downside of that is what happens when you're at full speed and ZCML
locks you there.

Besides, I think some of the reasons for the small size of the Zope 3
market (to date) is that ZCML is intimidating, or just annoying, to
Python developers looking in from the outside. I still think that
appealing to good, intelligent, passionate Python developers is what's
going to grow Zope 3 by allowing many different kick ass products,
sites, and applications to be built. Making it easy for a site
administrator to install a couple of components isn't going to do much
if there's not a lot of appeal for other developers who haven't
already drunk the kool-aid to write those components. If you could get
all of the lines of XML required to register a viewlet (in a readable
style) down to:

    <adapter name="kbase.importzipform" factory=".export.BatchImportViewlet"

And have everything else in the Python code::

    class BatchImportViewlet(ViewletBase):

I think it's then a lot more appealing to a Python programmer. There's
nothing stopping a knowledgeable administrator from overriding that
<adapter> configuration call and establishing different permissions,
or different 'provides'/'for' settings. Or a different name even. But
I would expect such a person to be knowledgeable.

Since most web sites and applications are matters of some degree of
custom development and *not* just configuration, I think ZCML should
be a thin layer and the Python layer should be robust. I think it
would promote better code, components, applications, sites, etc, if
the Python developer remained the chief focus of the current round of
development. The community of developers will then provide the kick
ass automatic-generated interfaces, or the 'ez-system-configuration'
toolkit, and those will appeal to and be used by their specific
audiences while a strong, clean, and powerful Zope rules all. And then
I never have to lose a day finding out why my Choice field doesn't

Jeff Shell
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to