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: RFC: ZConfig and other formats for ZCML
Andreas Jung wrote: --On 23. Januar 2006 15:22:27 -0500 Andrew Sawyers [EMAIL PROTECTED] wrote: On Mon, 2006-01-23 at 18:51 +0100, Andreas Jung wrote: This separation is artificial. I've never seen a single Zope installation where a system administrator had to care about Zope configuration issue. There was always a Zope developer in charge to deal with configuration issues. Those of us developers who have been in this case might not like that to always be the case. :) I'd like to live in a perfect World also. Depends on the ratio developers : sysadmins. If it is 50:50 them the separation is ok. IMO it is 80:20 :-) But that's only my personal estimate. -aj For us working in large organisations (and here I am bluntly assuming that using Zope in large organisations is OK, if you guys don't mind) then this kind of statment makes no sense. Sure, perhaps you guys never have experienced a situation where there are 2-4 developers and 10-12 sysadmins, however that does not mean that your own (in this sense limited) personal experience constitutes some kind of universal truth. In large organisations where deployment is actually a big deal, then the developers are far fewer than the sysadmins, and there are logistical and resource problems atteched to forcing the developers become an essential part of the on-going sysadmining tasks. Developers are a scarse resource and need to be foucused oin developing things. Sysadmins need to allowed to have a low entry barrier to Zope system administration. My humble 0.02 € /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. Lyrics applied to programming application design: emancipate yourself from mental slavery - redemption song, b. marley ___ 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: RFC: ZConfig and other formats for ZCML
Andrew Sawyers wrote: 1. On Mon, 2006-01-23 at 18:29 +0100, Martijn Faassen wrote: [snip] And the intended audience of ZCML is a very different audience - developers versus sysadmins. I'd have to say, I belived quite the opposite. There are specific references to Admins being part of the ZCML audience. See specifically http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book/zcml.html which says: 1. While the developer is certainly the one that writes the initial cut of the configuration, this user is not the real target audience. Once the product is written, you would expect a system administrator to interact much more frequently with the configuration, adding and removing functionality or adjust the configuration of the server setup. System administrators are often not developers, so that it would be unfortunate to write the configuration in the programming language, here Python. But an administrator is familiar with configuration scripts, shell code and XML to some extend. Therefore an easy to read syntax that is similar to other configuration files is of advantage. Let's just say that I don't think ZCML is there yet... While I can believe a sysadmin can make changes in ZCML configuration on the specific advice of a developer, and in some other specific instances, I don't think ZCML in general is very transparant for sysadmins at all, and perhaps it shouldn't be. I do believe there's value in even the specific, limited instances of non-developers making changes in ZCML however, and also believe the situation is better than when you'd have to tell a sysadmin to go change some Python code. I would argue that the apache config is comparable to Zope 3's ZCML - in that, if I wanted to enable/disable some feature typically included with Apache, say CGI support - this is done in Apache's config files. Granted I understand there are some differences, but it is worthy to note that there is some cross-over between Apache's configuration file audiences and Zope 3's ZCML files and ZConfig (zope.conf). I've worked with both ZCML and the Apache configuration language, and while I agree there is some overlap, ZCML is generally not about enabling/disabling features in my experience. ZCML as it stands is very much tied to application design, and a sysadmin can very easily break something fundamental by messing with it (imagine changing the name of a view, for instance). In contract, of course a sysadmin can break the Apache configuration too, but generally no specific detail of an application is broken in that case. *all* URLs to an application may change, but typically not a single one. So, I consider ZCML to be about application configuration, and Apache configuration to be about general server configuration. There are overlaps and grey areas, but the domains are quite distinct. More importantly to me (being one who is pushing Zope 3 in the Enterprise and recently supplying a summary of the online ZCML data to my fellow developers), what is the 'official' position if the Zope3 book on zope.org is wrong or who says it's wrong and why the change in positions? This occurred to me when Stephan recently said something similar, but I'd forgotten where I had read otherwise. I can't give you an official position. Instead, I'll go into some vague thoughts from me about ZCML: After working extensively with ZCML in large applications, and seeing ZCML as a special kind of declarative programming logic, I have started to wonder about the reusability of ZCML. Zope 3 is good at the reuse of smaller grained components than Zope 2, but I noticed that when I *want* a larger component (including UI and the rest), a whole lot of ZCML will need to come along and quite possibly be adjusted for particular applications. Perhaps snippets of ZCML can be made to be more reusable somehow... It *may* be that this eventually leads to a world where it becomes easier to turn off specific features of an application through ZCML. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: ZConfig and other formats for ZCML
Fred Drake wrote: On 1/21/06, Jim Fulton [EMAIL PROTECTED] wrote: are really attributes of foo. In ZCML, this might have been: foo x=1 y=2 / Except this breaks down in the case of ZConfig multikey elements, which allow configuration like this: foo x = 1 x = 2 y = 3 /foo Yes, but both ZCML and TAL already deal with these kinds of cases, in fact, they do so quite clunkilly some might say ;-) foo x=1 2 y=3 / tal:attributes anyone? ;-) There are also ways to arrange configuration like this: search-path directory1 directory2 directory3 /search-path Well, you know, XML does allow for elements to have contents ;-) ZCML should grow the ability to support elements having content, IMNSHO... 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: RFC: ZConfig and other formats for ZCML
Martin Aspeli wrote: No, I heard you the first time. But whilst zope.conf has been around for ages, it has not been used for the purpose that ZCML is now used. Really? I thought ZCML was used for configuration of a web application/server. .conf has been used exactly that with Apache for a long long time, and for Zope, just a long time ;-) The kind of thing people do with ZCML are an order of magnitude more complex than the things people do in zope.conf. Really? Ever written Apache rewrite rules? What is true is that there are now two books in print and a growing body of documentation that explains ZCML. If you're suggesting that Zope deprecates ZCML and starts using ZConfig for component wiring, you're going to turn that documentation from useful to confusing, We're talking about some pretty minimal differences... browser:addMenuItem title=Posting class=.posting.Posting permission=zope.ManageContent view=AddPosting.html / require permission=zope.ManageContent names=title body / Becomes: browser:addMenuItem title Posting class .posting.Posting permission zope.ManageContent viewAddPosting.html /browser:addMenuItem require permission zope.ManageContent nametitle namebody /require and you're going to alienate a few more developers (and honestly, Zope 3 doesn't yet have that many to alienate). This hasn't stopped big changes in Zope 3 so far, and I kinda like that... to find out if they want to bet on it for their next big development project, it doesn't exactly inspire confidence, does it? And for what reason? Because you don't personally like the aesthetics of XML? Actually, because I want to lower barriers to entry. Apache is the most prevelant web server on the planet. It uses .conf format. Zope also uses .conf format, and has done for years. Zope 3 then introduced ZCML, which no other web server on the planet uses ;-) So no, this is NOT just about the aesthetics of XML... 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: RFC: ZConfig and other formats for ZCML
Martin Aspeli wrote: Except ZConfig on/off switches are very easy to understand just by reading the zope.conf file. That doesn't mean that same syntax would make managing something as complex as the type of wiring ZCML is currently used for any clearer, though. No, but that's the realm of Philipp's proposal, not Jim's ;-) I'd be in favour of switching zope.conf to an XML-based format as well, personally. Well, I'd prefer this to having two config file formats, but I'd prefer it less that using .conf for both ;-) Commercial development tools typically have pretty decent XML support, and if you were to write e.g. a ZCML editor as an Eclipse plug in, being able to rely on existing XML components would be much easier. Developers familiar with J2EE, .NET etc. are used to XML configuration files, and have editors and tools they are comfortable with. Being able to use those same tools (oh, it's just XML) may ease the learning curve a little. Also, I assume there's a DTD or XML Schema for the ZCML syntax, which would let such tools validate and auto-complete ZCML syntax - a valuable way to save time if you're not intimately familiar with the syntax. While I agree with all of this, I've never seen anyone actually do this for anything Zope-related so far. ZPT is a prime example where this was touted as a good reason to go for an XML-based attribute language, but no-one ever developed these tools. As such, I'm tempted to cry yagni on XML-because-its-easier-for-tools... 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: RFC: ZConfig and other formats for ZCML
Max M wrote: Personally I abhor these configuration languages. I can never figure out what all the options are, and I allways suspect that I am missing something clever in some undocumented cornercase somewhere. Well, ZCML is already self documenting, as far as I can see. Zope.conf would also likely be self documenting is Jim's proposal is implemented... 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: RFC: ZConfig and other formats for ZCML
On Tue, Jan 24, 2006 at 10:13:33AM +, Chris Withers wrote: | Zope 3 then introduced ZCML, which | no other web server on the planet uses ;-) I think you are mistaken. If ZCML is a variant of XML, then Zope 3 is not alone. I've been told that IIS 7 does use XML for it's configuration. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.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: RFC: ZConfig and other formats for ZCML
Martijn Faassen wrote: Sure, but it's not my point. I don't think sysadmins, familiar with Apache configuration syntax, are the audience for ZCML. Developers are. Therefore, an important benefit of ZConfig syntax, familiarity from Apache, goes away in case of ZCML. Well, I can only speak for myself, but as a developer, I'm more familiar with .conf format and prefer it over xml for this kind of configuration... While many developers may be familiar with Apache config syntax, not all are, and a random developer is more likely to be familiar with XML anyway. ...hmm, not sure I agree, don't have any evidence either way though :-/ 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] ZCML bad ;-)
Stephan Richter wrote: I'll note that I commonly make browser the default namespace in browser packages. And _I'll_ note that it's one of the things in your book that threw me... I had to do a double take to figure out where all these new directives had come from when I eventually noticed the rebound namespace at the top of the file... 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] ZCML bad ;-)
On 1/24/06, Chris Withers [EMAIL PROTECTED] 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. -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
[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: Philipp von Weitershausen wrote: However, I think one namespace for ZCML is enough. +1 Big +1 to all of Philipp's suggestions. context 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. /context 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. z:directive z:namefoo/z:name a:documentation The foo directive indicates that the bar setting should be wombat. This is important when... /a:documentation /z:directive NOTE: if you make the ZCML namespace the default, then the above would simply be: directive namefoo/name a:documentation The foo directive indicates that the bar setting should be wombat. This is important when... /a:documentation /directive 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 ;-)
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.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
[Zope3-dev] zope.schema: defaults for non-immutables... questions
It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) But if a Foo is not immutable this doesnt make sense. (In my case, I want a to be a collection providing IFoo, which defaults to an empty collection. Each Bar implementing IBar should have its own instance of Foo.) A proposal to remedy: if the default is a callable object, it is assumed to be a factory. How does this sound? (This would apply to missing_value as well.) A few further questions: 1) who should be responsible for setting defaults, and how should it be done? I have a base class from which I derive (e.g.) Bar, whose constructor loops through fields of interfaces provided by the instance: for iface in zope.interface.providedBy( self ): for fname, field in zope.schema.getFields( iface ).iteritems(): It checks default missing_value, and sets them. However, if one field shadows another in the interfaces, there is no guarantee that I hit them in the right order. Might it not be good to have a attributesProvidedBy( instance ) in zope.interface that guarantees that it passes back the most derived versions (and resolves consistently when there is no most derived )? Also, currently, when something doesnt have a definition, and is not required, I check first for default then for missing_value, and use the first I find as a missing value. Is this correct? How should default and missing_value interact with each other? What makes most sense to me is: (pseudocode): If not specified: If default defined Use default Else If required Raise error Else If missing value defined Use missing value Else Raise error Finally, a missing missing_value eventually gets None in the current Field constructor. Shouldnt it be left undefined when it wasnt specified? (Same for default.) - Shaun ___ 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. context 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] /context 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 z:directive z:namefoo/z:name a:documentation The foo directive indicates that the bar setting should be wombat. This is important when... /a:documentation /z:directive what are the advantages of that approach over something like this: z:directive z:namefoo/z:name The foo directive indicates that the bar setting should be wombat. This is important when... /z:directive 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] zope.schema: defaults for non-immutables... questions
Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: Mutable is a better way to say non-immutable. :-) class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) But if a “Foo” is not immutable this doesn’t make sense. (In my case, I want “a” to be a collection providing IFoo, which defaults to an empty collection. Each Bar implementing IBar should have its own instance of Foo.) I've run into this myself. How about: a = Object(schema=IFoo, default_factory=Foo) ? 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 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] ZCML bad ;-)
On 1/24/06, Chris Withers [EMAIL PROTECTED] 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. 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... It's like those damned imports in Python. Why can't everything just be available in one big honkin' namespace automatically? ;-) Seriously - it's not that bad. ZCML's use of namespaces is judicious, I believe. There's no namespaced attributes - just the directives. I too use browser: as the default namespace in my browser focused ZCML files. There's only one or two things to type, ever. The namespaces are easy to remember. I can't believe it's a big deal at all. It's certainly a case of 'explicit is better than implicit', I believe. Like with Python code and modules and avoidance of import *, it makes all names easily traceable. Are you using an editor that makes it difficult to go to the top of the file to check on the names? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] zope.schema: defaults for non-immutables... questions
Shane, I considered 'default_factory' myself It seems good, but it complicates the logic internally. For one thing, logically, we'd have to also have 'missing_value_default' (unless we decree that missing values have to be not-non-immutable, ah... immutable). A further thought on where to put filling in of defaults code -- this should probably be a separate routine in zope.schema: setDefaults(instance), which would set defaults (and validate? -- or maybe call it setDefaultsAndValidate). - Shaun PS anyone have idea or best practice on how to best through attributes, avoiding shadowed ones? Seems like this is generally useful for introspection of metadata. -Original Message- From: Shane Hathaway [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 12:39 PM To: Shaun Cutts Cc: zope3-dev@zope.org Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: Mutable is a better way to say non-immutable. :-) class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) But if a Foo is not immutable this doesn't make sense. (In my case, I want a to be a collection providing IFoo, which defaults to an empty collection. Each Bar implementing IBar should have its own instance of Foo.) I've run into this myself. How about: a = Object(schema=IFoo, default_factory=Foo) ? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] doctest: Get type of object
Hello, I'm currently writing a test in a README.txt and I want to make sure that returned object a is of type zope.app.x. How can I test that? Thanks, Florian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: ZConfig and other formats for ZCML
Jim Fulton wrote: Martijn Faassen wrote: Shane Hathaway wrote: Jim Fulton wrote: See: http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML Comments and volunteers welcome. I like this proposal. It is likely to reduce the total amount of code. However, I want to be sure that consolidating engines is the real focus of the proposal. Converting XML files to ZConfig format doesn't seem like an interesting change. If you don't convert your ZCML files to ZConfig format, you'll have to support the ZCML reader as well, so I think it'd lead to more code unless such a thing were done. Huh? Geez, my proposal must have been really unclear. I'm not proposing replacing ZCML files with ZConfig files. I'm proposing leveraging the ZCML engine and especially the system for extensibility for handling ZConfig files. This would require some new code, but would reduce the amount of code overall. It would also reduce the number of configuration-file extension mechanisms needed. Finally, it would make it a lot easier to extend ZConfig file handling. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.comhttp://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/lists%40nabble.com 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. :) Kevin Smith View this message in context: Re: RFC: ZConfig and other formats for ZCML Sent from the Zope3 - dev forum at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re: RFC: ZConfig and other formats for ZCML
On Tue, 24 Jan 2006 10:16:13 -, Chris Withers [EMAIL PROTECTED] wrote: Commercial development tools typically have pretty decent XML support, and if you were to write e.g. a ZCML editor as an Eclipse plug in, being able to rely on existing XML components would be much easier. Developers familiar with J2EE, .NET etc. are used to XML configuration files, and have editors and tools they are comfortable with. Being able to use those same tools (oh, it's just XML) may ease the learning curve a little. Also, I assume there's a DTD or XML Schema for the ZCML syntax, which would let such tools validate and auto-complete ZCML syntax - a valuable way to save time if you're not intimately familiar with the syntax. While I agree with all of this, I've never seen anyone actually do this for anything Zope-related so far. ZPT is a prime example where this was touted as a good reason to go for an XML-based attribute language, but no-one ever developed these tools. As such, I'm tempted to cry yagni on XML-because-its-easier-for-tools... With a valid DTD or XML Schema (which is easily produced; I would've thought one already existed for ZCML, if not, it's a strange omission), any serious XML tool will be able to validate and sanity-check your ZCML files. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: ZConfig and other formats for ZCML
Martijn Faassen wrote at 2006-1-23 18:27 +0100: ... For one, ZConfig is a syntax not very well known, even granting its similarity to the Apache configuration language, while XML is very well known. Come on: The only syntactic part of ZConfig is: there are keys with values and sections (which may contain subsections and keys with values). This is almost identical to the syntactic part of XML: the keys correspond to attributes and the sections to elements. In both cases, the difficult parts do *NOT* lie in *SYNTAX* (which is trivial in both cases). The difficult parts lie in the available sections/elements with their keys/attributes and subsections/subelements and what this all means (i.e. their semantics)... What I like with ZConfig is its schemas and especially the ability to define datatypes. I hope that similar things can be achieved with ZCML. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: ZConfig and other formats for ZCML
Fred Drake wrote at 2006-1-23 09:56 -0500: On 1/23/06, Chris Withers [EMAIL PROTECTED] wrote: As I said earlier, I think XML is wrong for configuration for exactly this kind of reason... element-based is right for this type of config, it's why Apache uses, it's why Zope 2 uses it, and it's why Zope 3 uses it for the .conf file... There are no elements in the ZConfig configuration language. Sections, yes, but as has been noted, those don't trivially map to XML elements. Really? What prevents you to map ZCML elements to ZConfig sections and their attributes to ZConfig keys? Only for #PCDATA, there is not equivalent in ZConfig. But, almost surely, ZCML does not use #PCDATA... I have the feeling that mapping ZCML syntax onto ZConfig syntax is easier than the other way round (as ZConfig supports multikeys but XML allows only a single attribute of a given name). -- Dieter ___ 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] doctest: Get type of object
Am Dienstag, 24. Januar 2006 21:07 schrieb Florian Lindner: Hello, I'm currently writing a test in a README.txt and I want to make sure that returned object a is of type zope.app.x. How can I test that? I've tried: Failed example: homeFolder #doctest: +ELLIPSIS Expected: zope.app.file.file.File object at ... Got nothing I've also tried it without the #doctest Why do I get just nothing? Thanks, Florian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] doctest: Get type of object
[Florian Lindner] I've tried: Failed example: homeFolder #doctest: +ELLIPSIS Expected: zope.app.file.file.File object at ... Got nothing I've also tried it without the #doctest Why do I get just nothing? That's expected if (and only if) `homeFolder` is bound to `None`. What happens if you change the line to: print homeFolder #doctest: +ELLIPSIS ? That added print at the front, and will display: None if homeFolder is in fact bound to None. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Deploying WSGI Apps with Zope 3.2+
Sidnei da Silva wrote: Hello, I'm refactoring a application developed for Zope 3.0, and in the proccess of doing that, one of the things I wanted to do is to remove some hardcoded xslt pipeline and instead use a WSGI 'middleware' or 'filter'. Cool So.. I was planning to use paste.deploy to put this together. However it seems like currently I would have to define a different IServerType utility just to hook up a different WSGI application up to Zope 3. Has anyone put some thought about how to do this? A little. Ideally, I would like to see the WSGI application to be used to be given as a parameter to the server directive of zope.conf, maybe that does deserve a new wsgi-server directive. Any thoughts? I think that the way the server and app are integrated needs to be rethought. I think we need to look at how to leverage Paste Deploy in Zope. I hate to mention this with all of the discussion about ZConfig, but we should probably consider using PasteDeploy as an alternative to ZConfig. (Jim ducks.) Alternative, we should redo the Zope 3 ZConfig schema to work with the Paste Deploy APIs. Obviously, if we do the later, I'd prefer to do so after we've decided how we're going to reimplement ZConfig. In the short term, you might try teasing out the app and server from Zope and see if you could wire them up with Paste Deploy. 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
[Zope3-dev] Re: RFC: ZConfig and other formats for ZCML
Dieter Maurer wrote: What I like with ZConfig is its schemas and especially the ability to define datatypes. I hope that similar things can be achieved with ZCML. Of course it can, ZCML is defined in terms of Zope 3 schemas. Florent -- 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
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
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
