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 , , ,
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
for::
on line 294 of browser/configure.zcml is NOT going to be foreig
