Re: [Zope3-dev] Broken Tests
Date-Sent: 14. März 2006 07:45:59
--On 13. März 2006 16:49:27 -0500 Benji York <[EMAIL PROTECTED]> wrote:
It looks like revision 65953 ("updated to Docutils 0.4.0") broke the unit
tests. For details see
http://buildbot.zope.org:8002/Zope3%20trunk%202.4%20Linux%20zc-buildbot/b
uilds/382/test/0
Andreas, do you have any idea why that might be?
I fixed the problem in managerdetails. Docutils seems to perform tighter
type checking. Since the reST adapter defines 'unicode' as input_encoding we
need to pass a unicode string (see managerdetails.py). The other problem is
also already fixed.
Apart from that I did not receive and buildbot mails indicating the error.
Is there a problem with buildbot?
Andreas
pgp4plmz5xRm0.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] Broken Tests
--On 13. März 2006 16:49:27 -0500 Benji York <[EMAIL PROTECTED]> wrote:
It looks like revision 65953 ("updated to Docutils 0.4.0") broke the unit
tests. For details see
http://buildbot.zope.org:8002/Zope3%20trunk%202.4%20Linux%20zc-buildbot/b
uilds/382/test/0
Andreas, do you have any idea why that might be?
I fixed the problem in managerdetails. Docutils seems to perform tighter
type checking. Since the reST adapter defines 'unicode' as input_encoding we
need to pass a unicode string (see managerdetails.py). The other problem is
also already fixed.
Apart from that I did not receive and buildbot mails indicating the error.
Is there a problem with buildbot?
Andreas
pgpWUTu51kWPM.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
[Zope3-dev] Re: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 3/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > >>Martijn Faassen wrote at 2006-3-13 17:15 +0100: >> >>>... >>>A newer interpretation of ZCML is: >>> >>>""" >>>ZCML is a configuration language that configures a number of basic >>>directives for configuring the component architecture and security: >>>adapters, utilities, security requirements, and little else. Everything >>>else should be done in Python code, as configuration in Python code is >>>more flexible and packages can form a more self-contained whole. ZCML >>>should reflect the underlying universality of the component architecture. >>> >>>If two directives work with, say, adapters underneath, they should >>>really be one directive. ZCML should be simple and minimal so it is easy >>>to grasp. >>> >>>ZCML is not readable standalone. ZCML is simply used to turn on various >>>adapters and such, hooking them into the system, but we do not get a >>>clue what the adapters are doing by just looking at the ZCML - Python >>>code needs to be consulted. >>>""" >>> >>>I believe that this interpretation is the up-and-coming interpretation >>>of ZCML. >> >>I hope not... >> >>Note, that configuration files should be understand and >>adaptable by administrators. Therefore, they should be readable >>and understandable -- without an understanding of the implementation >>(but with reading of the component documentation). > > > I think differently. ZCML is primarily for programmers. ZConfig style > configuration is what administrators deal with more, isn't it? Maybe > ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files. > > I don't think of ZCML as administrative configuration. It spells out lots of site policy which must *not* creep back into the "software". > I'd rather have Python files that I can read and understand what's > going on without having to consult ZCML files, directives, > documentation, and so on, just to understand why a certain class whose > code I'm looking at is getting its behavior when I can see no > superclass. I'd like to know that a class I'm looking at is an adapter > and what it provides and what it adapts without having to dig through > a large ZCML file. > > An administrator is not likely to override my 'inplace_editor' view. Really? You have no options which an admin might want to change, either on a site-wide basis or within a single folder? How about choices like whether to accept HTML 4.0 versus XHTML 1.0? What about tag blacklists? > He may want to configure global services (if my application is written > that way) such as RDB connection parameters and mail services. But > beyond that, just loading it up in package-includes or in a specific > file is likely to be the bulk of 'administrative' effort. > > Did administrators go into your ``initialize(context)`` functions in > your Zope 2 Product's __init__.py files and change things? That's what > I view ZCML as being - a better version of that. (Better in only that > configuration and initialization can be executed separately from > Python imports) We need to get beyond the idea that Python is the ideal place to spell everything. It is particularly bad to have to modify the software shipped by the developer in order to change policy, which is where we are going if we continue down this road. Having to accept choices made by a component developer is a barrier to reuse; we won't win brownie points for all our cool components if we make it hard to use a comoponent without accepting either *all* or *none* of its configured policy choices. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFhdD+gerLs4ltQ4RAptSAJ4lvBZ2f7iwodYUP8l9J4j+nqoYcQCgr5qb c4HIIpb1Kkm/KuQ7yMYiGdU= =F/SR -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a new zcml directive?
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 > > +10 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: a new zcml directive?
Lennart Regebro wrote: > On 3/10/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > >>For instance, one that looks like this: >> >> > > > That doesn't look like configuration. No, it's an on/off switch. Me likesss it. 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] what is ZCML?
On Mon, Mar 13, 2006 at 04:40:09PM -0700, Shane Hathaway wrote: | I would suggest that is a component architecture feature, not a ZCML | feature. If Zope were a hardware device, the CA would be the wiring and | ZCML would be the schematic diagram. Great point! -- Sidnei da Silva Enfold Systems, Inc. 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] what is ZCML?
Paul Winkler wrote: On Mon, Mar 13, 2006 at 04:14:08PM -0700, Shane Hathaway wrote: You're aware of the DRY principle, right? ZCML is repetitive, and repetitive is wrong. We tend to think that repetition is *always* wrong, but in other fields there are cases in which it depends who the reader is, and how the repetition is expressed. One thing I learned in my long-ago days as a music student is that the least repetetive way to write a score is often the most difficult to sight-read. The stupidest, most repetitive way to write the score is very easy to read; it's completely linear, so the reader can't get lost. You can notate repetition easily enough, and make the score more compact, at the expense of requiring the reader to mentally construct the linear model and maintain more mental state while playing. In software development, there is an outer surface where you actually do want repetition. In a lot of web projects, for instance, it's perfectly fine to write HTML containing scores of repetitive tags. The right choice of what to repeat varies by the project. The projects I've done with Zope 3 have required me to repeat in ZCML even though that choice was not appropriate for the projects. 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: New way of using skins
Florian Lindner wrote: >>I think ovarall, Phillip should support those named layers. That feedback is a little late. The proposal had been around for months! By the way, from what I read in the old layer code (which seemed to be yours), I got the impression that named layers and skins were slated for deprecation but simply not officially deprecated yet. > Yes, I have my interface registered with: > > interface=".interfaces.ICentershockSkin" > type="zope.publisher.interfaces.browser.IBrowserSkinType" > name="centershock" > /> Note that this makes the interface a skin. Layers don't have to be registered at all anymore. > class ICentershockSkin(zope.app.rotterdam.Rotterdam): > > > I've tried to use the name centershock in either a layer or a type attribute, > but nothing worked. You will have to state the layer using standard dotted names to access the interface, e.g.: layer=".interfaces.ICentershockSkin". > Only giving the the python path with the layer attribute > worked. The type attribute does not even seem to exist, although I understood > Philipps proposal that it should replace the layer. > (tested with a resource directive) Ooops, sorry, I forgot to properly update the Implementation Status. Done now. 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] what is ZCML?
Alec Mitchell wrote: ... I was a bit disturbed. What's the point? The point is that you are using the adapter. > It tells you nothing unless you refer to the actual implementation. It tells you that the adapter is being used. > Why not just put the registration in python alongside the implementation if that's where the configuration of provided and required interfaces is going to be? No, that's where the declaration is. For smaller (non-Zope) applications, you could configure them in Python. For Zope, we want people to override your configuration without modifying your code. ZCML lets them do that. > I had considered one of zcml configuration's greatest benefits was that it could give a high level overview of how pieces of a package were interconnected. Of course it's still possbile to do things the old way, but I get the impression that it's discouraged. Brevity is not always a boon, though that cuts both ways here (adding a new "magical" seeming zcml declaration to save a copy/paste here and there may not be the best idea either). I understand how you feel here. It *would* be nice to have the information in both places *if* you didn't have to maintain it in both places. There is a tradeoff between avoiding duplication and making things cleared for the person reading ZCML. If I have to choose where to put the information, I far prefer having it in Python. 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?
On Mon, Mar 13, 2006 at 04:14:08PM -0700, Shane Hathaway wrote: > You're aware of the DRY principle, right? ZCML is repetitive, and > repetitive is wrong. We tend to think that repetition is *always* wrong, but in other fields there are cases in which it depends who the reader is, and how the repetition is expressed. One thing I learned in my long-ago days as a music student is that the least repetetive way to write a score is often the most difficult to sight-read. The stupidest, most repetitive way to write the score is very easy to read; it's completely linear, so the reader can't get lost. You can notate repetition easily enough, and make the score more compact, at the expense of requiring the reader to mentally construct the linear model and maintain more mental state while playing. I have no idea whether any of that applies to ZCML, so I'll re-lurk now. -- 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] what is ZCML?
Dieter Maurer wrote: ... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). As Jeffrey pointed out (and as I mentioned in my recent proposal), ZCML provides low-level configuration. It is aimed at developers, not adminstrators. Adminsitrators will use high-level configuration languages like ZConfig or ConfigParser. 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?
Martijn Faassen wrote: ... A newer interpretation of ZCML is: """ ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Right. Everything else should be done in Python code, Sort of. > 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. 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. Anyway, the main thrust of the ZCML simplification is to use it just for low-level configuration, not for definition. 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?
Sidnei da Silva wrote: On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote: | And I think it's | very important for the Python code to say what it does, so when I come | back to a module five months later I'm not staring at MyFactory going | "yeah, but what is it?" One thing that must not pass by unnoticed is that one of the points of 'Why ZCML' is that it allows you to 'do stuff' (configuration?) with plain python code that wasn't written for, nor depends on, Zope 3 directly. 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. I would suggest that is a component architecture feature, not a ZCML feature. If Zope were a hardware device, the CA would be the wiring and ZCML would be the schematic diagram. 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?
On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote: | And I think it's | very important for the Python code to say what it does, so when I come | back to a module five months later I'm not staring at MyFactory going | "yeah, but what is it?" One thing that must not pass by unnoticed is that one of the points of 'Why ZCML' is that it allows you to 'do stuff' (configuration?) with plain python code that wasn't written for, nor depends on, Zope 3 directly. 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. -- Sidnei da Silva Enfold Systems, Inc. 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] what is ZCML?
Jeff Shell wrote: Why design a language at all? We already did, and it's a BASIC-like language, so now we reap the consequences. Some of the consequences are: 1. If you stick to the established directives, you express repetitive, low level information that really needs to be represented in a higher level way. 2. If you invent your own directives, you make it harder for people to figure out what low level configuration is occurring. I see two ways to fix this situation: 1. Write tools for inspecting and searching low level configuration. If the tools are good enough, we can feel free to write any directives we like. 2. Drop ZCML and configure in Python. Solution #2 is not the subject of this thread, so let's not discuss it here. Yes, I know it's already possible, but it's against the Zope convention, and convention is important. Let Python be the language. Let ZCML exist to do the final step of loading/registering registerable objects in a predictable manner, and to provide the few things that we don't want to pollute our (or others) Python code with, like security declarations. You're aware of the DRY principle, right? ZCML is repetitive, and repetitive is wrong. The primary solution to repetitive code is to move to a higher level of expression. 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?
On 3/13/06, Alec Mitchell <[EMAIL PROTECTED]> wrote: > +1 The first time I saw: > > > > I was a bit disturbed. What's the point? It tells you nothing unless you > refer to the actual implementation. Right, but it switches it on, which is important. :-) -- 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
[Zope3-dev] Broken Tests
It looks like revision 65953 ("updated to Docutils 0.4.0") broke the
unit tests. For details see
http://buildbot.zope.org:8002/Zope3%20trunk%202.4%20Linux%20zc-buildbot/builds/382/test/0
Andreas, do you have any idea why that might be?
--
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] what is ZCML?
On 3/13/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: > > A newer interpretation of ZCML is: > > > > """ > > ZCML is a configuration language that configures a number of basic > > directives for configuring the component architecture and security: > > adapters, utilities, security requirements, and little else. Everything > > else should be done in Python code, as configuration in Python code is > > more flexible and packages can form a more self-contained whole. ZCML > > should reflect the underlying universality of the component architecture. > > > > If two directives work with, say, adapters underneath, they should > > really be one directive. ZCML should be simple and minimal so it is easy > > to grasp. > > > > ZCML is not readable standalone. ZCML is simply used to turn on various > > adapters and such, hooking them into the system, but we do not get a > > clue what the adapters are doing by just looking at the ZCML - Python > > code needs to be consulted. > > """ > > IOW, "most of the directives we need have already been invented. [1] We > don't want to build high level directives; ZCML will follow the BASIC > school of language design." :-) > > [1] http://www.inventionmysteries.com/article4.html > > While I was initially on board with the idea of reducing the number of > directives, I've changed my mind. I think we want high level directives > and we want people to feel free to write new directive types. We want > tools that let us inspect and search the resulting low level directives. > If we have to use ZCML, then ZCML should be expressive. Then why do we have Python? Is Zope going to be a "write ZCML directives to write your Zope app" system? Or is it going to be "write Python code to write your Zope app" system? I don't know if it's possible to use a ZCML configuration-execution outside of ZCML, which makes testing an awful hard beast sometimes. There's functionality that's locked away inside the directives that you then have to have not only the Zope environment set up to run, but a ZCML environment too. Pain pain pain pain pain. Unlock the magic. If it must exist, make it available and understandable to me. Don't hide it under more layers and verbs and nouns that conflict and change meaning depending on if you're using ZCML and Python. "Make ZCML More Expressive" - did we learn nothing from DTML Expressions? It starts out simply enough, but how long until we have more and more logic in ZCML? We already have this conditional that I barely understand (but appreciate in theory). Why design a language at all? I only want ZCML to allow me not to take on a packages provided components when I import it. I don't want to start thinking I can write an enterprise workflow and document management system in it. Let Python be the language. Let ZCML exist to do the final step of loading/registering registerable objects in a predictable manner, and to provide the few things that we don't want to pollute our (or others) Python code with, like security declarations. -- Jeff Shell ___ 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 Monday 13 March 2006 10:59, Dieter Maurer wrote: > Martijn Faassen wrote at 2006-3-13 17:15 +0100: > > ... > >A newer interpretation of ZCML is: > > > >""" > >ZCML is a configuration language that configures a number of basic > >directives for configuring the component architecture and security: > >adapters, utilities, security requirements, and little else. Everything > >else should be done in Python code, as configuration in Python code is > >more flexible and packages can form a more self-contained whole. ZCML > >should reflect the underlying universality of the component architecture. > > > >If two directives work with, say, adapters underneath, they should > >really be one directive. ZCML should be simple and minimal so it is easy > >to grasp. > > > >ZCML is not readable standalone. ZCML is simply used to turn on various > >adapters and such, hooking them into the system, but we do not get a > >clue what the adapters are doing by just looking at the ZCML - Python > >code needs to be consulted. > >""" > > > >I believe that this interpretation is the up-and-coming interpretation > >of ZCML. > > I hope not... > > Note, that configuration files should be understand and > adaptable by administrators. Therefore, they should be readable > and understandable -- without an understanding of the implementation > (but with reading of the component documentation). +1 The first time I saw: I was a bit disturbed. What's the point? It tells you nothing unless you refer to the actual implementation. Why not just put the registration in python alongside the implementation if that's where the configuration of provided and required interfaces is going to be? I had considered one of zcml configuration's greatest benefits was that it could give a high level overview of how pieces of a package were interconnected. Of course it's still possbile to do things the old way, but I get the impression that it's discouraged. Brevity is not always a boon, though that cuts both ways here (adding a new "magical" seeming zcml declaration to save a copy/paste here and there may not be the best idea either). Alec ___ 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/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote at 2006-3-13 17:15 +0100: > > ... > >A newer interpretation of ZCML is: > > > >""" > >ZCML is a configuration language that configures a number of basic > >directives for configuring the component architecture and security: > >adapters, utilities, security requirements, and little else. Everything > >else should be done in Python code, as configuration in Python code is > >more flexible and packages can form a more self-contained whole. ZCML > >should reflect the underlying universality of the component architecture. > > > >If two directives work with, say, adapters underneath, they should > >really be one directive. ZCML should be simple and minimal so it is easy > >to grasp. > > > >ZCML is not readable standalone. ZCML is simply used to turn on various > >adapters and such, hooking them into the system, but we do not get a > >clue what the adapters are doing by just looking at the ZCML - Python > >code needs to be consulted. > >""" > > > >I believe that this interpretation is the up-and-coming interpretation > >of ZCML. > > I hope not... > > Note, that configuration files should be understand and > adaptable by administrators. Therefore, they should be readable > and understandable -- without an understanding of the implementation > (but with reading of the component documentation). I think differently. ZCML is primarily for programmers. ZConfig style configuration is what administrators deal with more, isn't it? Maybe ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files. I don't think of ZCML as administrative configuration. I'd rather have Python files that I can read and understand what's going on without having to consult ZCML files, directives, documentation, and so on, just to understand why a certain class whose code I'm looking at is getting its behavior when I can see no superclass. I'd like to know that a class I'm looking at is an adapter and what it provides and what it adapts without having to dig through a large ZCML file. An administrator is not likely to override my 'inplace_editor' view. He may want to configure global services (if my application is written that way) such as RDB connection parameters and mail services. But beyond that, just loading it up in package-includes or in a specific file is likely to be the bulk of 'administrative' effort. Did administrators go into your ``initialize(context)`` functions in your Zope 2 Product's __init__.py files and change things? That's what I view ZCML as being - a better version of that. (Better in only that configuration and initialization can be executed separately from Python imports) -- Jeff Shell ___ 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/13/06, Alec Mitchell <[EMAIL PROTECTED]> wrote: > On Monday 13 March 2006 10:59, Dieter Maurer wrote: > > Note, that configuration files should be understand and > > adaptable by administrators. Therefore, they should be readable > > and understandable -- without an understanding of the implementation > > (but with reading of the component documentation). > > +1 The first time I saw: > > > > I was a bit disturbed. What's the point? It tells you nothing unless you > refer to the actual implementation. Why not just put the registration in > python alongside the implementation if that's where the configuration of > provided and required interfaces is going to be? I had considered one of > zcml configuration's greatest benefits was that it could give a high level > overview of how pieces of a package were interconnected. Of course it's > still possbile to do things the old way, but I get the impression that it's > discouraged. Brevity is not always a boon, though that cuts both ways here > (adding a new "magical" seeming zcml declaration to save a copy/paste here > and there may not be the best idea either). I consider one of ZCML configurations greatest detriments is that it does many things that cannot be easily replicated in Python (one day, you'll probably come across having to set up just the right unit test harness and you'll realize what I mean). I consider one of it's greatest detriments is that it completely destroys Don't-Repeat-Yourself. You can do: class MyFrank(object): def __init__(self, context): # ... See? No declarations on MyFrank that says what it does. Or you can do: class MyFrank(object): implements(IFrank) adapts(IBun, IRelish) def __init__(self, context): # ... And do the full line in ZCML. But then you've just said the implements / adapts twice. Using different words, I should point out. Or you can do the line the short way and let the Python code say what it does. Three options. I know I'm not consistent with the ones that I choose. I just know that I spend more time looking at Python code and I'd rather understand what the Python code is doing by looking at the Python code. Three options. That sure kills the "there should be one, and only one, obvious way to do it" theory too. Don't even get me started about when I might want to use 'zope:view', 'browser:view', or just plain old 'adapter' (since a view is just a multi adapter, as are content providers and viewlets and all sorts of other fun and useful combinations). Anyways - for me, the point of is that I already said in MyFactory that it implements and adapts certain interfaces already. I don't want to say that twice. And I think it's very important for the Python code to say what it does, so when I come back to a module five months later I'm not staring at MyFactory going "yeah, but what is it?" And I also think it's important for code to be debuggable, inspectable, so that when there's a bug from ... well, wherever it came from, code can be traced. It's very hard to trace through ZCML statements, and what they've produced. From dynamically made classes to the weirdness of the metaconfigure.py code (handlers, discriminators, etc) - all of those things get in the way of a productive pdb or "why is this thing blowing up?" session real fast. In my experience anyways. So I figure - the less ZCML I use, the better it will be for me to maintain in the future. -- Jeff Shell ___ 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: A newer interpretation of ZCML is: """ ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. """ IOW, "most of the directives we need have already been invented. [1] We don't want to build high level directives; ZCML will follow the BASIC school of language design." :-) [1] http://www.inventionmysteries.com/article4.html While I was initially on board with the idea of reducing the number of directives, I've changed my mind. I think we want high level directives and we want people to feel free to write new directive types. We want tools that let us inspect and search the resulting low level directives. If we have to use ZCML, then ZCML should be expressive. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Fwd: [Zope3-dev] a new zcml directive?
I wrote this reply earlier but forgot to use 'reply all' instead of 'reply'. Oops. I'm also editing and expanding my remarks slightly from the earlier. In short: Python is a good programming language, usually easy to follow. ZCML is not. Either work really hard at improving ZCML, or just simplify it. I'm having more headaches and misery with it as time goes by, and the last thing I need is more and more directives when I get infuriated by the ones that currently exist. On 3/13/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Marius Gedminas wrote: > [snip] > > -1 > > > > 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 > > > > > > > > I think this is exactly the same as Jeff Shell's suggestion, but its > > 3am, and I'm too tired to read his entire message. > > I guess it comes down to the question whether annotations are a basic > configuration concept, like views, and thus have their own directive to > register them, or not. It seems like we just had the debate and decision that ZCML was doing too much. Yes - I sometimes prefer to see (especially in a class directive) over . But in general, I want ZCML to be simple. I hate editing it. The more that I have to do in ZCML, the less that I want to do it. The less that I want to keep on using Zope. I have had too many frustrations in recent weeks. We have a good programming language. We should use it as much as possible. > In your example, the ZCML doesn't show that we actually are setting up > an annotation, and it doesn't show for what we're setting up an > annotation for in the first place either. It's one intrepretation of > ZCML that it should show these things. The other interpretation of ZCML > is that its main task is just hooking components into the system. I'm totally with the second option. I'd rather have the Python code say that it's an annotation than the ZCML. And I hate having to duplicate that information. I know that if I'm going to have ZCML say "provides='...'", I don't need to have 'adapts(...)' in my Python code. But then I find myself staring at my Python code and going "uh, what does this class do again?" I'd rather let the Python code say it. I hate seeing views documented (and implemented) like this: class Search: ... No 'implements', no superclass, no adapts, nothing. It means there's some other file somewhere else that is modifying this classes behavior that I have to look at and change my internal parsing mode to read and understand. And since I got bit by this again recently (trying to subclass from formlib's 'SubPageForm but registered with ZCML as a viewlet caused my __init__ override to go boom and I didn't know at that point which signature to implement), my anger with the system has grown. > Perhaps we should make explicit which ZCML we want to have, as its > design can be quite different depending on that choice. I still appreciate ZCML, but only in its most simplistic form. I think it's applicable for: * "I have an adapter and would like to register it" * "I have a utility and would like to register it" * "I have a class and would like to apply security options to it and a couple of other declarations (additional interfaces supported, a factory, etc)" * "I have an interface, and I'd like to say that all things that implement it are things of type x" * "I'd like to load and configure this package now" I think ZCML should *and only should* be used to basically register code to run separately from Python imports. That means it shouldn't be making new components on the fly. That starts to compound its job. Its job should be, in my arrogant opinion, saying "Here's some Python code - an object, a function, a class, whatever - and what it means to Zope (is it an adapter? a utility? or a class that needs security restrictions applied and supports common mega-interfaces *like* IAnnotatable)". That's very different than automation. The automation is "I have a thing, or want a thing, that does this: go forth and generate it dynamically for me." Whether it's an annotation adapter, or an edit form, or a viewlet, there are now extra objects that don't really exist in any Python module that can be easily inspected, introspected, etc. They are phantoms generated by the machine. You have to have them to make certain things work. But what they are isn't obvious. They become painful to debug, introspect, etc. It really seems like one of the goals/ideas for ZCML was that you could make a crazy application with Zero Python Code - just use a lot of ZCML and it will generate everything for you. Or use ZCML, an interfaces.py module with some schema, and have a couple of persistent classes, and t
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > Note, that configuration files should be understand and > adaptable by administrators. Therefore, they should be readable > and understandable -- without an understanding of the implementation > (but with reading of the component documentation). I tend to agree. -- 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] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote at 2006-3-12 15:54 -0500: >Dieter Maurer wrote: >> Jim Fulton wrote at 2006-3-11 18:03 -0500: >> >>>... >>>Where is this documented? >> >> >> I do not know. I saw a feature description in the mailing list. >> Fred and Tres (the authors) should be able to tell you whether >> there is a formal documentation and where you can find it. >> >> >>>Let's pursue this a bit. >>> >>>Would it be possible to write a configuration file that loaded >>>it's own schemas? >> >> >> Yes -- with some restrictions: as I described in my previous mail. >> >> The feature essentially works as follows: >> >> You have an abstract section type in your primary >> schema, usually usable in a multisection. >> >>Examples: ZServer server, ZODB storage, the general extension >>abstract section type >> >> In your module/package, you define your own section type >> implementing the abstract section type in its "component.xml". >> You are completely free in its keys and subsections. >> >> In the configuration file, you import your module/package (which >> makes available the definitions in its "component.xml") and >> instantiate one or more of the section types defined there. >> >> Your application/module looks for the sections of "its" type >> and uses them. >> >> The restriction: you cannot have new keys on the top level -- all >> must be nested in a section type defined by your "component.xml". >> But, this, I consider an advantage (ZConfig here behave similar >> to a "ConfigParser" approach). > >So the example I gave won't work. In a schema, I have to have an >abstract type for each thing I might want to add. But I don't know what >I want to add. This doesn't sound very extensible. You can have a *SINGLE* abstract type -- fixed for any extensions you may imagine and use this as the hook in your "component.xml". Such a single abstract type was added to the Zope schema to make almost arbitrary extensions possible. >I can't fathom the ZConfig documentation so I don't really know what >an abstract type is. It is essentially a name, which can be used at various places in your schema and implemented at other places in different ways. > I don't know how restrictive it has to be. >Can I define an abstract type that matched anything? Yes. I even think you currently cannot impose restrictions on the sectiontypes claiming to implement the abstract type. >Can I define a schema that just defines an abstract type that >matches anything? I think you must also use the abstract type in a section/multisection definition. But that would be all. -- 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?
Martijn Faassen wrote at 2006-3-13 17:15 +0100: > ... >A newer interpretation of ZCML is: > >""" >ZCML is a configuration language that configures a number of basic >directives for configuring the component architecture and security: >adapters, utilities, security requirements, and little else. Everything >else should be done in Python code, as configuration in Python code is >more flexible and packages can form a more self-contained whole. ZCML >should reflect the underlying universality of the component architecture. > >If two directives work with, say, adapters underneath, they should >really be one directive. ZCML should be simple and minimal so it is easy >to grasp. > >ZCML is not readable standalone. ZCML is simply used to turn on various >adapters and such, hooking them into the system, but we do not get a >clue what the adapters are doing by just looking at the ZCML - Python >code needs to be consulted. >""" > >I believe that this interpretation is the up-and-coming interpretation >of ZCML. I hope not... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). -- 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] zc.table and zc.resourcelibrary feedback
On Mar 13, 2006, at 10:59 AM, Martijn Faassen wrote: [...] Thanks for looking into this Martijn. We have some internal versions of a sortable zc.table factory that take a different approach, and are not using the client-side part of the zc.table code much at all. If you're willing to look at it and consider integrating it into zc.table, one of us will send you the files privately. You up for that? BTW, I think I listed in the release announcement that both of these packages could use some TLC. Thank you generally for considering giving them some! I would love to see resourcelibrary developed in these directions, fwiw: - pluggable insertion, to address one of the concerns in your original message. I don't remember exactly what Benji and I talked about. Maybe the resources would not be snippets but callable transformations. Maybe we could provide a factory for one kind of transformation which could be combined to effectively get the same behavior as our current transformation? A piece of code could request a transformation, which might depend on other transformations? Maybe this is too general. - order-aware dependency insertion: IIRC, the algorithm for gathering the necessary dependencies doesn't honor order, which may be a problem in some cases. order-aware could get fragile, though--for instance, if one resource says it depends on A and then B, and another says it wants B then A, what to do? Maybe it's necessary to have one spelling for order-unaware dependencies, and another for order-aware dependencies; maybe that itself is insufficient... - lighter-weight insertion into the publishing framework. No one (including myself) has followed up materially on Jim's old discussion of in-Zope publication pipelines. The request approach is heavy, and maybe a WSGI pipeline element is too heavy also. It would be nice to resolve this, though: replacing the request factory is a bit crazy. It's not a priority for us to work on these things right now, but we open-sourced some of the less-polished packages in hopes that others would see their possibilities, as you did, and be intrigued. ;-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] what is ZCML?
Hi there, In this mail I'd like to make explicit some competing design influences on ZCML. The first interpretation of what ZCML is: """ ZCML is a configuration language that provides abstract directives for configuring Zope applications. If we're setting up a page, we use the page directive. If we're setting up a skin, we use a skin directive. If we're setting up an adapter, we use an adapter directive. Even if two directives underneath only set up adapters (such as browser:page and zope:adapter), we still think it's valuable to have two directives, as we make explicit what we are doing. ZCML should be readable without having to consult Python code a lot. I.e. if we set up an adapter, we know what interface it's working for and we know what interface the adapter is providing just by looking at the ZCML. """ I believe that the first interpretation is the traditional interpretation of ZCML. A newer interpretation of ZCML is: """ ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. """ I believe that this interpretation is the up-and-coming interpretation of ZCML. (the third interpretation of ZCML is that it's evil and should be destroyed I'd like to leave out of this discussion - the outcome doesn't matter that much if you're of that persuasion) Of course, these interpretations have never been made very explicit. We have discussions where they are implicitly present, though. Reducing the namespaces in ZCML drastically makes more sense from the second perspective than from the first. Adding a new ZCML directive to support annotations makes more sense from the first and doesn't make much sense from the second interpretation. Which one of these interpretations is the right one for the future? I realize that the interpretations I sketch out may be extreme ends of a spectrum. I haven't seen a lot of advocacy the removal of browser:page, for instance. It may be that the real ZCML should be in the middle of these two interpretations. If so we should make our criteria explicit somehow, too - when do we really want to add a directive, and when do we really not want to remove a directive? Perhaps there is whole other perspective possible on ZCML that resolves this whole issue. Let us know if you have one! 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] zc.table and zc.resourcelibrary feedback
Benji York wrote: Martijn Faassen wrote: [snip] A second issue seems to me a bug in the javascript. When I use StandaloneSortFormatter I can click on the title of a column to sort to see a sorted view. This works wonderfully well. Unfortunately the javascript is a bit simplistic in that it simply adds the sort_on:list parameter over and over to the URL. This makes for very long and ugly URLs. Want me to work on a bugfix? Please. The current JavaScript is very much "the simplest thing that will possibly work". I looked into it and have written some new JavaScript, but I realized that the sorting behavior currently is apparently dependent on the amount of items in the 'sort_on' list in the URL. As far as I can understand, getRequestSortOn flips the sorting order for each time a particular field is mentioned in the URL. I don't know how exactly this works in the case of form-based tables, where this information is, I believe, POSTed. Encoding this information in the amount of times a particular item is present in the URL (or post body) seems odd. Was the motivation again "the simplest thing that will possibly work"? To really fix it, the sort order itself (forward or reversed) should be encoded in the URL (or POST), something like sort_forward=Column or sort_reversed=Column. I currently do not understand why this approach wasn't taken in the first place... The third issue is more like a missing feature. I was playing with the batching support, and I got it to work. Still, I had to write a bit of batching code myself and to make it fully work, I'd have to make sure of not showing 'previous' at the beginning of the fist batch, not showing 'next' at the beginning of the last batch, and the like. Yes, when writing zc.table we weren't quite sure how the batching should/would work and were using it in two independent projects. Both eventually grew code that's probably much like you wrote. It would be interesting to work on a "default batcher". Maybe I'll get to look into this. I still need to consider how it all should work together with sorting. Any hints? 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] a new zcml directive?
Stephan Richter <[EMAIL PROTECTED]> writes: > On Friday 10 March 2006 10:19, Martijn Faassen wrote: >> What do people think? > > +1 We use this pattern for every annotation in SchoolTool and it gets old > really quick. One argument that could be made is that the code in the > function could be in the constructor. This is bad, because the __init__ > method should not do any "writing" on other objects. > I looked at the schooltool code a while ago and the annotation thing was something that I also noted as duplicated in there. Since I wanted to use annotations in a similar way I wrote a package that defines such an annotation ZCML directive. You can download the package here: http://dev.gentoo.org/~wrobel/zope.annotation.tar.bz2. It still has a weird hack in the README.txt and is not polished in any way but I believe it should work. I am a Zope3 newbie so don't expect too much From the thing. But I thought it might be of interest to the ongoing discussion. Don't hesitate to tell me why the package sucks :) Still eager to learn more about Zope. Regards Gunnar -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ pgp6SExTFynI4.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] a new zcml directive?
On Monday 13 March 2006 06:20, Martijn Faassen wrote: > In your example, the ZCML doesn't show that we actually are setting up > an annotation, and it doesn't show for what we're setting up an > annotation for in the first place either. It's one intrepretation of > ZCML that it should show these things. The other interpretation of ZCML > is that its main task is just hooking components into the system. Yes, I agree with that. I tend to like the first one and use it that way. I commonly use the ZCML File of a package to get an overview of what features it provides. > Perhaps we should make explicit which ZCML we want to have, as its > design can be quite different depending on that choice. Yes, I think this would be a good idea. 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] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote: > Have you written a ZConfig schema? Have you tried to read the > documentation on writing one? Have you writtem an application > that uses ZConfig? If you had, I think you'd know what I was > talking about. I have. Our chunk of our schema.xml is over 600 lines including comments and whitespace and defines 22 sections. We needed a configuration mechanism for Launchpad and related tools. I decided to go with ZConfig to integrate our configuration with the rest of the Z3 configuration. This was with Zope 3.0 and integrating our config with the Z3 config was quite problematic. We gained a little doing it this way. Having the Z3 configuration with our own configuration information made is easy to maintain the multiple configs we need to maintain (several production configs and developer workstation configs, maintained in the RCS alongside the code). In theory, we could generate documented configuration templates but we haven't done that -- we just maintain the commends in 'default' configuration. We lost a fair bit of flexibility doing it this way. Field validation needs to be done the ZConfig way. There are issues with non-required fields in non-required sections giving us grief. There seem to be namespace issues, despite being hierarchical (eg. we have instead of just , it seems because is already used by Z3 so we can't call our section that). These issues might be ZConfig in Z3.0 issues, or problems with how we are using it. If the issues we are having are our fault, I would also call that a problem with ZConfig as the documentation is not detailed enough to match ZConfigs complexity. Pulling in configuration information should be light weight, but I find ZConfig puts too much burden on developers for little gain. Despite being very complex, it seems to lack features that we need or the features don't work the way we need them too (eg. we really need to say 'this config file is identical to that one, except these fields are changed. Extending ZConfig to do this did not seem fun.). An alternative would have been a .ini or xml format similar to what you have already described. I elected to proceed with ZConfig to see how we went and to integrate our config with Zope3's. In hindsight, I think we would have had a simpler, more flexible and more easily extensible system if we had gone with .ini or xml instead. Migration for us shouldn't be a problem, we access to our configuration is via a simple API so we can replace the guts. I expect to reimplement our config machinery when I get a chance to work on low priority tasks (we have issues with what we have, but it works). 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. -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Moving to docutils 0.4.0?
I would like to update Docutils for Zope 2 trunk and Zope 3 trunk to v 0.4.0. Any objections for - importing docutils as top-level module on svn.zope.org - replacing src/docutils with an svn:externals definition ? Andreas pgpXIknsX6Wpy.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] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote: Have you written a ZConfig schema? Yup, a few, as well as adding a couple of options to zope.conf, which totally abuses ZConfig :-/ Have you tried to read the documentation on writing one? Yup :-) Have you writtem an application that uses ZConfig? Yup, couple... If you had, I think you'd know what I was talking about. Well, admittedly, it's been a while since I wrote the schemas for MailingLogger (although that had to be updated for Zope 2.8) and an even longer while for Process (http://www.simplistix.co.uk/software/applications/process) and X2Y (http://www.simplistix.co.uk/software/applications/x2y) but I don't remember it being particularly painful. X2Y, in particular, is quite an extensive app with lots of plugins, each with their own schemas, and I just had a look at the schemas again now and find them pretty easy to understand. I must be missing something... is there something particularly complex that you're doing? These aren't due to new features added and discarded. This is generally due to refinement based on experience. potato / potato - tomato / tomato... Hmmm, that doesn't work so well when it's written down :-/ I don't know what you are asking, since I said in this thread and in the proposal that we could support the old format. OK. I assume this was done because it's too much of a PITA to write ZConfig schemas. I think you assume wrong there... Oh? What evidence do you have? Do you think it was done because meaningless options are considered a good thing? I would assume it's because someone saw an abstraction that wasn't really there, as with cache managers in Zope 2. But, that's just an assumption and likely to be wrong. svn blame may be more useful here... Well, maybe they could use ZConfig? Has anyone asked them? Why don't you do that. I presume http://www.webwareforpython.org/archives/list/paste-users.en.html would be the right place? In fact, why don't you lobby to have it added to the standard library? Sure, I'll give it a go, but if there's already several in there, I can see people being reluctant, even if the ones that are in there are inferior :-/ Still, Guido did eventually admit HTMLParser.py, so there's some hope :-) 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] RFC: Use ConfigParser for High-Level Configuration
Chris Withers wrote: Jim Fulton wrote: I'd like to be able to use configuration files for the test runner, but I really don't want ZConfig to be a dependency of the test runner. I also don't want to go through all of the gymnasics required to develop a ZConfig schema just for the test runner. What are these gymnastics you speak of? Have you written a ZConfig schema? Have you tried to read the documentation on writing one? Have you writtem an application that uses ZConfig? If you had, I think you'd know what I was talking about. This isn't all that common. Hmmm, the number of DeprecationWarnings I seem to see with Zope 3-related stuff would appear to disagree with that... These aren't due to new features added and discarded. This is generally due to refinement based on experience. ... Note that in my proposal, I proposed supporting the ZConfig format, at least for a while. Isn't there some way we could make this switchable so we don't have to make either/or choices? (I'd still be verymuch in favour of seeing ZConfig as the default.) I don't know what you are asking, since I said in this thread and in the proposal that we could support the old format. I assume this was done because it's too much of a PITA to write ZConfig schemas. I think you assume wrong there... Oh? What evidence do you have? Do you think it was done because meaningless options are considered a good thing? Paste Deploy provides a framework for doing this. I'd rather colaborate on something that exists that have to reinvent it just to keep using ZConfig. Well, maybe they could use ZConfig? Has anyone asked them? Why don't you do that. In fact, why don't you lobby to have it added to the standard library? 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
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.
...
> ===
> --- Zope3/branches/jim-adapter/src/zope/component/back35.py 2006-03-12
> 21:46:52 UTC (rev 65930)
> +++ Zope3/branches/jim-adapter/src/zope/component/back35.py 2006-03-12
> 21:46:54 UTC (rev 65931)
> @@ -0,0 +1,133 @@
> +##
> +#
> +# Copyright (c) 2006 Zope Corporation and Contributors.
> +# All Rights Reserved.
> +#
> +# This software is subject to the provisions of the Zope Public License,
> +# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
> +# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
> +# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> +# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
> +# FOR A PARTICULAR PURPOSE.
> +#
> +##
> +"""Features that will be deprecated in Zope 3.5
> +
> +$Id$
> +"""
> +import sys
> +import warnings
> +
> +from zope.interface import Interface, providedBy
> +from zope.component.bbb.interfaces import IServiceService, IDefaultViewName
> +from zope.component.service import GlobalServiceManager
> +
> +# Try to be hookable. Do so in a try/except to avoid a hard dependency.
> +from zope.hookable import hookable
> +
> +def getGlobalServices():
> +from zope.component import getGlobalSiteManager
> +return GlobalServiceManager('servicemanager', 'zope.component.service',
> +getGlobalSiteManager())
> +
> +def getGlobalService(name):
> +return getGlobalServices().getService(name)
> +
> +def getServices(context=None):
> +if context is None:
> +return getGlobalServices()
> +else:
> +# Use the global service manager to adapt context to IServiceService
> +# to avoid the recursion implied by using a local getAdapter call.
> +try:
> +return IServiceService(context)
> +except TypeError, error:
> +from zope.component.bbb.exceptions import ComponentLookupError
> +raise ComponentLookupError(*error.args)
> +
> +getServices = hookable(getServices)
> +
> +def getService(name, context=None):
> +return getServices(context).getService(name)
> +
> +def getServiceDefinitions(context=None):
> +return getServices(context).getServiceDefinitions()
> +
> +# Presentation API
> +
> +def getView(object, name, request, providing=Interface, context=None):
> +view = queryView(object, name, request, context=context,
> + providing=providing)
> +if view is not None:
> +return view
> +
> +from zope.component.bbb.exceptions import ComponentLookupError
> +raise ComponentLookupError("Couldn't find view",
> + name, object, context, request, providing)
> +
> +def queryView(object, name, request,
> + default=None, providing=Interface, context=None):
> +from zope.component import queryMultiAdapter
> +return queryMultiAdapter((object, request), providing, name,
> + default, context)
> +
> +queryView = hookable(queryView)
> +
> +def getMultiView(objects, request, providing=Interface, name='',
> context=None):
> +view = queryMultiView(objects, request, providing, name, context=context)
> +if view is not None:
> +return view
> +
> +from zope.component.bbb.exceptions import ComponentLookupError
> +raise ComponentLookupError("Couldn't find view",
> + name, objects, context, request)
> +
> +def queryMultiView(objects, request, providing=Interface, name='',
> + default=None, context=None):
> +from zope.component import queryMultiAdapter
> +return queryMultiAdapter(objects+(request,), providing, name,
> + default, context)
> +
> +def getViewProviding(object, providing, request, context=None):
> +return getView(object, '', request, providing, context)
> +
> +def queryViewProviding(object, providing, request, default=None,
> + context=None):
> +return queryView(object, '', request, default, providing, context)
> +
> +def getDefaultViewName(object, request, context=None):
> +view = queryDefaultViewName(object, request, context=context)
> +if view is not None:
> +return view
> +
> +from zope.component.bbb.exceptions import C
Re: [Zope3-dev] a new zcml directive?
Marius Gedminas wrote: [snip] -1 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 I think this is exactly the same as Jeff Shell's suggestion, but its 3am, and I'm too tired to read his entire message. I guess it comes down to the question whether annotations are a basic configuration concept, like views, and thus have their own directive to register them, or not. In your example, the ZCML doesn't show that we actually are setting up an annotation, and it doesn't show for what we're setting up an annotation for in the first place either. It's one intrepretation of ZCML that it should show these things. The other interpretation of ZCML is that its main task is just hooking components into the system. Perhaps we should make explicit which ZCML we want to have, as its design can be quite different depending on that choice. 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] a new zcml directive?
Lennart Regebro wrote: On 3/10/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: For instance, one that looks like this: That doesn't look like configuration. What does it look like to you? If hooking up adapters is considered to be configuration, why is hooking up annotations not configuration? 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: Use ConfigParser for High-Level Configuration
Jim Fulton wrote: Would it be possible to write a configuration file that loaded it's own schemas? Not sure what you mean... For example, suppose I wanted to configure zope and twisted, could I do something like: import zope.app.appsetup import zope.app.twisted import zope.testrunner I think it's %import you're looking for. site-definition site.zcml %import site.conf? ;-) interrupt-check-interval 200 type HTTP address 8080 path Data.fs path access.log path z3.log path STDOUT tests-pattern f?tests$ tests-path src module-pattern !^(ZConfig|BTrees|persistent|ThreadedAsync|transaction|ZEO|ZODB|twisted|zdaemon|zope[.]testing|)[.] Okay, not sure what the troublesome bit of the above is... Then free the main program from having to specify a schema? Again, not sure what you mean... 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] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote: I don't want to try to make paste deploy or setuptools, use ZConfig. There are other tools out there that use ConfigParser, Yay! Lowest common denominator programming :-( I'd like to be able to use configuration files for the test runner, but I really don't want ZConfig to be a dependency of the test runner. I also don't want to go through all of the gymnasics required to develop a ZConfig schema just for the test runner. What are these gymnastics you speak of? This isn't all that common. Hmmm, the number of DeprecationWarnings I seem to see with Zope 3-related stuff would appear to disagree with that... ...but maybe that's another thread. Note that in my proposal, I proposed supporting the ZConfig format, at least for a while. Isn't there some way we could make this switchable so we don't have to make either/or choices? (I'd still be verymuch in favour of seeing ZConfig as the default.) I assume this was done because it's too much of a PITA to write ZConfig schemas. I think you assume wrong there... Paste Deploy provides a framework for doing this. I'd rather colaborate on something that exists that have to reinvent it just to keep using ZConfig. Well, maybe they could use ZConfig? Has anyone asked them? Either that or make the config switchable for the edge case where you want to use paste deploy. But please, don't force a change like this through for one particular piece of interoperability that not many of us seem to feel as passionately about as you :-S 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
