Re: [Zope3-dev] what is ZCML?
On 3/14/06, Sidnei da Silva [EMAIL PROTECTED] wrote: That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] what is ZCML?
OK, I just think I had a sort of brainwave-thingy, so I'm going to lay it out here to see if it was a good brainwave or not: Currently I can see three useful uses of ZCML: 1. User interface configurations, that is, everything that goes under browser. Menus, pages, forms, that sort of thing. 2. Switching on/overriding tools, utilities, adapters, etc. Call it component registration. 3. Making non-component classes into component classes. Now, one thing we notice here is that the things in 3 is not anything that needs to be overriden. It therefore doesn't HAVE to be in ZCML. You can do this equally well by making small wrapper classes in Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This is one item that can be discussed. I also realised that what goes in my point 1 here, is what goes int Martijns #1, and what goes in my point to, fits into Martijns #2. So I would like to suggest that both view #1 and view #2 are equally valid, but for different things. One thing we notice is that for example the content directive doesn't fit vith view #2, of the leaner and meaner ZCML. And neither is it user interface configuration. My conclusion: It should go away. Thoughts on that? ___ 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: Use ConfigParser for High-Level Configuration
Stuart Bishop wrote: the Z3 configuration. This was with Zope 3.0 and integrating our config with the Z3 config was quite problematic. What were the problematic bits? We lost a fair bit of flexibility doing it this way. Field validation needs to be done the ZConfig way. How would you prefer to do it? There are issues with non-required fields in non-required sections giving us grief. Can you describe these a little? There seem to be namespace issues, despite being hierarchical (eg. we have librarianlibrarian_server instead of just librarianserver, it seems because server is already used by Z3 so we can't call our section that). Hmm, that's odd :-S having are our fault, I would also call that a problem with ZConfig as the documentation is not detailed enough to match ZConfigs complexity. Yep, I'd agree with that. ZConfig is a tool that's very easy to misuse :-/ So +1 I guess. Although I personally would prefer using XML, as I think it will be more readable for complex configurations as it is better able to represent heirarchies and provide more flexibility to developers. My main gripe with the .ini format is the lack of hierarchy, but then I worry that with XML we'll suffer from an overly complex schema... config sucks, we should all just go to the pub... 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] RFC: Use ConfigParser for High-Level Configuration
Chris Withers wrote: Stuart Bishop wrote: the Z3 configuration. This was with Zope 3.0 and integrating our config with the Z3 config was quite problematic. What were the problematic bits? We lost a fair bit of flexibility doing it this way. Field validation needs to be done the ZConfig way. How would you prefer to do it? Budding in: It would be nice to be able to use Zope schema for conversion and validation. ZConfig was developed at around the same time as Zope schema. The ZConfig developers fealt they couldn't wait and reuse the work on zope.schema. and developed their own schema system. It sucks to have to maintain 2. It's also a pain for people who might want to use ZConfig's to have to figure out another. ZConfig obviously fits your brain. It doesn't fit mine at all. 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] RFC: Use ConfigParser for High-Level Configuration
--On 14. März 2006 06:23:33 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Budding in: It would be nice to be able to use Zope schema for conversion and validation. ZConfig was developed at around the same time as Zope schema. The ZConfig developers fealt they couldn't wait and reuse the work on zope.schema. and developed their own schema system. It sucks to have to maintain 2. It's also a pain for people who might want to use ZConfig's to have to figure out another. ZConfig obviously fits your brain. It doesn't fit mine at all. Could you please explain how zope.schema would deal with hierarchies? As I mentioned earlier the file format is uninteresting at this point. Having an easy and flexible framework for defining a configuration schema should be the goal and I have currently no idea how you would define some more complex configuration schemas using zope.schema. -aj --- - Andreas JungZOPYX Ltd. Co KG- - E-mail: [EMAIL PROTECTED] Web: www.zopyx.com, www.zopyx.de - --- pgpOYKkAlIFTj.pgp Description: 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: a new zcml directive?
Philipp von Weitershausen wrote: Marius Gedminas wrote: I'd prefer from zope.annotation.adapter import AnnotationAdapter getFoo = AnnotationAdapter(for_=IBar, interface=IFoo, factory=Foo, key=FOO_KEY) # I suppose the key could be optional; you could use a dotted # interface name by default and then the ordinary zope:adapter factory=.foo.getFoo / +10 Likewise. 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] RFC: Use ConfigParser for High-Level Configuration
On Tuesday 14 March 2006 06:29, Andreas Jung wrote: Could you please explain how zope.schema would deal with hierarchies? As I mentioned earlier the file format is uninteresting at this point. Having an easy and flexible framework for defining a configuration schema should be the goal and I have currently no idea how you would define some more complex configuration schemas using zope.schema. I have used schemas multiple times to represent hierarchies, most recently in the zf.zscp work, where I parse XML files using a schema or a set thereof. You simply use the Object field to connect a sub-schema to a schema. I have also used hierarchical schema trees in the principal settings code, where you hook in dynamically new schemas. 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] what is ZCML?
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: [snip] as configuration in Python code is more flexible and packages can form a more self-contained whole. Wrong! This is an important point. No one in the know is proposing using Python for configuration. Python is for definition, not configuration. The problem with some of the high-level ZCML directives is that they performed *definition* in addition to configuration. For example, browser:page creates new classes. It's important that definition be done in Python. Configuration should be done in ZCML. Okay, since I'm wrong, I think it would be useful if you spelled out the difference between definition and configuration. Admittedly, the distinction is not always crisp. Similarly, the difference between low-level configuration for programmers and high-level configuration for adminstrators is not always crisp. The philosophy is important though. ZCML is configuration, not definition. Generally, Python is for definition, although, sometimes other languages are used too. Obviously, template languages are used for definition too. Tres has argued that declarative languages might be better for defining interfaces. Also, XMI is an interesting case, as it, potentially, fills both roles. :) I have some intuitions but it's obviously not fully clear to me, and I suspect others may also have difficulty. I'll phrase give examples of things that I could interpret as configuration or as definition. Which of the following is definition and which is configuration (or something else entirely?): * Specifying which pages can be viewed for an object providing a particular interface. Low-level configuration * Attaching annotations to objects of a particular interface. Saying that we want to use a particular adapter is configuration. Implementing that adapter is definition. * Attaching menu entries to objects of a particular interface. Low-level configuration. Defining the menu entries is definition. * Setting the layer a view is in. Low-level configuration. * Specifying which page template is used to render a particular view. Low-level configuration * Setting the permissions needed to access the attributes of an object. Low-level configuration * Setting up the indexes in a catalog. definition * Setting up a catalog for a site. Creating the catalog is definition, registering it is configuration * Determine what is shown in which columns are shown in a table on a web page. Definition * The initial sorting order of these columns. Grey :) * The batch size of a particular batched view. Grey * Which resources should be included in a web page displaying a certain widget. I don't know what this means. * The relational database we've connected our application to. High-level configuration * The mailserver we've connected our application to. High-level configuration * The fields that show up in a form. Definition * Setting up which fields that show up in a form are required. Definition * Setting up which file extensions we want to allow to be uploaded into a file upload widget. Grey. I would expect that you might also want to define handlers for these. So you'd define the handlers and configure their use. Perhaps these questions are too high level and should be split up into multiple questions. What criteria do you use to determine whether something is definition or configuration? It's hard to say without repeating the words or synonyms. :) If it's I also suspect that some of these are local or application specific configuration. It makes sense to store some configuration in the ZODB, and thus, at present, not express it in ZCML at all. Yes. What is configuration sometimes depends on the application in question. Yup Should there be high-level directives in ZCML? I don't think they should be disallowed, but you really have to ask yourself if the automation they provide is worth the extra burden of understanding what they do. The other drawback of using ZCML for automation is that complicated automation is often quite cumbersome to express in ZCML. Another drawback is that such automation often combines various bits of python code with ZCML and you have to look at multiple files instead of just one. Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. Anyway, the main thrust of the ZCML simplification is to use it just for low-level configuration, not for definition. So to make it clear, you're in favor of ZCML interpretation #2, with the modification that Python code should not be
Re: [Zope3-dev] what is ZCML?
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. [...] Jim yes, except that ZCML adds strictly no abstraction compared to what would have been written in python. It only paraphrases python by hiding lines of code. I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. 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: SVN: Zope3/branches/jim-adapter/src/zope/ Redeprecated a number of things that didn't generate warnings
Philipp von Weitershausen wrote: Jim Fulton wrote: Log message for revision 65931: Redeprecated a number of things that didn't generate warnings before. Sigh. Also fixed all the depecation warnings generated by running the zope.component tests. ... Added: Zope3/branches/jim-adapter/src/zope/component/back35.py I'm certain that the stuff in this file was already deprecated (and generated deprecation warnings), so I think we can definitely get rid of it and don't need to keep it around. I didn't see evidence of deprecation warnings. These methods didn't generate warnings. The code: from bbb import * or from bbb import x, y, ..., is, sadly, quite common and generates no warnings. The fact that deprecating these now with warnings generates tens or hundreds of new deprecation warnings supports my case. It's actually even worse though. Many things that are deprecated also provide implementation that non-deprecated code relies on. :( I have some pending work now in which I have to sort this sort of thing out. This is going to take quite a bit of work to sort out. If someone else wants to try and sort this out, I'm willing to suspend work on my adapter branch until it's done. I'll note that have have only about a month and a half until the May 1 feature freeze. 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] what is ZCML?
Jim Fulton wrote: Jean-Marc Orliaguet wrote: Jim Fulton wrote: Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. [...] Jim yes, except that ZCML adds strictly no abstraction compared to what would have been written in python. It only paraphrases python by hiding lines of code. I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. Jim I would say that they paraphrase more lines of code than the low-level ones, but they fundamentally add no extremely valuable abstraction since a page is an alias for a multiadapter, a menu registers utilities, interfaces, .. . Anyway these are the ones that should be moved out of ZCML I guess since they are so site or application specific that it is difficult to be reuse them as components in other setups. But after rereading your mail it seems that this is what you said in it. simply put, high-level ZCML would be for me being able to associate a collection of resources to a given skin in a global way, or saying that a given LDAP directory should be plugged into a given authentication service, but without specifying LDAP port, servers, when doing the connection (because I have an object in ZCML that stands for the LDAP directory and another one that refers to the authentication service) /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: Jim Fulton wrote: Yup. BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) - But indirection and abstraction can provide benefits that outweight their inherent bad-ness. Whenever we consider ptoviding a high-level/automated facility, we have to weigh the benefit against the inherient badness. [...] Jim yes, except that ZCML adds strictly no abstraction compared to what would have been written in python. It only paraphrases python by hiding lines of code. I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. Jim I would say that they paraphrase more lines of code than the low-level ones, but they fundamentally add no extremely valuable abstraction since a page is an alias for a multiadapter, a menu registers utilities, interfaces, .. Wrong. the page directive defines a class and combines multiple configurations. This is definately a higher level of abstraction. . Anyway these are the ones that should be moved out of ZCML I guess since they are so site or application specific that it is difficult to be reuse them as components in other setups. Well, no. They are not application specific. Rather, we feel, after getting experience with them, that the benefits they provide don't justify the hiding they do of what's really going on. The same could have been true if they were written in Python. In fact, we have a similar problem with some of our Python menu APIs, which automate too much and actually obscure what is really a simple pattern. 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: SVN: Zope3/branches/jim-adapter/src/zope/ Redeprecated a number of things that didn't generate warnings
Stephan Richter wrote: On Tuesday 14 March 2006 10:26, Jim Fulton wrote: This is going to take quite a bit of work to sort out. If someone else wants to try and sort this out, I'm willing to suspend work on my adapter branch until it's done. I guess it would be better to work on your branch, since you get the warnings there? And because I'm farther along and because I think I have a better way to handler these things. (See zope.deferredimport on the branch.) Perhaps I should go ahead and merge zope.deferredimport. I'll have a look over the weekend. I'm gonna need a stronger commitment than that. This needs to be done either before or as I do my adapter work. I don't want to do a bunch of work that is going to conflict with someone else. Unfortunately, time is in short supply. I have to squeeze in time in the morning or on weekends. I can't wait too long. If you think you are going to attack this in earnest, then I'll refocus on packaging and set the adapter work aside for a few weeks. I'm quite sure that a lot of things we wanted to deprecate before (and remove now) are not generating warnings and need to be redeprecated. 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] Locale definitions
Hi, can somebody tell me where the locale definitions come from? The de_DE definition for currency always includes a weird symbol that might want to be a Euro symbol. However, there is no option to get a price formatted as a reasonable number without this broken symbol ... Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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: Use ConfigParser for High-Level Configuration
I know that everyone here in pythonland seems to hate xml, it may not be pretty, but we have to use it for at least some things anyway. We probably all spend quite a bit of our time writing xhtml, why not just standardize on one format. Please, I don't want to learn any more configuration languages. Laurence Jim Fulton wrote: At: http://dev.zope.org/Zope3/UseConfigParserForHighLevelConfiguration Is a proposal for using ConfigParser, rather than ZConfig for high-level configuration. Comments welcome. Jim ___ 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: Use ConfigParser for High-Level Configuration
--On 14. März 2006 17:17:12 + Laurence Rowe [EMAIL PROTECTED] wrote: I know that everyone here in pythonland seems to hate xml, Nothing but a stupid rumor :-) it may not be pretty, but we have to use it for at least some things anyway. We probably all spend quite a bit of our time writing xhtml, why not just standardize on one format. Please, I don't want to learn any more configuration languages. Where is the effort for learning ZConfig or INI-style configuration when you edit pre-configured zope.conf file? -aj pgp4wGdonGqDw.pgp Description: 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] what is ZCML?
Roger Ineichen wrote at 2006-3-13 21:57 +0100: ... I think ZCML is defently not configuration in the clasic understanding of configuration. Defining directives in ZCML means we bind components together to a application. If developer share this configuration layer with admins and use it for tasks like configuring a mail queue (like we do right now) I'm sure we will get a big mess for admins and developers understanding of what ZCML should be. Why do we need ZCML for this? It can be done with Python equally well... -- 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] what is ZCML?
Sidnei da Silva wrote at 2006-3-13 20:21 -0300: ... That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. As I understand, no other framework out there gives you this. Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks -- 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] what is ZCML?
Jim Fulton wrote at 2006-3-14 07:23 -0500: ... * Setting up the indexes in a catalog. definition Really? I would consider it configuration -- even high level configuration. ... BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) I do not agree with this (but I also do not agree with explicit is better tham implicit -- almost all activities would become drastically more difficult if they could only be done explicitly: walking, driving, eating, ... I am very happy that most things, in real life and in programming work implicitly and on an appropriate abstract level). -- 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] what is ZCML?
Lennart Regebro wrote at 2006-3-14 09:19 +0100: On 3/14/06, Sidnei da Silva [EMAIL PROTECTED] wrote: That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? And you can use Python, too, to mark them: You import the class and call an implements for it. -- 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] what is ZCML?
On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? And you can use Python, too, to mark them: You import the class and call an implements for it. Right you are, you don't even need to subclass it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] what is ZCML?
On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks Yeah. And that aspect orientation is in Zope3 done in ZCML... So I don't really know what you are trying to say here. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] what is ZCML?
Jim Fulton wrote: Jean-Marc Orliaguet wrote: I was refering to high-level ZCML, such browser:page, browser:menu, etc vs low-level directives like adapter. Jim I would say that they paraphrase more lines of code than the low-level ones, but they fundamentally add no extremely valuable abstraction since a page is an alias for a multiadapter, a menu registers utilities, interfaces, .. Wrong. the page directive defines a class and combines multiple configurations. This is definately a higher level of abstraction. OK, but that's not violent abstraction. For a python programming, going to ZCML does feel like wow, I can do some high-level configuration of my application, we are still configuring fairly low-level components (pages, menus, views ...), they still need to be configured on a higher level for the application to start working. The effort is not necessarily justified compared with how views for instance are declared inline with the code. By looking at zope/app/publisher/browser/viewmeta.py it is clear that most of the code is there handle all the different page registration options (templates, attributes, security, ..). the fact that the abstraction done in ZCML does not succeed in hiding information is an issue, IMO this is because the directives in ZCML correspond to low-level objects and the objects' internal way of functioning is getting too much exposed (not enough encapsulation) as its the case with browser:page. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Locale definitions
On Tue, 2006-03-14 at 16:18 -0500, Stephan Richter wrote: On Tuesday 14 March 2006 12:20, Christian Theune wrote: The de_DE definition for currency always includes a weird symbol that might want to be a Euro symbol. However, there is no option to get a price formatted as a reasonable number without this broken symbol ... The data comes from the former ICU project, I think it is now called OpenI18n. Unfortunately they changed the format *again* (groan), so that updating is not just a matter of updating the data. Buuh! :) -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Dieter Maurer wrote: Jim Fulton wrote at 2006-3-14 07:23 -0500: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) I do not agree with this (but I also do not agree with explicit is better tham implicit -- almost all activities would become drastically more difficult if they could only be done explicitly: walking, driving, eating, ... I am very happy that most things, in real life and in programming work implicitly and on an appropriate abstract level). +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. To say something is bad only because it's implicit or abstract is a poor argument, but to say something is bad because it's a leaky abstraction is an argument that can be explored further. For example, it's not very sensible to say implicit acquisition is bad because it's implicit, but it is quite sensible to say it's bad because it leaks all attributes and forces a lot of code to be aware of wrappers. 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] what is ZCML?
Shane Hathaway wrote: Dieter Maurer wrote: Jim Fulton wrote at 2006-3-14 07:23 -0500: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) I do not agree with this (but I also do not agree with explicit is better tham implicit -- almost all activities would become drastically more difficult if they could only be done explicitly: walking, driving, eating, ... I am very happy that most things, in real life and in programming work implicitly and on an appropriate abstract level). +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. To say something is bad only because it's implicit or abstract is a poor argument, but to say something is bad because it's a leaky abstraction is an argument that can be explored further. That's not what I was refering to. For example, it's not very sensible to say implicit acquisition is bad because it's implicit, but it is quite sensible to say it's bad because it leaks all attributes and forces a lot of code to be aware of wrappers. All abstractions have their dark side. Things can have strengths and weaknesses. I stand by my argument that indirection and abstraction are bad. Of course, they are often also good. They should be used when the good significantly outweighs the bad. Too often though, people don't realize that indirection and abstraction have an inherent cost and use them when the benefit doesn't outweigh the cost. 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] what is ZCML?
Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. which is strictly equivalent to Implicit is better than explicit, except when it's not. :-) and when it's not ... explicit is better. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On Tuesday 14 March 2006 16:44, Jim Fulton wrote: I stand by my argument that indirection and abstraction are bad. Of course, they are often also good. They should be used when the good significantly outweighs the bad. Too often though, people don't realize that indirection and abstraction have an inherent cost and use them when the benefit doesn't outweigh the cost. He he. :-) Was this a Jim brain teaser? :-) 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] what is ZCML?
Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) 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] what is ZCML?
Zachery Bir wrote: On Mar 14, 2006, at 4:31 PM, Jean-Marc Orliaguet wrote: which is strictly equivalent to Implicit is better than explicit, except when it's not. :-) and when it's not ... explicit is better. Clearly arbitraritude is better than claritization, except when it is. Or maybe: a desire to argue pedantics is better than a desire to write code (and configuration wink). Zac yes, there is a lot of truth in what you wrote, and the opposite too.. maybe the zope philosophical findings should be published in a book :-) /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/branches/jim-adapter/src/zope/ Redeprecated a number of things that didn't generate warnings
Jim Fulton wrote: I didn't see evidence of deprecation warnings. These methods didn't generate warnings. The code: from bbb import * or from bbb import x, y, ..., is, sadly, quite common and generates no warnings. The import doesn't, but the use of each method did because they looked like this: def getView(object, name, request, providing=Interface, context=None): if __warn__: warnings.warn( The concrete concept of a view has been deprecated. You want to use `getMultiAdapter((object, request), providing, name, context)`., DeprecationWarning, warningLevel()) ... I know for a fact that each call to getView, getResource, etc. (in short, every function that's now in back35.py) generated warnings upon being called, and it's the message shown above in the code snippet. It's actually even worse though. Many things that are deprecated also provide implementation that non-deprecated code relies on. :( I don't think any code relies on the stuff in back35.py, except for perhaps the get[Global]Service[s] stuff. 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: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: During the Zope3 sprint following PyCon, Paul and I, with Jim's guidance, began work on exploring how Zope can utilize eggs and be packaged using eggs. Since we're still experimenting with how eggs will be used, I wrote a script, zpkgegg, which reads the zpkg configuration information for a package and generates a standard setup.py from which an egg and vanilla sdist can be generated. You can find the script in subversion in the projectsupport project. For a brief overview of how the script is used, see README.txt (in http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs generated by zpkgegg do not attempt to distinguish between runtime, testing or development dependencies, so almost all packages will want zope.testing. README.txt contains a brief example of how to point easy_install at the appropriate folders so that easy_install can resolve the dependencies. Note that at this point we're still experimenting with how we'll use eggs, so suggestions, feedback and comments are welcome. I've been playing around a lot, trying to get at least the eggs together to make ZPT usable outside of Zope (one of the original sprint goals). I have a couple of observations: 1. Putting 'setup.cfg' under version control sucks, because the 'develop' framework scribbles on it. I think we should do two things: - Move any special settings to a 'setup.cfg.in', and modify the workspace stuff to read that first when creating setup.cfg. - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk). 2. Getting the development dependencies installed was harder than it seemed. Some packages (perhaps with help from a stanza in 'setup.cfg') could do that when running 'develop.py'; others needed me to run 'setup.py develop'. Maybe we should just kick off 'setup.py develop' at the end of the 'develop.py' dance? 3. I was hoping to get 'setup.py test' working, but that command in setuptools doesn't honor the command-line arguments for egg handling. 4. We need to begin creatinng released versions of the eggs (maybe numbering them according to the Z3 release they point into), and reorganizing the download page a bit (maybe development builds need to go on one page, and release builds on another). 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 iD8DBQFEF0fm+gerLs4ltQ4RAmrpAJoDoHdjtKphZJPy9tXG5tGjde0+hgCfaFZo tmvntIJnqEyc4tMS3UrLrXI= =G//3 -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: SVN: Zope3/branches/jim-adapter/src/zope/ Redeprecated a number of things that didn't generate warnings
On Tuesday 14 March 2006 17:26, Philipp von Weitershausen wrote: The import doesn't, but the use of each method did because they looked like this: def getView(object, name, request, providing=Interface, context=None): if __warn__: warnings.warn( The concrete concept of a view has been deprecated. You want to use `getMultiAdapter((object, request), providing, name, context)`., DeprecationWarning, warningLevel()) ... I know for a fact that each call to getView, getResource, etc. (in short, every function that's now in back35.py) generated warnings upon being called, and it's the message shown above in the code snippet. This would also be the reason you would see many less deprecation warnings. Because here they would be only report the warning once for all getView calls, while the import approach reports every call. 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: SVN: Zope3/branches/jim-adapter/src/zope/ Redeprecated a number of things that didn't generate warnings
Stephan Richter wrote: On Tuesday 14 March 2006 17:26, Philipp von Weitershausen wrote: The import doesn't, but the use of each method did because they looked like this: def getView(object, name, request, providing=Interface, context=None): if __warn__: warnings.warn( The concrete concept of a view has been deprecated. You want to use `getMultiAdapter((object, request), providing, name, context)`., DeprecationWarning, warningLevel()) ... I know for a fact that each call to getView, getResource, etc. (in short, every function that's now in back35.py) generated warnings upon being called, and it's the message shown above in the code snippet. This would also be the reason you would see many less deprecation warnings. Because here they would be only report the warning once for all getView calls, while the import approach reports every call. It's the other way around, but essentially yes. Fact is, the stuff in back35.py was definitely officially deprecated since Zope 3.1. I *think* we can get rid of it. 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
