[Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Tres Seaver wrote: > I'm not sure what Chris meant, but the change to the visual output of > the testrunner when running "with dots" seems gratuitous to me, as well > -- I don't see any benefit to the "indented, narrower" output, Me neither, for what it's worth. > Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) > to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. Sort of. It didn't break configure && make. It's just "make install" that was broken. I still don't understand why people whine about "make install" being gone. The point of a checkout is that you have a full functional SVN working copy, not an installation source. If you want to install things, use a TGZ archive which lets you do "make install" perfectly fine. I've never installed Zope anywhere except on production servers anyway, and there you should obviously use releases. If you absolutely must use "make install" from a checkout (perhaps because you want to install the trunk somewhere), then you can make a TGZ first using zpkg. Though I still don't see the point of 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] httpgz in zope.conf?
On Mar 21, 2006, at 8:53 AM, Stephan Richter wrote: On Tuesday 21 March 2006 08:41, Jim Washington wrote: Perhaps another proposal could suggest a method for registering and sequencing post-processing utilities? I think WSGI middleware components are the answer here. In general, I agree. I think almost all, or maybe even all, of Jim's examples belong there. However, It would be outside the app server, so something inside might be more desirable. Right. In particular, while most of the transforms that Jim listed need no interaction with the app server except to receive the output, resourcelibrary works more naturally if there is access to the application. That said, after thinking about it a little, resourcelibrary functionality might work also as a WSGI middleware piece: the middleware would stash an empty set in the WSGI environ, and then components wanting to use resourcelibrary would look for the key in request.environment, and if it exists, add their request to the set. Then when the middleware gets the output, it would analyze the set and add the requested resource link/code and dependencies to the output. It might have to move away from Zope 3 resources, since the middleware typically wouldn't have access to a database connection... The biggest losses here I can think of would be Zope 3- integrated virtual host awareness, and the possibility of hooking ZODB resources into the resourcelibrary, as TTW development might want. That said, the WSGI approach might be a win for resourcelibrary. And implementing all of the other bits Jim mentioned, including httpgz, as WSGI bits I think would be a win for us and potentially for other WSGI-compliant frameworks. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] httpgz in zope.conf?
On Tuesday 21 March 2006 08:41, Jim Washington wrote: > Perhaps another proposal could suggest a method for registering and > sequencing post-processing utilities? I think WSGI middleware components are the answer here. However, It would be outside the app server, so something inside might be more desirable. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 3/20/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > >>So *don't use ZCML*; use Python: there is literally nothing which can >>be done in ZCML which cannot be done in Python. I wish that folks who >>don't like / need ZCML would quit trying to dictate how the rest of us >>use ZCML. > > > "Literally nothing"? Try literally everything. I'm sorry. But that was > the experience I had that set me in such a bad temperament. I had no > idea what half of these directives were doing, and when trying to > duplicate them in a test environment I nearly threw the laptop to the > ground and swore of programming forever. I was *INCREDIBLY* > frustrated. There is a lot of potentially valuable functionality > *hidden behind ZCML*. If a ZCML directive were a one line > wrapper/adapter around a common function, I'd feel different. If a directive is too magical for you, and you don't mind writing Python, then *don't use it*. Consider the following: If you consider what it does (register a view which uses a filesystem-based template) rather than how it does it (i.e., synthesize a new class for use as a view factory and bind a template to it). If you don't like the implementation, and don't mind the boilerplate, then why not write: class MyView(object): index = zope.pagetemplate.pagetemplatefile.PageTemplateFile( 'templates/myview.pt') def __init__(self, context, request): self.context, self.request = context, request def __call__(self, *args, **kw): return self.index(*args, **kw) zope.security.checker.defineChecker(MyView, zope.security.checker.CheckerPublic) zope.component.provideAdapter( (ISomeInterface, zope.publisher.interfaces.browser.IBrowserRequest), MyView, 'myview.html') Note that I am *not* arguing in favor if the current implementation of / ; in fact, I think it is needlessly complex. But I am strongly against the idea of tossing the directive on that account, and thereby breaking deployed applications. > My argument and wish has been only this: simplify ZCML. Make it more > transparent what it is doing. There is a classic tension here between "convenience" and "purity". Please recall the many of the directives in ZCML were *added* because people got tired of typing repetitious boilerplate (imagine the Python code above repeated *dozens* of times in a given application). >>Or, if you like ZCML but don't like the current directive set, feel free >>to propose a new set of directives you think are better, and implment >>them in *your* namespace: if enough other people like them, we can talk >>about making people who are already using the current set change. But >>let's quit tearing up what people have alredy learned in favor of a >>it-must-be-better-because-its-new variant which doesn't yet exist, and >>whose improved usability we have to take on faith. > > > My set of directives is , , , and maybe > . Inside of , , , , > and (because I do believe that 'factory' there is a nice > shortcut). So just use those. But *don't* argue that the rest of us mustn't define or use more convenient directives. > Nothing new. Only less. Less concepts to have to remember. Less > concepts to have to look up. Less code to have to try to follow when > it's 10:30 at night and I've been working six hours too long and I > still can't figure out why my field adapter on an IChoice isn't > getting its value set properly and I can't get a vocabulary > bootstrapped up to write a test to debug and then verify the fix of > it. > > Make ZCML do whatever you want. But if you're going to share it, it > needs a HELLUVA lot better documentation. I'm glad for what's there > now. But I've been surprised by ZCML one time too many, and have lost > too many hours trying to figure out the surprise. Too many similar > directives, too many possible attribute combinations, and too little > information about what certain choices will actually do or what > they're good for. And the source is not a readable, reliable backup > point to look at. > > >>I'll note that the "Refactor mercilessly" meme from XP is *not* >>particularly well-suited to frameworks / libraries: it is best suited >>when applied to *applications*, where the impacts of such changes are >>borne entirely by the people who make them. When you tear up the API of >>a framework / library, you force *other* people to make changes, often >>without any particular benefit to them. > > > What is well suited to frameworks and libraries is to provide maximum > playability with a minimum number of concepts. When the component > architecture was simplified (Zope 3.0 -> Zope 3.1), the whole thing > suddenly made a whole lot more sense to me. Utilities and Adapters. > Nice. There are a lot of ways those can be combined, especially when > multi-adapters come into play. But the core concepts are clea
Re: [Zope3-dev] Re: a plan for widgets?
Jeff Shell wrote: On 3/20/06, Tres Seaver <[EMAIL PROTECTED]> wrote: So *don't use ZCML*; use Python: there is literally nothing which can be done in ZCML which cannot be done in Python. I wish that folks who don't like / need ZCML would quit trying to dictate how the rest of us use ZCML. "Literally nothing"? Try literally everything. I'm sorry. But that was the experience I had that set me in such a bad temperament. I had no idea what half of these directives were doing, and when trying to duplicate them in a test environment I nearly threw the laptop to the ground and swore of programming forever. I was *INCREDIBLY* frustrated. There is a lot of potentially valuable functionality *hidden behind ZCML*. If a ZCML directive were a one line wrapper/adapter around a common function, I'd feel different. What if it were trivial to replicate any ZCML directive in a test environment? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Choice field missing too ? Was: [Zope3-Users] question: can I make a view trusted: A BUG
Hi, there is already a collector entry for the bug below, but I think the ChoiceField has the same issue. I too encountered a ForbiddenAttribute while accessing the title attribute of a ChoiceField. Adding the code below to fields.zcml with the corresponding changes did the trick. The error went away. I added to zope.app.schema.fields.zcml: - Andreas Ok everyone: it is a zope bug. The following should be included in zope.app.schema.fields.zcml: ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] httpgz in zope.conf?
Gary Poster wrote: On Mar 20, 2006, at 9:39 AM, Stephan Richter wrote: On Monday 20 March 2006 09:35, Jim Washington wrote: [...] BTW, I would be glad to see a proposal to add this to the core. I think httpgz is general very interesting to a lot of people. +1 If it goes into the core, httpgz can be done much more elegantly. Perhaps another proposal could suggest a method for registering and sequencing post-processing utilities? I can think of several possible post-content-generation operations that might take advantage of such a hook. - javascript minimization / obfuscation - watermarking or tagging pdf's and images - inserting 'this is the development site, not the real site' or copyright statements - tidying - wow the folks that 'view source' - httpgz - zc.resourcelibrary -Jim Washington ___ 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-CMF] Fighting the Zope 2.9 testrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Chris Withers wrote: > >> Jens Vagelpohl wrote: >> >>> >>> From the old testrunner, which I miss *a lot*, I could ensure I am >>> indeed running a specific module by doing... >> >> >> >> Yup, this is one of the things I like least from the Zope 3 world. >> What happened to proposals and community agreement before inflicting >> big changes on other people who're trying to help out? > > > Oh cut the crap. The new test runner tries very hard to be backward > compatible. The old test runner was increasingly unmaintaiable and > had a host of bugs of it's own. > > I can't tell what you snipped, but I'm guessing that it was the > breakage of supplying a module name as a positional argument. > This breakage was not intentional. It was a bug. There is an > easy work around: just use the -m option. > >> I particularly hate the fact that no real effort was put into >> backwards compatibility, not to mention those silly weird >> sort-of-fifty-dots-per-line thing that doesn't actually work. I'm not sure what Chris meant, but the change to the visual output of the testrunner when running "with dots" seems gratuitous to me, as well - -- I don't see any benefit to the "indented, narrower" output, especially because it's "prettiness" gets fouled up anyway by deprecation warnings, etc. I objected to the change enough to file collector issues: http://www.zope.org/Collectors/Zope/1958 http://www.zope.org/Collectors/Zope3-dev/493 > What the heck are you talking about? What doesn't work? Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. E.g.: $ cd /tmp $ svn co svn+ssh://svn.zope.org/repos/main/Zope/trunk zt $ cd zt $ ./configure --prefix=/tmp/zt-sw && make && make install ... running install_scripts error: cannot copy tree 'build/scripts-2.4': not a directory make: *** [install] Error 1 $ make clobber inplace ... $ ls -laF bin ls: bin: No such file or directory (The 'bin' directory was, in Zope 2.7, 2.8, the location for the scripts, created during an inplace build). 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 iD8DBQFEH/jP+gerLs4ltQ4RAhlOAKDBNhLZNaLvUn9bHOTBiIjBz2CYLQCeI6gp WD21iz7SSHQfCTOd0PxT22s= =k4TY -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] remove zope.app.module
On Tuesday 21 March 2006 06:18, Jim Fulton wrote: > I'm going to remove zope.app.module. It hasn't been released and isn't > bein used by anyone afaik. We'll likely bring it back in the future > in another location. > > If there are objections, let me know. For now, I'll remove it form the > jim-adapter branch. Objection. :-) WebDev uses it. I would appreciate if you leave it there for now. We can absorb it into the webdev package if you wish. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Choice field missing too ? Was: [Zope3-Users] question: can I make a view trusted: A BUG
On Tuesday 21 March 2006 08:09, Andreas Elvers wrote: > there is already a collector entry for the bug below, but I think the > ChoiceField has the same issue. Could you make a comment on the reported bug that this is true for the choice field as well? Thanks! 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] Reducing the Amount of ZCML Directives ready for review
On Monday 20 March 2006 10:47, Philipp von Weitershausen wrote: > Stephan Richter wrote: > >>>I am -1 on moving out of the class directive. I am > >>> impartial on the factory subdirective, since I never use it. I think > >>> factories are failed experiment, btw, but that's another story. > >>> > >>>If is moved out than what's the point of having a class > >>>directive in the first place. > >> > >>Making security assertions about the class. This would be the only thing > >>that would be used for, ultimately reducing its functionality to > >>one thing. > > > > Then why don't you call the directive ""? > > Or , because it's class-based. Good idea. Oh, and that's not specific at all? I prefer my directive (I agree that was an old, unnecessary relic) that allows me to configure anything that I might want to configure about a class: security, interfaces and maybe the usage (for example factory, utility, adapter). This way when I see a class directive I know what I am in for. BTW, I currently really hate when I have to do this: ... I think it would be much nicer if I could do one of the two choices: ... or ... Of course it would be even nicer to specify the adapted and provided interface as well in the directives, so I think this is a lost battle already. :-( > > Or even better, get rid of > > it altogether and have simple directives for "" and "". > > Perhaps. Of course, practicality sort of wins here because we already > have top-level and directives for making assertions > about modules. Oh, so now you start talking about practicality? If we are practical, we would not remove all high-level ZCML declarations. I am in total agreement that the browser directives or any directive creating new types are doing far too much, but this does not mean that high-level ZCML directives are bad. > > I am still -1 on removing implements from the class directive. > > Why? I respect the vote but so far I haven't heard a reason for it. In various responses I have given reasons. I just do not believe that a minimal ZCML is the way of attracting new developers. Especially, since we have no alternative. > > I think they have another purpose. They group the declarations for one > > thing together, which makes it easier to read. > > True. Which is why I would defend class/require and class/allow as > subdirectives (instead top-level ones). The reason why I'm not defending > class/implements is because I'd like to consolidate. There is nothing bad about having an sub- and top-level-directive. As you pointed out we do this already with the security directives. > Especially in Five, but I can imagine also in other projects, you'd like > to declare interfaces on classes without configuring their security. > Five invented five:implements for this. In Zope 3 this is not possible. Yes it is. The class directives are additive. The following works and we do this in SchoolTool: ... > Also, neither in Zope 3 nor in Five it's possible to declare an > implemented interface on a function (I actually have use cases for this, > of course I could deal with them differently, but a uniform way would be > nicer). I agree, this is a real limitation. So why not have something like that: 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: a plan for widgets?
On Monday 20 March 2006 16:29, Roger Ineichen wrote: > It's important to have informative sugger in a configuration language > like ZCML. Otherwise it get reduced to somewhat useless that I will hate > to write but have to. That's how I feel as well. But until now I thought I have been a minority. I thought that Dominik's suggestions of different levels of ZCML would be helpful. I am also slowly seeing where Shane comes from with his ZCML collection directives. > The next step will probably be to move the > configuration to pyhton at all. I don't think so. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] remove zope.app.module
I'm going to remove zope.app.module. It hasn't been released and isn't bein used by anyone afaik. We'll likely bring it back in the future in another location. If there are objections, let me know. For now, I'll remove it form the jim-adapter branch. 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: [Zope-CMF] Fighting the Zope 2.9 testrunner
Chris Withers wrote: Jens Vagelpohl wrote: From the old testrunner, which I miss *a lot*, I could ensure I am indeed running a specific module by doing... Yup, this is one of the things I like least from the Zope 3 world. What happened to proposals and community agreement before inflicting big changes on other people who're trying to help out? Oh cut the crap. The new test runner tries very hard to be backward compatible. The old test runner was increasingly unmaintaiable and had a host of bugs of it's own. I can't tell what you snipped, but I'm guessing that it was the breakage of supplying a module name as a positional argument. This breakage was not intentional. It was a bug. There is an easy work around: just use the -m option. I particularly hate the fact that no real effort was put into backwards compatibility, not to mention those silly weird sort-of-fifty-dots-per-line thing that doesn't actually work. What the heck are you talking about? What doesn't work? 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: Reducing the Amount of ZCML Directives ready for review
Lennart Regebro wrote:
On 3/20/06, Tres Seaver <[EMAIL PROTECTED]> wrote:
[...]
This doens't really make the number of statements smaller, and it
doesn't save very many lines of ZCML. But it *does* make it pretty
darn obvious what to do. Because you can't do much else.
Note again that this is not a proposal. I'm not saying we should do
this. I'm just saying that simplifying can be done in several ways,
and this would be one (not nessecarily good) way.
(In fact, I think I like this, but it can without any problems be made
into a separate product that adds this statement to ZCML, for
simplified product creation).
I like your focus to higher levels of usability.
level 1 -> ca basics: class, utility and adapter
^
| implemented by
|
level 2 -> developer patterns: class, utility, adapter, view, factory,
skin, layer etc.
^
| implemented by
|
level n -> ...
As you pointed out the question of simplicity depends on a certain
abstraction level (perspective).
It's important to provide different logical abstraction levels, because
there are a lot of people interacting perfectly with a physical system
on a certain abstraction level without knowing any implementation
details on a deeper level [1].
Phillip's design principle ("There should be one-- and preferably only
one --obvious way to do it.") is very important within a certain
abstraction level [2], but if we apply this rule over all levels we will
increase complexity for higher level use cases. IMO for a bunch of
people that's pure-zope 3-anti-marketing :(
Regards,
Dominik
[1] Example:
Use case on level 2:
Register and invoke a factory:
It's necessary to have an API for the factory registering and
-invocation, but it's not necessary at all to know that factories are
implemented as utility.
Register a class:
It's important to register a class including its marker interfaces, its
factory and its security declaration in simple way.
[2] Example:
The biggest violation of this principle is the adaption-mechansim
itself: Neither the convenience function IFoo(context) nor the other
API's provide uniform adapter artefacts (-> adapters providing location,
location proxied adapters, security proxy around the context, security
proxy around the adapter). This lack cannot be hidden properly on higher
abstraction levels. This fact is leading to weird ZCML-directives.
___
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: Reducing the Amount of ZCML Directives ready for review
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Dominik Huber wrote: I really appreciate your effort in all other cases, but in this case I think its not a simplification. At least in case of class/implements it is. I'm merging two directives, class/implements and five:implements into one. The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. That "rule" is somewhat debatable (the debate seems ongoing). I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your "simpler / cleaner" thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. + 1 ___ 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
Hi Stuart, Stuart Bishop wrote: What were the problematic bits? # Disgusting hack to use our extended config file schema rather than the # Z3 one. TODO: Add command line options or other to Z3 to enable overriding # this -- StuartBishop 20050406 from zdaemon.zdoptions import ZDOptions ZDOptions.schemafile = os.path.abspath(os.path.join( os.path.dirname(__file__), 'lib', 'canonical', 'config', 'schema.xml')) Also, there is only one schema.xml so multiple components can't each insert their own blob of configuration information into the global schema. Okay, so I can see two potential problems here: 1. Zope 3's schema.xml has the same problem that Zope 2's used to have - no generic multisection where other frameworks/products/whatever can insert their own bits of configuration. I suspect fixing that schema.xml (which involves inserting one or two lines ;-) would remove the need for your monkeypatch above. 2. Are you aware of the component.xml stuff that Dieter referred to? 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? Validation of the entire config file, and if there are one or more errors output a readable report at the end with error messages returned by the validators. The current mechanism just spits out exceptions, which is really bad for configuration files aimed at end users. Agreed, this is something that could be added to ZConfig. Or Zope 3 could catch those exceptions and morph them into useful messages. Admittedly, you wouldn't get all the errors though, so ZConfig could do with some enhancement here... If I have a non-required section foo, containing a non-required key bar, if I try and access config.foo.bar I get an AttributeError. I should get the default value for bar. Okay, probably a bug. Have you reported this to the ZConfig author(s)? 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... Why would you want a schema for the XML? xml freaks like schemas ;-) Although I actually probably should have said "I worry that we'll end up with overly complex and badly structured xml *cough*zcml*cough*... - validation handlers would be registered for a particular XML namespace ...yay! we love namespaces *sigh* - Config file is loaded into a set of data structures, one for each XML namespace That's not a bad idea though... - warnings are emitted if there are XML namespaces loaded that don't have a validator. Why? If people don't want validators, don't force them... Of course, .ini would be able to emit more meaningfull error messages: foo/bar/1 in section [whatever] is required, but not found blah/whatever in section [whatever] is not a valid url section [baz] is required but does not exist. I'm all for just fixing the bugs in ZConfig and I think you'll be happy enough. Not sure it's worth the huge upheavels :-S cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Jens Vagelpohl wrote: From the old testrunner, which I miss *a lot*, I could ensure I am indeed running a specific module by doing... Yup, this is one of the things I like least from the Zope 3 world. What happened to proposals and community agreement before inflicting big changes on other people who're trying to help out? I particularly hate the fact that no real effort was put into backwards compatibility, not to mention those silly weird sort-of-fifty-dots-per-line thing that doesn't actually work. My other big bug bear is what I've read about make-make-install no longer working in 2.9. Why on earth was this just broken without any thought to the vast number of people who rely on this as a simple way to quickly get a new release onto a number of boxes? I've been very happy to see the majority of the stuff in Zope 3, but it seems some things like this are getting rushed through without a lot of thought and consideration, which seems very un-zope-3 to me :-( 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
