[Zope3-dev] Re: ZCML bad ;-)
Shane Hathaway wrote: > Philipp von Weitershausen wrote: >> However, I think one namespace for ZCML is enough. > > +1 > > Shane +1 from me and +5 people around who completely stuck in ZCML -- Mikhail Kashkin, Key Solutions (http://keysolutions.ru/) Zope/Plone Consulting/Hosting/WebDev Plone на русском http://plone.org.ru/ Plone Foundation Member (http://plone.org/foundation/members/) ___ 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: ZCML bad ;-)
Chris Withers wrote: > (and if we can get it down to one, we don't have to specify it at the > top of the file... yay!) Not really. Specifying no namespace at all is not the same as specifying the namespace of prefix-less elements. Even with one namespace the declaration of that namespace is still useful from a semantic point of view, e.g. when mixing ZCML with other XML. For example, I could imagine to inline-document ZCML with additional DocBook tags. It's currenty not possible because the ZCML machinery expects every element to be a directive or subdirective. When all ZCML directives are part of a single namespace, though, other namespaces are free to be used for documentation, XInclude, etc. For that to work, though, the ZCML namespace should be defined explicitly, even if it's only one, to distinguish it explicitly from other stuff. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: ZCML bad ;-)
Shane Hathaway wrote: > Christian Lück wrote: > From a lerners point of view (for example me) the thematic organization >> >> is a pro too: The z3 beginner will probably need the 'zope' and >> 'browser' namespaces at first. Browsing apidoc zcml namespaces lets your >> knowledge grow fast, because you get structured information. > > > How do you reconcile this opinion with the opinion posted by Kevin? > > [Kevin Smith] > >> I think people are afraid to give ZCML anymore traction than it >> already has. I for one find it intimidating and confusing. Not so much >> because of its format, or api documentation, but because it is unclear >> what and how all the names and attributes interrelate. It's taken me two >> books, a bunch of samples, and alot of trial and error to get me to a >> very basic level. It seems easy now that I know what I know, but I >> thought Zope3 was going to have a flatter learning curve. I blame ZCML >> and whatever it might be hiding. :) > > > It sounds to me like the structure made ZCML difficult to learn. > > Shane > Yes, the complexity of z3 is overwelming in the beginning. And it's often still trial and error. But I won't blame the namespaces/syntax of zcml. I always liked to browse the namespace-divisions of apidoc in order to learn about alternatives and related things. I'm happy that information about rdb is blinded out when I'm aiming at views and vice versa. In fact, I do not know exactly what to blame for the learning curve. On the one hand the component concept is what made me turn to z3 and what makes me adhere. But on the other hand all this interfaces factories adapters views things cost me weeks, if not months. Huh, tests, they might be a suspect. Writing tests is about metaprogramming and I am totally lost in this forrest. The test passes, but the app fails on exceptions... Most of the documentation is doctests but IMO tests are the most difficult thing with z3. If I was called into the witness stand, I would probably blame the connex between tests and documentation. But, hey, in the affair, *I*'m having with Zope3 for five months now, the different namespaces/the syntax of zcml have never been a problem. Reconciliatio/Concordia opinionum? Impossible for this subject. We are deeling with very individual histories of learning here. - Sorry, my term 'example' may have been wrong. - You might assume a probability distribution and an average zope3 learner, but that is very different from reconciliatio of real learners. Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML bad ;-)
Chris Withers wrote: Gary Poster wrote: FWIW, me too. I'm no XML guru (as Fred will attest ;-) ) but reading the namespaces on an XML file seems like basic XML procedure. Well, the reading of them is the lesser of my two complaints... I find it irksome to have to type them at the top of ever file. How 'bout you started reading about this newfangled "copy/paste" feature of your text editor? Sheesh... Florent Is there no way that they could be pre-bound in the XML parser? That way you'd only need to inlcude them if you wanted to rebind them... -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +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
Re: [Zope3-dev] Re: ZCML bad ;-)
Christian Lück wrote: From a lerners point of view (for example me) the thematic organization is a pro too: The z3 beginner will probably need the 'zope' and 'browser' namespaces at first. Browsing apidoc zcml namespaces lets your knowledge grow fast, because you get structured information. How do you reconcile this opinion with the opinion posted by Kevin? [Kevin Smith] I think people are afraid to give ZCML anymore traction than it already has. I for one find it intimidating and confusing. Not so much because of its format, or api documentation, but because it is unclear what and how all the names and attributes interrelate. It's taken me two books, a bunch of samples, and alot of trial and error to get me to a very basic level. It seems easy now that I know what I know, but I thought Zope3 was going to have a flatter learning curve. I blame ZCML and whatever it might be hiding. :) It sounds to me like the structure made ZCML difficult to learn. Shane ___ 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: ZCML bad ;-)
Fred Drake wrote: Are you sure? Perhaps it's reasonable to use a single namespace for all the ZCML directives defined as part of the Zope 3 release. What about third-party directives? Are you saying we don't need to worry about introducing names that conflict with third-party names we don't know about? That sounds short-sighted to me. Yeah, I agree with that :-/ If we're using XML+Namespaces, we have to specify it, regardless of the number of namespaces used. *sigh* xml sucks ;-) ...which brings me back to my previous question: is there any way, preferably in emacs, to have these namespace declarations automatically inserted by the editor whenever I use them? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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: ZCML bad ;-)
Alexander Limi wrote: On Tue, 24 Jan 2006 11:10:29 -0800, Jeff Shell <[EMAIL PROTECTED]> wrote: It's like those damned imports in Python. Why can't everything just be available in one big honkin' namespace automatically? I believe you mis-spelled "acquisition". Acquisition is extensibility in many independently controlled dimensions with no conflict detection. No one suggested that. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML bad ;-)
On Tue, 24 Jan 2006 11:10:29 -0800, Jeff Shell <[EMAIL PROTECTED]> wrote: It's like those damned imports in Python. Why can't everything just be available in one big honkin' namespace automatically? I believe you mis-spelled "acquisition". *ducks* ;) -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: ZCML bad ;-)
Shane Hathaway wrote: > Fred Drake wrote: > >> On 1/24/06, Chris Withers <[EMAIL PROTECTED]> wrote: >> >>> Shane Hathaway wrote: >>> Philipp von Weitershausen wrote: > However, I think one namespace for ZCML is enough. >> >> >> >> Are you sure? >> >> Perhaps it's reasonable to use a single namespace for all the ZCML >> directives defined as part of the Zope 3 release. > > > Agreed. Let's just do that. > >> What about >> third-party directives? Are you saying we don't need to worry about >> introducing names that conflict with third-party names we don't know >> about? >> >> That sounds short-sighted to me. We've certainly defined several >> directives here at ZC, and I'd hate to have to push them all into Zope >> 3 itself just to ensure we don't end up with name conflicts in the >> future. > > > Separate namespaces for separate business entities makes sense to me. > What doesn't make sense to me is having separate namespaces for every > subsystem, which is too deep a hierarchy. > > Shane > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/christian.lueck%40ruhr-uni-bochum.de > > > >From my point of view as someone who is developping web applications with z3 the 'hierarchy' is a pro. Imagine two libraries: one with all the books in a alphabetical order, one with a thematic order. I would strongly prefer the latter one with the thematic order, which is more structured. >From a lerners point of view (for example me) the thematic organization is a pro too: The z3 beginner will probably need the 'zope' and 'browser' namespaces at first. Browsing apidoc zcml namespaces lets your knowledge grow fast, because you get structured information. BTW, I think it's a very flat hierarchy, because it is only three levels: namespace--element--attribute. That's not deep at all. I would rather use the term structure than hierarchy. Christian ___ 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: ZCML bad ;-)
On Jan 24, 2006, at 12:22 PM, Shane Hathaway wrote: Fred Drake wrote: On 1/24/06, Chris Withers <[EMAIL PROTECTED]> wrote: Shane Hathaway wrote: Philipp von Weitershausen wrote: However, I think one namespace for ZCML is enough. Are you sure? Perhaps it's reasonable to use a single namespace for all the ZCML directives defined as part of the Zope 3 release. Agreed. Let's just do that. ... Separate namespaces for separate business entities makes sense to me. What doesn't make sense to me is having separate namespaces for every subsystem, which is too deep a hierarchy. I would be OK with that. That seems like it's a reasonable compromise. 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: ZCML bad ;-)
Fred Drake wrote: On 1/24/06, Chris Withers <[EMAIL PROTECTED]> wrote: Shane Hathaway wrote: Philipp von Weitershausen wrote: However, I think one namespace for ZCML is enough. Are you sure? Perhaps it's reasonable to use a single namespace for all the ZCML directives defined as part of the Zope 3 release. Agreed. Let's just do that. What about third-party directives? Are you saying we don't need to worry about introducing names that conflict with third-party names we don't know about? That sounds short-sighted to me. We've certainly defined several directives here at ZC, and I'd hate to have to push them all into Zope 3 itself just to ensure we don't end up with name conflicts in the future. Separate namespaces for separate business entities makes sense to me. What doesn't make sense to me is having separate namespaces for every subsystem, which is too deep a hierarchy. Shane ___ 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: ZCML bad ;-)
On Tuesday 24 January 2006 11:29, Fred Drake wrote: > > >> However, I think one namespace for ZCML is enough. > > Are you sure? > > Perhaps it's reasonable to use a single namespace for all the ZCML > directives defined as part of the Zope 3 release. What about > third-party directives? Are you saying we don't need to worry about > introducing names that conflict with third-party names we don't know > about? > > That sounds short-sighted to me. We've certainly defined several > directives here at ZC, and I'd hate to have to push them all into Zope > 3 itself just to ensure we don't end up with name conflicts in the > future. +1. I agree with Fred. Also, I am refraining from commenting on this thread most of the time and wait for a real proposal to comment on. 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
Re: [Zope3-dev] Re: ZCML bad ;-)
That's a fair question. This is a pattern I have learned by using Docbook 5.0, which is another one of those _lets_rewrite_an_established_technology_to_address_longstanding_issues_ releases. Norm uses the RelaxNG annotations namespace[1]. I like the design principle RelaxNG uses for namespaces: "RELAX NG doesn't define specific elements and attributes reserved for annotations. Instead, RELAX NG opened its language. RELAX NG permits foreign attributesattributes from any namespace other than the RELAX NG namespaceto appear on all its elements"[2] Going back to my XSLT example, with XSLT I can easily pick out all elements with a given namespace or following a given pattern with *a single template match*. If you embedded the documentation using the mixed content schema as per your example below, I can still pick it out but it will be a bit more work. It will also be more brittle. If you add new deeply nested elements or whatnot.. you see my point. In general with each change to your schema I may have to go back and change my doco-generator xslt. With namespaces, you rarely if ever have to make changes. Perhaps the above is one of the reasons why namespaces are mentioned in the Python mantra... --Craeg [1] http://www.docbook.org/xml/5.0b2/rng/docbook.rng [2] http://books.xmlschemata.org/relaxng/relax-CHP-13-SECT-1.html > > > > foo > > > >The foo directive indicates that the bar setting should be wombat. > >This is important when... > > > > > > what are the advantages of that approach over something like this: > > > >foo > The foo directive indicates that the bar setting should be wombat. > This is important when... > > > > I.e. just intermingle prose with the ZCML. ___ 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: ZCML bad ;-)
[EMAIL PROTECTED] wrote: > I like generating documentation directly from source. > Namespaces provide a nice way to do that with XML files via XSLT, while > still enabling RelaxNG schema validation, etc. > > foo > >The foo directive indicates that the bar setting should be wombat. >This is important when... > > what are the advantages of that approach over something like this: foo The foo directive indicates that the bar setting should be wombat. This is important when... I.e. just intermingle prose with the ZCML. -- Benji York Senior Software Engineer Zope Corporation ___ 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: ZCML bad ;-)
On 1/24/06, Chris Withers <[EMAIL PROTECTED]> wrote: > Shane Hathaway wrote: > > Philipp von Weitershausen wrote: > > > >> However, I think one namespace for ZCML is enough. Are you sure? Perhaps it's reasonable to use a single namespace for all the ZCML directives defined as part of the Zope 3 release. What about third-party directives? Are you saying we don't need to worry about introducing names that conflict with third-party names we don't know about? That sounds short-sighted to me. We've certainly defined several directives here at ZC, and I'd hate to have to push them all into Zope 3 itself just to ensure we don't end up with name conflicts in the future. > (and if we can get it down to one, we don't have to specify it at the > top of the file... yay!) If we're using XML+Namespaces, we have to specify it, regardless of the number of namespaces used. -Fred -- Fred L. Drake, Jr. "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: ZCML bad ;-)
> Shane Hathaway wrote: >> Philipp von Weitershausen wrote: >> >>> However, I think one namespace for ZCML is enough. >> >> +1 Big +1 to all of Philipp's suggestions. I have a fair amount of experience with Zope2 and am learning Zope3...but with half an eye at Ruby on Rails and Spring/Hibernate. I want to build business objects in Python but build my GUIs using XML, XSLT and AJAX technologies that will work on *any* backend platform or language. I like generating documentation directly from source. Namespaces provide a nice way to do that with XML files via XSLT, while still enabling RelaxNG schema validation, etc. For example, you could embed textual annotations using a different namespace that should be ignored by ZCML machinery, e.g. foo The foo directive indicates that the bar setting should be wombat. This is important when... NOTE: if you make the ZCML namespace the default, then the above would simply be: foo The foo directive indicates that the bar setting should be wombat. This is important when... IMHO, We *must* make Zope3 a good XML citizen or stand to lose developers to competing platforms. OTOH, using more than one namespace for ZCML itself seems silly. my 2c, --Craeg ___ 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: ZCML bad ;-)
Shane Hathaway wrote: Philipp von Weitershausen wrote: However, I think one namespace for ZCML is enough. +1 +1 ;-) (and if we can get it down to one, we don't have to specify it at the top of the file... yay!) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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: ZCML bad ;-)
Philipp von Weitershausen wrote: However, I think one namespace for ZCML is enough. +1 Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML bad ;-)
Fred Drake wrote: >>I find it irksome to have to type them at the top of ever file. Is there >>no way that they could be pre-bound in the XML parser? That way you'd >>only need to inlcude them if you wanted to rebind them... > > Even if we could avoid it at a technical level, it means that what > we're reading is no longer XML. One of the desires with ZCML was to > not invent everything from scratch. So, *if* we're using XML, we need > to use it as defined, otherwise it *isn't* XML. We're shying away > from what's invented here in favor of what's been developed in a > broader community. > > An alternate syntax could of course do things differently, but > introducing an alternate syntax just means there's more than one way > to do it. That's usually a bad idea. Philipp's proposal cuts more to > the heart of the problems with ZCML, and they aren't syntax-specific. Indeed. Also, I think that with less ZCML directives in the future (I'd like to see their number cut in half or so) ZCML namespaces won't be as necessary as they are now. Actually, I find the different ZCML namespaces not really useful anymore, especially when a browser page is not something special from a registration point of view but instead just another view or even just another adapter with security declarations. I like XML and I like the fact that ZCML uses XML. I'm also a big fan of explicit namespace declarations. I want them for ZPT, for example. However, I think one namespace for ZCML is enough. That should also save some dead chickens in the future (re ChrisW). 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: ZCML bad ;-)
Shane Hathaway wrote: FWIW, I still hate ZCML for the following reasons: Everyone seems to agree on the direction suggested here: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less Indeed, while I strongly agree with all of this, I think it's orthagonal to the point I was trying to make... There's only one thing that bothers me about that article: it calls the people who complain about ZCML either "Python purists" or "die-hard Zope 2 coders", when you and I are neither. Indeed ;-) My view comes purely from requiring the number of languages that need to be known to use Zope be as few as possible to make things easier on us all... We are Zope evangelists, and our concern is that the current ZCML is a significant barrier for others who want to learn and adopt Zope. Yup :-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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: ZCML bad ;-)
Paul Winkler wrote: On Sun, Jan 22, 2006 at 10:58:43AM -0500, Jim Fulton wrote: Jeff Shell wrote: But I'm really starting to get frustrated with a lot of the elements in the ZCML browser: namespace. (snip) To a large extent, they were failed experiments. Just stop using them. Eek. How do those of us who are still neophytes recognize which browser: directives are failed experiments? Is there anything in the browser: namespace we *should* use? I count 18 in Philip's book which I just got. For now, you should keep folloing the book. Over time, we will learn which approaches work and which don't and we'll change the way we work in response. It will take time to update documentation. Don't sweat it. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: ZCML bad ;-)
Paul Winkler wrote: To a large extent, they were failed experiments. Just stop using them. Eek. How do those of us who are still neophytes recognize which browser: directives are failed experiments? Is there anything in the browser: namespace we *should* use? I count 18 in Philip's book which I just got. I echo these sentiments: which ones should go away? what should we use instead? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML bad ;-)
Jim Fulton wrote: > Perhaps we should start actively deprecating many ZCML directives? > This will require some volunteer effort to do it well. I hereby volunteer. :) 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: ZCML bad ;-)
On Sun, Jan 22, 2006 at 10:58:43AM -0500, Jim Fulton wrote: > Jeff Shell wrote: > >But I'm really starting to get frustrated with a lot of the elements > >in the ZCML browser: namespace. (snip) > > To a large extent, they were failed experiments. Just stop using them. Eek. How do those of us who are still neophytes recognize which browser: directives are failed experiments? Is there anything in the browser: namespace we *should* use? I count 18 in Philip's book which I just got. > > Menus are best understoood as a pattern! > I'd like to see this somewhere in the z3 wiki on zope.org, but I don't see an obvious good place to put it. Somewhere under User Documentation? -- Paul Winkler http://www.slinkp.com ___ 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: ZCML bad ;-)
Jim Fulton wrote: Perhaps we should start actively deprecating many ZCML directives? This will require some volunteer effort to do it well. +1 on selective deprecation, -1 on me volunteering :) -- Benji York Senior Software Engineer Zope Corporation ___ 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: ZCML bad ;-)
Jeff Shell wrote:
On 1/20/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
Chris Withers wrote:
FWIW, I still hate ZCML for the following reasons:
Everyone seems to agree on the direction suggested here:
http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less
I think that will resolve a lot of concerns.
...
But I'm really starting to get frustrated with a lot of the elements
in the ZCML browser: namespace. They do a lot behind the scenes and
maybe that's a good thing for new users to minimize the amount of code
they have to write or provide, but it gets frustrating (at least, it
has for me) when you start growing up beyond that.
To a large extent, they were failed experiments. Just stop using them.
Maybe the big base-class-mess of Zope 2 made it desirable to not even
require a base class for a Zope 3 view?
No, that was not the motivation.
> Some of those viewmeta
directives are doing a lot of crazy dynamic class and method creation
to provide IBrowserPublish, traversal to the default view, or
rendering a certain attribute or template automatically as the
default. As I was starting to use Zope 3 in earnest, I wouldn't
understand when I should use browser:page versus browser:view, and if
I did browser:page with both a template and a class if there was any
way I could refer to the template from the class's methods since the
template was stitched in by ZCML.
The management of templates was the reason we had to go down this road.
Some influential early Zope 3 reviewers (who will remain nameless to
protect their reputations :) complained that they didn't like to muck
up their Python code with template definitions. They didn't like
seeing things like:
foo = ViwPageTemplateFile("foo.pt")
in their Python code and prefered to relegate those definitions to
ZCML. This was the origin of the page directives. In retrospect,
it was a mistake.
The fact that we have both view and page had to do with an early
concept, multi-page-views that also hasn't terned out to remain useful.
Again, I'd be happy to see these directives fade from use.
Even though I've made a pro-ZCML case on the basis that most of the
directives and their attributes are reasonably well documented, what
the directives DO is another matter entirely. In theory, registering a
view is equivalent to zope.component.provideAdapter((ISomeObj,
ISomeSkinLayerOrRequest), provides, name). But the directives do so
much more than that. So while I'm often trying to stick with apidoc
for reference, I'm always going into Zope to see how things really
work and usually to ensure that I'm really doing things correctly. And
looking at some of the metaconfigure code is... Well, it's rough.
There's something defined in zope.app.publisher.browser.menumeta for
menuitems called 'extra'. I've been struggling to find out if I can
add things to menu items to render out like javascript onclick
handlers. And I mean s-t-r-u-g-g-l-i-n-g. I finally find this 'extra'
thing. It's not defined in any schema interface. What is it? What form
does it take? It's in the argument list in the directive handlers, but
not in the metadirective's schema. Should I write my own menu system?
This is a very good example.
I like being able to declare menus in ZCML - keeps their order easy to
control. But I don't want to be writing javascript handlers in it. I
don't want to be writing new directives. I've been crawling through
this code all morning. It's very convenient until you can't do what
you want... So then the issue becomes "should I just do it in Python?
Yup.
Is there a way I can do it but still have it all work out nicely at
configuration time?
I think so.
> I'm guessing there is if I write a custom
IBrowserMenu utility and write my own way of providing menus to it..."
...
Menus are an idea that, like the rest of the component architecture, has evolved
and simplified over time.
Menus are best understoood as a pattern!
The pattern goes like this: A menu us just a collection of
named components that provide some interface. The menu is the
menu item type. To define a new menu, define a new type.
To make the menu items context sensitive, look up the menu
items as adapters. (Well, you typically do that anyway, since
menu items generally adapt at least the request.) How you
display or order the items is up to you.
That's it. Simple. For our applications, we often create
mini menu frameworks to meet specialized needs. The existing
menu interfaces, including the ZCML directives implement this
simple pattern. Sadly, things designed to make things simpler
often take simple ideas and make them complex. :) The original
menu framework didn't implement this pattern, but was retrofitted
to do so.
If you want to define menus or menu items in Python, go ahead.
Just define interfaces and adapters and register the adapters
in ZCML.
I like th
Re: [Zope3-dev] Re: ZCML bad ;-)
On 1/20/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Chris Withers wrote: > > FWIW, I still hate ZCML for the following reasons: > > Everyone seems to agree on the direction suggested here: > > http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less > > I think that will resolve a lot of concerns. I very much agree with that, and have been working a lot to start using those styles where I can. I like using that for the adapters especially, and now I'm designing and writing more adapters because it is so much easier now to just write:: and not freak out over all of the ZCML options and which ones I really should be providing. And then when I look at the python code, it's much nicer to see all of the base classes, implements, and adapts statements right there. When I revisit the code a couple of months down the line, there's just more contextual information immediately available. I'll still heavily defend ZCML to an extent. I've written before about how I've tried to do component-architecture-lite systems in Zope 2 in the past, and doing a lot of the registration bits in Python cleanly was just hard. No project of mine has ever done it quite the same way. I definitely like the "on/off" feature of ZCML. In moderate to large systems, it's nice to know when and how components are loaded and registered. ZCML removes the mystery from that, and I love that - I think it's critical, in fact, if Zope 3 is going to show off / succeed as an integration platform. Being able to use code from a third party package without having any side effects of spurious and unwanted component registration is nice, as is being able to provide alternate registrations for what that package provides. But I'm really starting to get frustrated with a lot of the elements in the ZCML browser: namespace. They do a lot behind the scenes and maybe that's a good thing for new users to minimize the amount of code they have to write or provide, but it gets frustrating (at least, it has for me) when you start growing up beyond that. Maybe the big base-class-mess of Zope 2 made it desirable to not even require a base class for a Zope 3 view? Some of those viewmeta directives are doing a lot of crazy dynamic class and method creation to provide IBrowserPublish, traversal to the default view, or rendering a certain attribute or template automatically as the default. As I was starting to use Zope 3 in earnest, I wouldn't understand when I should use browser:page versus browser:view, and if I did browser:page with both a template and a class if there was any way I could refer to the template from the class's methods since the template was stitched in by ZCML. Even though I've made a pro-ZCML case on the basis that most of the directives and their attributes are reasonably well documented, what the directives DO is another matter entirely. In theory, registering a view is equivalent to zope.component.provideAdapter((ISomeObj, ISomeSkinLayerOrRequest), provides, name). But the directives do so much more than that. So while I'm often trying to stick with apidoc for reference, I'm always going into Zope to see how things really work and usually to ensure that I'm really doing things correctly. And looking at some of the metaconfigure code is... Well, it's rough. There's something defined in zope.app.publisher.browser.menumeta for menuitems called 'extra'. I've been struggling to find out if I can add things to menu items to render out like javascript onclick handlers. And I mean s-t-r-u-g-g-l-i-n-g. I finally find this 'extra' thing. It's not defined in any schema interface. What is it? What form does it take? It's in the argument list in the directive handlers, but not in the metadirective's schema. Should I write my own menu system? I like being able to declare menus in ZCML - keeps their order easy to control. But I don't want to be writing javascript handlers in it. I don't want to be writing new directives. I've been crawling through this code all morning. It's very convenient until you can't do what you want... So then the issue becomes "should I just do it in Python? Is there a way I can do it but still have it all work out nicely at configuration time? I'm guessing there is if I write a custom IBrowserMenu utility and write my own way of providing menus to it..." The documentation about the IBrowserMenu interface is there, the menu items too. But there's no clear path to translating ZCML like this:: into a custom IBrowserMenu utility that explicitly just lists these menus or implicitly finds them by looking for an adapter I write that does... stuff. And the feeling I get here is kindof like the feeling I assume people get in Zope 2 when they try to grow beyond a certain point. Up to here, the system provides you with some nice and easy tools to do _. You can do _ your own way and make it better if you just do this: (pulls out new programming paradigm). I like the approach t
[Zope3-dev] Re: ZCML bad ;-)
On Fri, 20 Jan 2006 14:54:55 -, Shane Hathaway <[EMAIL PROTECTED]> wrote: Chris Withers wrote: FWIW, I still hate ZCML for the following reasons: Everyone seems to agree on the direction suggested here: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less I think that will resolve a lot of concerns. +1 There's only one thing that bothers me about that article: it calls the people who complain about ZCML either "Python purists" or "die-hard Zope 2 coders", when you and I are neither. We are Zope evangelists, and our concern is that the current ZCML is a significant barrier for others who want to learn and adopt Zope. Heh... I happen to know Philipp agrees with you there :) Martin (and current ZCML confuses me too) -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML bad ;-)
Chris Withers wrote: FWIW, I still hate ZCML for the following reasons: Everyone seems to agree on the direction suggested here: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less I think that will resolve a lot of concerns. There's only one thing that bothers me about that article: it calls the people who complain about ZCML either "Python purists" or "die-hard Zope 2 coders", when you and I are neither. We are Zope evangelists, and our concern is that the current ZCML is a significant barrier for others who want to learn and adopt Zope. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
