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 for:: <viewlet name="kbase.importzipform" for="kbase.interfaces.IKnowledgeBaseSite" class=".export.BatchImportViewlet" manager="kbase.skin.viewlets.IMultipleFormsManager" permission="br.cms.AddAndRemoveContent" layer="kbase.skin.KBase" /> 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 anyways:: <adapter name="kbase.importzipform" factory=".export.BatchImportViewlet" provides="zope.viewlets.interfaces.IViewlet" for="kbase.interfaces.IKnowledgeBaseSite kbase.skin.KBase kbase.skin.viewlets.IMultipleFormsManager" locate="yes" permission="br.cms.AddAndRemoveContent" /> 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" permission="br.cms.AddAndRemoveContent" locate="yes" /> And have everything else in the Python code:: class BatchImportViewlet(ViewletBase): implements(IViewlet) adapts(...) 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 work. -- Jeff Shell _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com