Re: [Zope3-dev] Re: One namespace for ZCML
Roger Ineichen wrote: I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
On Wednesday 15 February 2006 07:59, Philipp von Weitershausen wrote: I realize that and I think at least the concern was valid. As for the solution, I rather prefer the convenience (which reads for me as automation when it get rids of dead chicken direcives) to be in Python. But I think this is exactely the problem. Convenience is often geared towards non-technical people, like designers and integrators. For them to touch or write Python code is horrifying. One of the goals of ZCML was to address this audience and day: Look add, edit or change this and that directive and you are good to go. It was also one of the reasons XML was chosen. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Stephan Richter wrote: I realize that and I think at least the concern was valid. As for the solution, I rather prefer the convenience (which reads for me as automation when it get rids of dead chicken direcives) to be in Python. But I think this is exactely the problem. Convenience is often geared towards non-technical people, like designers and integrators. For them to touch or write Python code is horrifying. I don't think designers will have to touch Python. I don't even think they will often touch ZCML. The designers I hired never had to... One of the goals of ZCML was to address this audience and day: Look add, edit or change this and that directive and you are good to go. It was also one of the reasons XML was chosen. I think ZCML is addressing people who build packages, people who make applications out of these packages and people who deploy those applications. I think in all three cases we can assume enough experience with Zope and Python to expect them to enter, say, a dotted name. And, of course, these people typically overlap. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: One namespace for ZCML
Hi Philipp [...] Subject: Re: [Zope3-dev] Re: One namespace for ZCML Roger Ineichen wrote: I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). Yes, I agree, that's also a good base for a menu simplyfication. If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). I think it's to complex it right now since I'm not sure at all if my idea will work. Let me try to give a short overview. - Merge the menu and menu item to one implementation - the above will also allow to implement nested menus. Right now the implicit menu, registred in views, don't have a id itself. This means they are unuseful for nested menu registrations. - move menu registration out of the view directives, (like described in your proposal) - Also refactor the IFactory concept. Use IFactory adapters on folders instead of IFactory utilities. The last part IFactory adapters instead of IFactory utilities depends on a application I wrote and was running in serious problems because of the slowdown which depends on IFactory utilies lookups. I'm not sure if somebody will agree on this, but I think if I can profile the IFactory utility implementation and show the slowdown, we have a better base for a proposal. This would also solve some namespace problems we have with the content type name registration. Note; nested menus are implemented since more then a half year. But they are not useable with the existing menu items which are registered inculded in the view directives. Because in the view directive registred menus are only menu items which are not nested. Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: snip Just note that I'm explicitly not addressing automation as a use case for custom ZCML directives. I believe automation is best done in Python. If you're trying to invent a new ZCML directive that does something else to an adapter/view/utility before registering it (e.g. putting an interface on it, adding attributes, wrapping it in a factory etc.), then that should be done in Python. zope.formlib is a good example of how browser:page is enough for registering a form as it isn't ZCML's concern *what* kind of page we're registering. All that is in Python. I'll aggree to an extent: where this pactice breaks down is when the argumentes to the automation need to be supplied as configuration. At that point, a wrapper argument which allows the user to specify those values without writing / modifying PYthon can be a win. In the case of Shane's webroot proposal, for instance, the filesystem path to the root would be best specified as an attribute to a custom directive, even if the directive did nothing more than configure a single global utility. snip Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8cKj+gerLs4ltQ4RAvo3AKCs0XzL07Yo6TYUGjtR9TwVHsWkSQCgvSul z/pSuIU/iBLm3x3ad1IR2G4= =fyuR -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Philipp von Weitershausen wrote: Yet again looking for comments, this time at: http://dev.zope.org/Zope3/OneNamespaceForZCML. Let me add my -1 to this. I'm all for reducing the number of namespaces in the standard directives, and reducing the number of directives too, but getting rid of namespaces, as others have pointed out, removes clean ways of extending ZCML for third-party frameworks. For example CPS currently has a cps:upgradeStep directive: cps:upgradeStep title=Upgrade catalog from Zope 2.7 handler=.upgrade.upgrade_catalog_Z28 checker=.upgrade.check_upgrade_catalog_Z28 sortkey=-10 / cps:upgradeStep title=Clean catalog of broken objects source=3.3.4 destination=3.3.5 handler=.upgrade.upgrade_334_335_clean_catalog / Now you could have a CpsUpgradeStep directive, but I hope everyone agrees that prefixing names is a poor man's way of doing namespaces. You could also maybe provide the same info using two or three other standard directives, but that would be very inconvenient. Maybe a simple zope 3 component doesn't need to provide extensions to ZCML using a namespace, but any *framwework* on top of it will quickly need them. Finally -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Tres Seaver wrote: Just note that I'm explicitly not addressing automation as a use case for custom ZCML directives. I believe automation is best done in Python. If you're trying to invent a new ZCML directive that does something else to an adapter/view/utility before registering it (e.g. putting an interface on it, adding attributes, wrapping it in a factory etc.), then that should be done in Python. zope.formlib is a good example of how browser:page is enough for registering a form as it isn't ZCML's concern *what* kind of page we're registering. All that is in Python. I'll aggree to an extent: where this pactice breaks down is when the argumentes to the automation need to be supplied as configuration. At that point, a wrapper argument which allows the user to specify those values without writing / modifying PYthon can be a win. In the case of Shane's webroot proposal, for instance, the filesystem path to the root would be best specified as an attribute to a custom directive, even if the directive did nothing more than configure a single global utility. In another post I said that this use case is ok because it actually configures this component. That's one of the intended usecases of ZCML. Automation isn't, but then again what you're describing above isn't automation either, so all we're doing right now is agreeing with teach other :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote: As we have learned that we can reduce nearly all component tasks to adapters and utilities, many tasks revolving around registration and configuration of policy also only involve adapters and utilities. By using those elementary directives we can stimulate the learning process for developers (there should only be one way of doing things). Yes, you might have to use two or three directives instead of just one new one, but you'll know what you're doing... And you'll remember it in 2 months. I think that's more valuable than saving a couple of lines today. I think this is the wrong thread. :-) We are discussing the one namespace here. If I would be against replacing one special directive with a couple fundamental directives, I would have voted -1 on the other proposal, which I did not. That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). I do not think namespace declarations are dead chickens. For me declaring a namespace in ZCML is the same as importing a package or module in Python. You would not want all functions and classes in Python live in one namespace, would you? +1 to Stephan's comment; -1 to the proposal. - The opposition to namespace declarations is whiny, as they are the standard way to make XML extensible. Unless we are going to quit using XML, outlawing namespaces would be equivalent to saying, you may not extend ZCML; I don't think we are smart enough to make that ukase. I think the Last Law of Python according to the Prophet Peters obtains here as well. - Note that the non-XML language also used by Zope (ZConfig) has its own extensibility mechanism: in fact, Fred and I made it possible in November for Zope2 products to register their own schemas for those extensions, which was a blocker for moving some configuration out of software. - I don't want to encourage people to do configuration in Python: we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the ZCML delenda est thread. - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. - Many of the objected-to directives exist precisely because people did not want to type the much more verbose equivalents which were the original, cleaner spellings. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8KAe+gerLs4ltQ4RAtREAJwMf91w4eEGbvp0Llz0SKg7bkoTpwCgyDce rEhfptDFqlhXZjSAZ5FZXxw= =aIxe -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: One namespace for ZCML
On Feb 13, 2006, at 10:05 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote: [...] +1 to Stephan's comment, Tres' comment, and Tres' use of the word ukase (which I had to look up). -1 to the proposal. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: One namespace for ZCML
On Monday 13 February 2006 10:05, Tres Seaver wrote: - I don't want to encourage people to do configuration in Python: we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the ZCML delenda est thread. - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. - Many of the objected-to directives exist precisely because people did not want to type the much more verbose equivalents which were the original, cleaner spellings. Mmmh, I had totally forgotten about this design goal/use case. Thanks a lot for pointing this out. I will not change my vote on the other proposal, but I think we have to keep this in mind when talking about ZCML simplification. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: - The opposition to namespace declarations is whiny, as they are the standard way to make XML extensible. Unless we are going to quit using XML, outlawing namespaces would be equivalent to saying, you may not extend ZCML; I don't think we are smart enough to make that ukase. I think the Last Law of Python according to the Prophet Peters obtains here as well. I'm neither trying to follow the whiny people who detest XML and therefore ZCML nor am I trying to make ZCML not extensible. That said, I think that ZCML's usage of namespace is quite arbitrary. Why is browser and mail-related stuff on its own namespace but security-related stuff not? I'm not arguing (here) against refactoring the namespaces in which core directives are declared. I'm arguing against the idea that namespaces are bad in general. Why is it then recommended that third-party packages use their own namespaces, even though they might only have browser-related directives to register...? Third-party packages which don't define new directives don't need their own namespaces. If, for instance, Plone adds a plone:view directive which is nothing more than a no-op wrapper around 'browser:view', that would be a Bad Thing (TM). If, however, they add a 'plone:frobnatz' directive which does something magical and outside the scope of the Zope core, and document how to use it when setting up Plone, that would be a Good Thing, especially if it kept people from changing site policy by customizing software. I don't really see the point in ZCML's using namespaces. What good do they provide? Seriously, is it just the prefix? Well, we don't need the namespaces for that. ZCML *must* support extensibility, and therefore must continue to allow packages to register their own namespaces (unless we abandon XML altogether). Otherwise, we give up the ability to check that a given directive can actually be interpreted at all, which would be a Bad Thing. - Note that the non-XML language also used by Zope (ZConfig) has its own extensibility mechanism: in fact, Fred and I made it possible in November for Zope2 products to register their own schemas for those extensions, which was a blocker for moving some configuration out of software. I'm not sure what to do with this info... Just note that being able to extend the configuration language from non-core code is an important use case. - I don't want to encourage people to do configuration in Python: Rest assured neither do I. we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the ZCML delenda est thread. I have heard such feedback, otherwise I wouldn't have taken the time to write the proposal. I've also heard positive feedback on this particular matter (reducing ZCML namespaces to one). Again, I wouldn't have brought it up otherwise. A lot of the feedback seemed to be along the lines of: - ZCML sux -- I won't use Zope3 until it is gone! They weren't gonna use it anyway. - Why do I have to declare the namespaces? (XML haters, for the most part; note that I am not an XML fanboy myself). - Why does the core use more than one namespace? This question seems legitimate to me: I think we wanted to allow non-mangled names for otherwise conflicting directives, e.g. 'browser:view' and 'xmlrpc:view'. - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. This belongs in the other thread, really. But here it goes anyway: I'm not convinced that people who deploy apps will actually go as deep as editing package ZCML, or even overrides for that matter. I would rather imagine they turn ZCML features on or off (which would then turn on or off ZCML directives via zcml:condition) Nope. You are ignoring the cases which are currently done TTW in Zope2: mailhost configuration, for instance, or caching policies, etc. If an application wants to add a diretive which makes it possible to configure such policies in ZCML, why should we prevent that? - Many of the
[Zope3-dev] Re: One namespace for ZCML
Tres Seaver wrote: - The opposition to namespace declarations is whiny, as they are the standard way to make XML extensible. Unless we are going to quit using XML, outlawing namespaces would be equivalent to saying, you may not extend ZCML; I don't think we are smart enough to make that ukase. I think the Last Law of Python according to the Prophet Peters obtains here as well. I'm neither trying to follow the whiny people who detest XML and therefore ZCML nor am I trying to make ZCML not extensible. That said, I think that ZCML's usage of namespace is quite arbitrary. Why is browser and mail-related stuff on its own namespace but security-related stuff not? I'm not arguing (here) against refactoring the namespaces in which core directives are declared. I'm arguing against the idea that namespaces are bad in general. I'm not arguing that either. I'm just saying that one namespace is sufficient. Why is it then recommended that third-party packages use their own namespaces, even though they might only have browser-related directives to register...? Third-party packages which don't define new directives don't need their own namespaces. If, for instance, Plone adds a plone:view directive which is nothing more than a no-op wrapper around 'browser:view', that would be a Bad Thing (TM). If, however, they add a 'plone:frobnatz' directive which does something magical and outside the scope of the Zope core, and document how to use it when setting up Plone, that would be a Good Thing, especially if it kept people from changing site policy by customizing software. Sure, I don't mind the policy-changing frobnatz. After all, that's what ZCML is for, defining and adjusting policy. I don't really see the point in ZCML's using namespaces. What good do they provide? Seriously, is it just the prefix? Well, we don't need the namespaces for that. ZCML *must* support extensibility, and therefore must continue to allow packages to register their own namespaces (unless we abandon XML altogether). I don't see how that conclusion works. It seems like you think namespaces are needed for extensibility. They are not. We can add directives to existing namespaces just fine. XML Namespaces are useful for extending existing XML dialects with stuff from others. E.g. embedding SVG into HTML, adding TAL/METAL to HTML, and the like. The way ZCML uses namespaces isn't even half-way compatible with that. For example, I couldn't add inline-documentation to ZCML unless I configured no-op directives for my particular documentation elements, just so that the ZCML machinery wouldn't complain it encountered unknown directives. Why would it think that they are directives? I can add inline-documentation to XSL or, heck, OpenDocument just fine. ZCML wants to be XML but it's weird about it. Otherwise, we give up the ability to check that a given directive can actually be interpreted at all, which would be a Bad Thing. Huh? - Note that the non-XML language also used by Zope (ZConfig) has its own extensibility mechanism: in fact, Fred and I made it possible in November for Zope2 products to register their own schemas for those extensions, which was a blocker for moving some configuration out of software. I'm not sure what to do with this info... Just note that being able to extend the configuration language from non-core code is an important use case. I agree it is. we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the ZCML delenda est thread. I have heard such feedback, otherwise I wouldn't have taken the time to write the proposal. I've also heard positive feedback on this particular matter (reducing ZCML namespaces to one). Again, I wouldn't have brought it up otherwise. A lot of the feedback seemed to be along the lines of: - ZCML sux -- I won't use Zope3 until it is gone! They weren't gonna use it anyway. ... - Why do I have to declare the namespaces? (XML haters, for the most part; note that I am not an XML fanboy myself). I am *for* declaring XML namespaces. I'm against declaring too many pointless namespaces. - Why does the core use more than one namespace? This question seems legitimate to me: I think we wanted to allow non-mangled names for otherwise conflicting directives, e.g. 'browser:view' and 'xmlrpc:view'. Yes. Using namespaces for this is arbitrary, though. We could just as well have chosen different names, e.g. browserView and xmlRpcView.
Re: [Zope3-dev] Re: One namespace for ZCML
Hey, Good comments, Tres, thanks. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Martijn Faassen faassen at infrae.com writes: What happens if you want to add your own statements? Should you still do that in your own namespace? No. But I don't think that it'll be much of a problem. I expect that not a lot of 3rd party packages will need their own set of ZCML directives. Well, hopefully not, but that doesn't mean it doesn't sometimes make sense. Zope should worry about defining what type of configuration ZCML is useful for and documenting that. Third party authors should then decide whether their configuration fits that same general profile, and if so should be allowed to add their own ZCML directives. And these sure as hell ought to use namespaces, because they are not part of the core Zope namespace. Specifically, they can never be part of any core Zope ZCML DTD (and there really should be one!), and they should really have their own DTD to validate against. For this to work, they *must* have a separate namespace. Flatting the namespace in order to save a few characters of typing is akin to braking XML conventions and standards, and not for very good reason. Currently I know of five and union.cms doing it. I'm certainly considering doing so for Silva. Then there's the example of many packages in the Zope 3 core which are actually quite independent from the core itself, such as the email package, and may in the future become Zope extensions. I'd say adding a namespace is a common method for abstracting application specific component configuration tasks. I also don't see what's bad about it and why we'd like to discourage it. Namespaces are the de-facto way of doing application domains in XML. I really don't understand why people fret so much about them. All you have you do is to put in your root node: xmlns:myPrefix=http://mysite.com/dtd/myschema; That URL doesn't need to be real, it just needs to be a unique identifier. And you can choose whatever prefix you want, so if you don't like to type browser, how about just b? I think encouraging third-party developers who *do* need ZCML (and there will be times when that makes sense) to not use their own namespace is to ignore one of the main conventions of XML and thus become a poor XML citizen. I agree that ZCML could use some slimming down, and if that lands us with something that semantically all belongs in a single zope namespace (and recall, if I want, I could use zope as the main unnamed namespace or explicit use a prefix for it) so be it. But if I write an application that needs some configuration or wiring that logically belongs in ZCML, I shouldn't have to invent my own config file format and I shouldn't be inventing my own names in a namespace I don't own. It's kind of the same as saying that all variables in Python should be global because you don't like to write 'from module import foo'. Well ... tough. :) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Philipp von Weitershausen philipp at weitershausen.de writes: The problem is uncontrolled ZCML directive proliferation. It's bad enough that you have to familiarize yourself with a new API when dealing with a 3rd party Zope package. But having to learn a new set of ZCML directives?!? I think many people would be skeptical. Me included. Or a new python API... your package will have to come with documentatio about how it is to be used. If Zope encourages a consistent way of demarcating what is ZCML-configured, what is python-configured and what is not configuration at all, this problem will go away. As we have learned that we can reduce nearly all component tasks to adapters and utilities, many tasks revolving around registration and configuration of policy also only involve adapters and utilities. By using those elementary directives we can stimulate the learning process for developers (there should only be one way of doing things). Yes, you might have to use two or three directives instead of just one new one, but you'll know what you're doing... And you'll remember it in 2 months. I think that's more valuable than saving a couple of lines today. There is always a balance between the aesthetic beauty of reducing everything to a few axiomatic principles, and the way people think. I think you'll find that many people get confused by the view/multi-adapter duality. Yes, it's very neat when you finally get it, but it took me a long time to get my head around it (partially, I admit, because I was reading poor documentation... when I read your book, it made a lot more sense). Be sure to draw a clear line between what things are the same because the implementation lends itself to use the same primitive components, and what things are actually semantically equivalent. That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). I think this is based on a misunderstanding of how XML works (or should work) combined with a somewhat irrational fear of writing a few extra letters. You don't have to declare namespaces you don't use in any particular file, nor do you have to stick to long-winded prefixes if you don't want to. The URIs of namespaces are unique identifiers and can be quite short (e.g. http://zope.org/dtd/core). Ideally, they should resolve to DTDs that can be used for XML validation and by tools to create code-completion etc. Now, if Zope decides that it has a sufficiently small set of concepts to warrant keeping them in a single namespace, that's probably a good thing - less to learn, less to remember. If it turns out there are very clear components with different areas of use, having different namespaces may well work. I'm not a fan of the core vs. browser namespace separation at the moment, for example, but I could see how something radically removed from the core Zope use case would find use for a separate namespace. But third party products that have not (yet) been rolled into core Zope must have their own namespace, to avoid clashes, to permit validation, and simply to meake it clear what is being provided by the third party product. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Philipp von Weitershausen philipp at weitershausen.de writes: I'm not arguing (here) against refactoring the namespaces in which core directives are declared. I'm arguing against the idea that namespaces are bad in general. I'm not arguing that either. I'm just saying that one namespace is sufficient. It may be sufficient for Zope itself (I don't know if it is, I haven't reviewed all current ZCML directives and use cases), but it won't be sufficient for third-party extension or anything else that wants to use ZCML for its own purposes, which seemed to be the argument higher up the thread. If I misunderstood you on that point, please accept my apologies. I am *for* declaring XML namespaces. I'm against declaring too many pointless namespaces. Then I misunderstood you earlier. I'm sorry for that. - Why does the core use more than one namespace? This question seems legitimate to me: I think we wanted to allow non-mangled names for otherwise conflicting directives, e.g. 'browser:view' and 'xmlrpc:view'. Yes. Using namespaces for this is arbitrary, though. We could just as well have chosen different names, e.g. browserView and xmlRpcView. Erm... you can if you want, just use a different xmlns:browserView. It's up to the person writing the XML file, although conventions are useful. Nope. You are ignoring the cases which are currently done TTW in Zope2: mailhost configuration, for instance, or caching policies, etc. If an application wants to add a diretive which makes it possible to configure such policies in ZCML, why should we prevent that? Very true, I forgot to mention that use case. But I also never put them on my hit list, for exactly the reason you mention: They are about policies and configuring code components. So, yes, deployers will edit ZCML directives, but on a limited scale. Would they configure a DAV namespace adapter? I would think not. +1 Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Gary Poster gary at zope.com writes: On Feb 13, 2006, at 10:05 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote: [...] +1 to Stephan's comment, Tres' comment, and Tres' use of the word ukase (which I had to look up). It wasn't a spelling mistake? ... ukase \yoo-KAYS; -KAYZ; YOO-kays; -kayz\, noun: 1. In imperial Russia, a published proclamation or order having the force of law. 2. Any order or decree issued by an authority; an edict. -1 to the proposal. +1 to Gary's +1's and -1's. However, I think a review of namespace *usage* in Zope 3 at present is a good idea, as opposed to outlawing them entirely. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: snip I'm not arguing (here) against refactoring the namespaces in which core directives are declared. I'm arguing against the idea that namespaces are bad in general. I'm not arguing that either. I'm just saying that one namespace is sufficient. Not if you need to mangle names to avoid clashes. snip I don't really see the point in ZCML's using namespaces. What good do they provide? Seriously, is it just the prefix? Well, we don't need the namespaces for that. ZCML *must* support extensibility, and therefore must continue to allow packages to register their own namespaces (unless we abandon XML altogether). I don't see how that conclusion works. It seems like you think namespaces are needed for extensibility. They are not. We can add directives to existing namespaces just fine. I don't want to encourage third-party applications to inject their names into stock namespaces, because then I can't safely mix unrelated third-party packages without chasing down conflicts. XML Namespaces are useful for extending existing XML dialects with stuff from others. E.g. embedding SVG into HTML, adding TAL/METAL to HTML, and the like. The way ZCML uses namespaces isn't even half-way compatible with that. For example, I couldn't add inline-documentation to ZCML unless I configured no-op directives for my particular documentation elements, just so that the ZCML machinery wouldn't complain it encountered unknown directives. Why would it think that they are directives? I can add inline-documentation to XSL or, heck, OpenDocument just fine. ZCML wants to be XML but it's weird about it. I don't want DocBook in my ZCML, personally. De gustibus again. At the moment, ZCML does assume that all elements in a ZCML file belong to it. If you wanted to add DocBook to your ZCML, then you could add a meta.zcml file which registered faux handlers for the docbook elements; you might also add a directive to ZCML which instructed it to ignore all nodes from a given namespace. Otherwise, we give up the ability to check that a given directive can actually be interpreted at all, which would be a Bad Thing. Huh? Right now, ZCML does a syntax check on the files it processes, and barfs on elements it doesn't understand. I don't want to lose that check if the only benefit is the ability to inline foreign elements. Again, I wouldn't mind some syntax which told ZCML to ignore names from particular foreign namespaces. snip A lot of the feedback seemed to be along the lines of: - ZCML sux -- I won't use Zope3 until it is gone! They weren't gonna use it anyway. ... - Why do I have to declare the namespaces? (XML haters, for the most part; note that I am not an XML fanboy myself). I am *for* declaring XML namespaces. I'm against declaring too many pointless namespaces. Now we are getting close to 'de gustibus' territory. Your proposal seems to make a claim that we don't / won't need more than one namespace, while the ones we have are there because people were trying to avoid name clashes. There may be some which could be refactored away, but I don't think that is the same point the proposl si trying to make. - Why does the core use more than one namespace? This question seems legitimate to me: I think we wanted to allow non-mangled names for otherwise conflicting directives, e.g. 'browser:view' and 'xmlrpc:view'. Yes. Using namespaces for this is arbitrary, though. We could just as well have chosen different names, e.g. browserView and xmlRpcView. I don't think that was arbitrary all: we use namespaces *as they are designed* here, to allow people to use natural names for things without worrying whethere they clash with names which are equally natural in another domain. This is why Python has namespaces, too: import this ... Namespaces are one honking great idea -- let's do more of those! - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. This belongs in the other thread, really. But here it goes anyway: I'm not convinced that people who deploy apps will actually go as deep as editing package ZCML, or even overrides for that matter. I would rather imagine they turn ZCML features on or off (which would then turn on or off ZCML directives via zcml:condition) Nope. You are ignoring the cases which are currently done TTW in Zope2: mailhost configuration, for instance, or caching policies, etc. If an application wants to add a diretive which makes it possible to configure such policies
Re: [Zope3-dev] Re: One namespace for ZCML
On 2/13/06, Sidnei da Silva [EMAIL PROTECTED] wrote: Someone argued in the python-brasil list that let's do more of those actually refers to 'one honking great idea', thus meaning let's do more of those great ideas (like namespaces). This is the first time I've heard that interpretation. Now whether that's that's the correct interpretation is up to the original author (Tim Peters?) to clarify :) I don't know if he's paying attention to this thread, but I'm fairly certain everyone at PythonLabs understood that to refer to namespaces. If Tim would like to counter that, he's certainly free to do so, of course. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: One namespace for ZCML
Quick in-and-out from a lurker: yesterday as I was learning how to use Five with Plone, I thought to myself, wouldn't it be cool if there were two directives, cmf:installable and cmf:registerContentClass? This is from someone who's totally naive about zcml. Was this evil on my part? Because the debate seems to be about behaviors that are implicitly encouraged. Third-party packages which don't define new directives don't need their own namespaces. If, for instance, Plone adds a plone:view directive which is nothing more than a no-op wrapper around 'browser:view', that would be a Bad Thing (TM). If, however, they add a 'plone:frobnatz' directive which does something magical and outside the scope of the Zope core, and document how to use it when setting up Plone, that would be a Good Thing, especially if it kept people from changing site policy by customizing software. -- -J. Method ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
