Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
--On 6. Oktober 2007 08:14:10 -0400 Benji York [EMAIL PROTECTED] wrote: Andreas Jung wrote: we want to get rid of the term Zope 3 in the future The confusion for people with the terms and Zope 2 and Zope 3 was one of major topics of the last german Zope conference. And there were also talks between the DZUG and the ZF on this topic and there was agreement that we should speak of the zope application and zope components - however this topic belongs on desk of the Zope foundation. -aj pgpcfSCx21IDq.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: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
--On 6. Oktober 2007 12:03:06 -0300 David Pratt [EMAIL PROTECTED] wrote: I agree with you Roger. I want things to stay as they are for the same reasons. I have great respect for Zope 2 developers however there there are two development paradigms at play that are fundamentally incompatible despite the inclusion of component architecture in Zope 2. What do you man by two development paradigms? Please don't build a wall between Zope 2 and Zope 3 developers. Most old-school Zope 2 developers are doing development also with Zope 3 components and Zope 3 techniques. Look at Plone 3.0 and its heavy usage of Zope 3 techniques...impressing. The Zope 3 development paradigms are highly accepted by most Zope 2 core developers...we are all sitting in the same boat. There is a fundamental difference in the Zope 2 and Zope 3 architecture but little difference between the paradigms how we should design and write software on top of the Zope platform in the future. The distinction between Zope 2 and Zope 3 must disappear. We must speak of Zope. Everything else is counterproductive when it comes to promoting Zope. There is only one Zope developer community and most of us have a Zope 2 and a Zope 3 hat on (others have a CMF or a Plone head). An artificial separation between Zope 2 and Zope 3 developers is undesirable in my opinion. Andreas pgpkMzAHd5fv7.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: AW: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
--On 6. Oktober 2007 18:24:45 +0200 Roger Ineichen [EMAIL PROTECTED] wrote: Hi Andreas What do you man by two development paradigms? Please don't build a wall between Zope 2 and Zope 3 developers. Most old-school Zope 2 developers are doing development also with Zope 3 components and Zope 3 techniques. Look at Plone 3.0 and its heavy usage of Zope 3 techniques...impressing. The Zope 3 development paradigms are highly accepted by most Zope 2 core developers...we are all sitting in the same boat. There is a fundamental difference in the Zope 2 and Zope 3 architecture but little difference between the paradigms how we should design and write software on top of the Zope platform in the future. The distinction between Zope 2 and Zope 3 must disappear. We must speak of Zope. Everything else is counterproductive when it comes to promoting Zope. There is only one Zope developer community and most of us have a Zope 2 and a Zope 3 hat on (others have a CMF or a Plone head). An artificial separation between Zope 2 and Zope 3 developers is undesirable in my opinion. You are using 7 times the term Zope2 and 9 times Zope 3 and also Plone 3.0 in this small text. Can you try to describe this without 2 or 3 in Zope *? I guess not, right? s/Zope 2/Zope application server s/Zope 3/Zope components I really don't care about how it is called, but I'm sure we need some naming convention and since we have one, I don't see any reason to change this. As said: there was a big discussion on the terms Zope 2 and Zope 3 during the last DZUG conference. Bringing it to the point: the terms zope 2 and zope 3 should die. There's only 'Zope'. You also use the term Plone 3.0 which you implie that we know that you mean the Plone which uses Zope 3 components ? You are respecting the postifx 3.0 in the Plone world but not for Zope? why? Plone is an application but not a framework. Plone does not have an identify crisis as Zope. I'm a little confused and don't understand why you are lobbing for such a renaming and at the same time you are using this terms so heavy. Why? There are much, much more applications deployed on top of the Zope application server than on top of the Zope component architecture. There is a huge installation of Plone site on top of the Zope app server and now the Zope component framework. Although you are a Zope component-only developer you can not ignore the dependent applications and framework. The Zope application server core team is always in communication with the CMF and Plone teams (we play nicely together (mostly)) and I do expect the same within the Zope world. The merging of the lists is just one multiple steps for bringing the two side together. Andreas pgpL2CrWnTW0b.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: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
--On 6. Oktober 2007 03:16:53 +0200 Roger Ineichen [EMAIL PROTECTED] wrote: Betreff: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. -1 Not that I'm not interested in what's going on in Zope 2, but the two list let me easy separate this two different topics. And it will allow me to read the Zope2 mails in digest mode if I don't have time to read all. That's a bit shortsighted. First we want to get rid of the term Zope 3 in the future (since it confuses ppl). Second: decisions and discussons made in the Zope components world have an impact on the Zope 2 world. Sorry to say but the Zope components world is not an island. Andreas pgpY19teibECj.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] I'd lobe to merge the zope3-dev and zope-dev lists
--On 4. Oktober 2007 15:15:40 -0400 Stephan Richter [EMAIL PROTECTED] wrote: On Thursday 04 October 2007 09:57, Jim Fulton wrote: This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. -1. I do not follow zope-dev at all and the traffic is pretty high there. Not as high as on the zope3-dev list. +1 for phasing the zope3 term out. -aj pgpxQcMv4o99u.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: What does python 3000 mean for zope?
--On 1. September 2007 16:21:23 -0400 Stephan Richter [EMAIL PROTECTED] wrote: On Saturday 01 September 2007 15:33, Martijn Faassen wrote: I think Zope will be on Python 2.x for many years to come. I really hope not. A friend of mine and I want to get a bit involved in Python 3000 once it is stable enough that the standard libs can get some attention. At this point I really want to have an initial look at porting Zope 3 packages to Python 3. I really hope we can move to Python 3 in a reasonable amount of time. What are the major benefits from moving to Python 3? The major and most important change I see in Py3K is the string-as-unicode implementation. That's a big advantage. However everything else is in some way syntactical sugar. Py3k still won't run on multiple CPUs, it still uses the GIL... improvements in this area would be arguments for me to move to Py3K. Only speaking for my self, I don't see major improvements that would my daily Python experience significantly. Andreas pgp1rdvpI3Z8N.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: What does python 3000 mean for zope?
--On 1. September 2007 21:40:20 +0200 Martijn Faassen [EMAIL PROTECTED] wrote: Hey, David Pratt wrote: Ultimately, the folks that will even want to maintain a 2.x code base will quickly erode since the forefront of development is never the past. Perhaps it will all move more quickly for this reason when python 3K is out for real. This is what I fear will happen. This could mean either some huge codebases in Python 2.x are going to be left behind in some kind of ghetto, or that the single community will fracture into a Python 2.x and a Python 3.x community. Both scenarios suck, so I certainly hope I'm being pessimistic about this. Nothing more to add..a separation of the Zope community into Python 2.X and Python 3.X is the last thing we need (and could afford). Andreas pgpUgnp2iNnX5.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: What does python 3000 mean for zope?
--On 1. September 2007 16:00:19 +0530 Baiju M [EMAIL PROTECTED] wrote: May be we can try Python 3.0 porting in next GSoC ? :) -1 on that. I am pretty sure that this will lead to two different codebases which are hard to maintain over long period of time. We should stick with Python 2.X for the time being. Otherwise we risk compatibility issues with the current deployed Zope installations. We must not jump on every train just because it stop in front of out door. -aj pgpiX73whYL95.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: What does python 3000 mean for zope?
--On 1. September 2007 16:33:58 +0530 Baiju M [EMAIL PROTECTED] wrote: Andreas Jung wrote: --On 1. September 2007 16:00:19 +0530 Baiju M [EMAIL PROTECTED] wrote: May be we can try Python 3.0 porting in next GSoC ? :) -1 on that. I am pretty sure that this will lead to two different codebases which are hard to maintain over long period of time. We should stick with Python 2.X for the time being. Otherwise we risk compatibility issues with the current deployed Zope installations. We must not jump on every train just because it stop in front of out door. I hope your -1 is for porting to Python 3.0 in next year itself. May be we should consider it after Python 3.0 final release ? Otherwise how long will be the time being ? If packages like ZODB, zope.interface zope.component is not ported that will be great loss for Python 3.0 programmers. I am basically speaking here for the Zope 2 world. If we move core components to Python 3000 we have to move the complete Zope 2 core to Python 3000 which will cause a huge disaster because of almost every third party component is likely to break. This is a big risk for the reputation of Zope. I currently don't see how a smooth transition would look like. At the end will have Zope 2 for Python 2.X, Zope 2 for Python 3.X and Zope 3-ish components for Python 2.X and different components for Python 3.X...appears as a nightmare to me. Andreas pgpyzMhrXTDSI.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [StabilizeEggPackages] (edit) Is that all that has to be done in setup.py?
--On 29. August 2007 16:15:36 +0200 Wichert Akkerman [EMAIL PROTECTED] wrote: I don't like the overly long PyPI pages, but I do really like having easily browsable documentation online. PyPI is the only places where that is possible at the moment. Pointing people to svn.zope.org to read documentation is not an option in my opinion: finding and reading documentation would require a dozen extra mouseclicks. I also prefer the overlong Pypi pages as long as there is no chance to jump _directly_ from PyPI into the related documentation section. Clicking on some svn.zope.org link and clicking through the directory structure is not a very option from the usability prospective (even for experienced programmers). Andreas pgpcga52BvtBd.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: Guide for maintaining software in the Zope repository
--On 25. August 2007 08:51:44 -0400 Benji York [EMAIL PROTECTED] wrote: Fred Drake wrote: On 8/24/07, Stephan Richter [EMAIL PROTECTED] wrote: But if you prefer consistency, then we really should be staying with the Zope 3 style guide, This, of course, all depends on the answer to the question: Consistency with what? Zope 3 history? The larger Python community? (Don't think the world agrees on PEP 8...) Because my desire is to make individual Zope packages more widely adopted by the larger Python community and bring more people to Zope 3, I prefer PEP 8. As has been said of Python, more Python code will be written in the future than has been in the past, I hope the same is true of Zope. Hopefully, there are also more Zope users to come than we have ever had. Consistency is good, but we have to be consistent with the largest body of code/group of people as possible. Can someone please point out the major differences concerning Python code between PEP 8 and the Zope 3 style guide? -aj pgpl3EWCRn8Tj.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: Guide for maintaining software in the Zope repository
--On 24. August 2007 09:25:14 -0400 Stephan Richter [EMAIL PROTECTED] wrote: On Thursday 23 August 2007 20:37, Philipp von Weitershausen wrote: I would like to get your comments on it. No matter what this evolves to, I wouldn't mind eventually seeing it set in stone with your blessings, so that the checkin police can use it as the highway code to issue tickets to anyone who's speeding on the repository lane. I don't like the section on coding style. A while back we agreed that people can choose it freely as long as every package in the *namespace* has the same style. So for example, ``zope`` and ``z3c`` use the original Zope 3 styleguide, while ``zc`` uses PEP8 compliance. This is much easier to keep track of than having to remember every package's style. I personally do not like underscore-style method naming, so I would never use it for packages that I am starting from scratch. I do honor other people's decisions though, and would always follow the original author's style. Consistency is better than correctness in this case. (I usually tend to value correctness higher than consistency.) We should not be too pendantic when it comes to coding styles. I assume that most contributors to Zope 3 or Zope components know how to write code the Zope 3 way. Now with Philipp's guide we have a document telling people how to do it the right way. We still have the stick in our bag for the case of the cases... Andreas pgpod7hrA09mA.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: Guide for maintaining software in the Zope repository
--On 24. August 2007 12:21:24 -0400 Fred Drake [EMAIL PROTECTED] wrote: On 8/24/07, Andreas Jung [EMAIL PROTECTED] wrote: We should not be too pendantic when it comes to coding styles. I assume that most contributors to Zope 3 or Zope components know how to write code the Zope 3 way. As the community grows, this is an increasingly poor assumption. Different developers come to Zope with different background experience and from environments that have their own coding styles. My statement was focused on discussions like camel case vs. underscores. Such discussions are basically academic. In real life when you develop software for different companies or projects it is hard to switch your personal coding styles from project to project. In my experience you adopt the Zope 3 style guide also to other projects outside the Zope world. But let's be pragmatic at some point... Now with Philipp's guide we have a document telling people how to do it the right way. I don't think that's what this is. This is a document describing how things /are/ done in the Zope 3 repository. That's helpful both as it stands and as a foundation for a document on how things should be going forward. What's the difference? :-) -aj pgp9faw3M2D4R.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: Guide for maintaining software in the Zope repository
--On 24. August 2007 19:27:23 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: I find it very stupid to prescribe whilespace rules and Whitespace rules have a major impact on the readability of code. Readability is a major point when we talk of code quality. Readable code does not make code automatically but good code has to be readable. '_' separation versus camelCase spelling. Ack. -aj pgpic2FxlUE9h.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: Guide for maintaining software in the Zope repository
--On 24. August 2007 19:55:35 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Andreas Jung wrote at 2007-8-24 19:35 +0200: ... Whitespace rules have a major impact on the readability of code. Readability is a major point when we talk of code quality. Readable code does not make code automatically but good code has to be readable. Lots of whitespace does not make the code more readable for all persons -- it does not for me, for example. Other rules are more important: * use speaking names * ensure that a unit (e.g. a function definition) can been seen in its whole * carefully document complex operations * combine a general overview with detailed source documentation. ACK on everything of that. But reading code comes before understanding code. And the visual impression of code has a strong impact on how we read code and on how we understand code. Rules (written or unwritten) exist to organize a certain aspect in life, work etc. Rules are (usually) made to satisfy the needs of a majority. If we organize code in a common repository then the code styles (or call them rules) tell the individual programmer how most programmers would expect how good code should like. When we write code and check it into a public repository the code was written to solve a particular problem but it has to follow the most basic rules that are set by the developers community as a whole. There is always place for personal preferences however there is some border.. Bringing it back to the point: Understanding matters, reading comes before understanding so rules about whitespaces, # of statements per line etc. really matters. -aj pgplqywBcAgHk.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: Guide for maintaining software in the Zope repository
--On 24. August 2007 02:37:01 +0200 Philipp von Weitershausen [EMAIL PROTECTED] wrote: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-so ftware.txt Thanks for writing this excellent guide. However I am personally unclear about specifying the dependencies and their version requirements (but this is more a setuptools issue than a Z3 specific one). Andreas pgpDOZIoeKX0u.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: zope.location/trunk/setup.py using pypi as homepage instead of svn.zope.org
--On 20. August 2007 20:22:50 -0400 Stephan Richter [EMAIL PROTECTED] wrote: On Saturday 18 August 2007 17:03, Philipp von Weitershausen wrote: * Please also don't forget to add a changelog entry in README.txt, especially if you're adding features. If there's no README.txt yet, this is a good time to give it one. It should start out with a simple paragraph and have at least one section called Changes. You could then use its contents as the long_description in setup.py. Other packages (e.g. zope.proxy or zope.publisher) can serve as examples. Why do the changes have to be part of the README file? That seems no good. I think a separate file is much better. I also prefer having separated files for the README and the changes. You can easily concatenate both files within your setup.py to generate the long_description. I doing this for my own projects. Andreas pgp7HWwT2N7Rx.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] [zope.sendmail] added encryption support
I added encryption support (SSL/TLS) to zope.sendmail on a branch: http://svn.zope.org/zope.sendmail/branches/ajung-encryption-branch/ I would appreciate it if someone could test it against their own SMTP servers since I could test it only against my own SMTP server. Tnx, Andreas pgpCpN92naaTE.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
--On 27. Juni 2007 11:36:23 -0300 David Pratt [EMAIL PROTECTED] wrote: Hi. I've tended to use system python against some better advice, but use but leave it clean since I am using buildouts. This really has had more to do with the convenience of using the system package tools for upgrading such as FreeBSD ports system. I've also been experimenting with CentOS and Fedora Core - so here yum comes into play. I think the best advice I have got from the discussion seems to be using a hand compliled python. I am almost at a point of thinking perhaps it my be best to use cmmi recipe for most system software on a stripped down server. I already need to patch a compiler and lxml will also only run on most up-to-date xml libraries so building these seems to make sense to make sure it does not choke. ...as Jim taught the audience during his Buildout tutorial some weeks ago in Potsdam: System Python is EVIL, EVIL, EVIL Andreas pgpGQeLsAKUQb.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] Can we have a 3.2.3 and 3.3.2 release?
Hi, I am currently trying to build the next Zope 2.9 and Zope 2.10 releases. I would like to ship the release with the latest Zope 3.2 and 3.3 *tagged* releases. At least Zope 2.9 refers (because of a bugfix) to zope.interface on the 3.2 branch. I definitely won't make 2.X releases with a svn:external mixture against branches and tags. Are there any objections creating tags for 3.3.2 and 3.2.3 based on the current code on the 3.3 and 3.2 branches? I see also problems coming up when using the satellite projects with their own release schedule within Zope 2. It will be hard to track changes and make a decisions which if of the packages needs to be updated. The Zope 3 meta-egg or how ever we will call it is most important since it has to describe the officially blessed versions of all packages. Andreas pgprP3ZWiCMJR.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 thought on backward compatibility and minimum versions
--On 31. Mai 2007 20:08:02 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Jim Fulton wrote at 2007-5-31 10:12 -0400: In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: - Suppose that we always had access to the latest released version, - Suppose that, within a major release, all releases were backward compatible, Then I assert that there is no *need* to specify a minimum release within a major release. I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. That's why one should have enough tests...although tests will never cover all cases. -aj pgpt1WGkPLSoR.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] Zope? PostgreSQL
--On 23. April 2007 09:20:14 -0400 Ariel Eduardo Morales Malpica [EMAIL PROTECTED] wrote: Hi. I'm working on a project and I'm using ZODB but my mentor advices me that this model of database will be so big after one or two years. He consider that because ZODB works with transactions and it's added to ZODB frequently. My mentor mentioned me PostgreSQL, but I don't want it, because is better for me use Objet Oriented Database than Relational Database. You pack and reorganize the ZODB like any other RDBMS. Don't tell us that a RDBMS won't grow :-) I don't know what to do. Is true that ZODB can be so big in few years? I'm implementing a Project Management System and I fear that it could be a problem after a few years. (use ZODB). Your issue isn't really of major interest when making a decision for/against the ZODB. The decision for example must depend on your data model and how relational it is. Both systems have their pros and cons. -aj pgpdh3cQwJjbH.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] z3c.sqlalchemy questions
--On 17. März 2007 11:12:19 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: Hi there, I saw Andreas Jung checked in z3c.sqlalchemy. Cool! Some questions though: * how is this different from zalchemy? It's providers better control about the mapper generation and should cover all the different use-cases we encounter right now with databases. You have certain levels of control about how mappers are generated. But wait for the documentation :-) * I see it uses ZopeTestCase, while it appears to be pure Zope 3 code otherwise, at least at first sight (and because of the package name). Why is this done? That's possibly a culprit of a former version. I'll have to clean it up. * The copyright isn't Zope Corporation. Under the current rules of the SVN repository (pre-copyright assignment to the Foundation), the copyright should be assigned to Zope Corporation and contributors. After transition it'll change again. No problem. I can change that. Andreas pgpYQcBFPr5b0.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] [German Zope Conference] Call for papers open
From: Andreas Jung [EMAIL PROTECTED] To: [EMAIL PROTECTED], zope@zope.org, zope-announce@zope.org, zope-dev@zope.org Subject: [Zope-Annce] [German Zope Conference] Call for Papers open Date-Sent: 1. Februar 2007 08:06:52 Dear Zope Community, the eighth Zope conference organized by the German Zope User Group (DZUG) will be held this year at the Potsdam Institute for Climate Impact Research from 4. to 5 June 2007 (near Berlin). The topic of the conference will be Zope in sciences. Proposals for talks and workshops can be submitted until 01.04.2007; http://www.zope.de/redaktion/dzug/tagung/potsdam-2007/dzug-conference-2007-call-for-papers-zope-in-science or http://www.zope.de/redaktion/dzug/tagung/potsdam-2007/dzug-conference-2007-call-for-papers-zope-in-science Both German and English proposals are highly welcome. You can find further information about the Zope conference here: http://www.zope.de/8-dzug-tagung Regards, Andreas Jung Assistant Chairman DZUG e.V. pgpjdTLS7YlH1.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] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner
Hi, the Zope 2 testrunner has a problem with zope.testing: http://www.zope.org/Collectors/Zope/2268 testbrowser/browser.py tries a from test import pystone import it picks up the test.py of the Zope 2 testrunner that tries to re-add some configuration options to testrunner.setup causing the initial error. Zope 2 or Zope 3 bug...any chance to get this fixed in zope.testing somehow? A workaround would be to move the import above PystoneTimer.pystonesPerSecond(). Any objections against this workaround? Andreas pgpZS1ZOIORY7.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] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner
--On 19. Januar 2007 14:41:53 -0500 Benji York [EMAIL PROTECTED] wrote: Wouldn't that change just defer the error until that function is called? (which the testbrowser tests do) The patch solves my problem and the testbrowser tests pass. Andreas pgpivN2G5VcEl.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] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner
--On 19. Januar 2007 15:08:49 -0500 Benji York [EMAIL PROTECTED] wrote: Andreas Jung wrote: --On 19. Januar 2007 14:41:53 -0500 Benji York [EMAIL PROTECTED] wrote: Wouldn't that change just defer the error until that function is called? (which the testbrowser tests do) The patch solves my problem and the testbrowser tests pass. I suspect that means the tests are insufficient, but I'm just pragmatic enough to be persuaded the patch should go in (with a comment as to why that import is done there). Done Andreas pgp9DZEqYuvcq.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 18. Januar 2007 08:29:57 -0500 Fred Drake [EMAIL PROTECTED] wrote: On 1/18/07, Andreas Jung [EMAIL PROTECTED] wrote: We're faster with new Zope versions than the W3C with any standard. So? The recommendation for XML 1.1 is already a done deal (a second edition was published last September), so there are already multiple specified versions. Since other version strings are allowed, whether there's a published specification or not, we don't want to make assumptions about what's there. Are the underlying frameworks (TAL, xml.parsers.pyexat) ready for XML 1.1? -aj pgpsZe3h8qPY0.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 16. Januar 2007 14:12:46 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: I am replying to the three proposals. First I have to kick the proposal of Tres (UTF-8 storage). We want unicode as internal representation for any kind of ZPT (both text/html and text/xml). Supporting unicode for text/html and utf-8 for text/xml would make code more complicated and lead to further unicode encoding conflicts. We're trying to solve this issue right now and I don't want to introduce a new construction site. So Martijn's and my proposal remain. They are not very different. In the end the behavior is almost identical. But I will adopt your suggestion to remove the preamble when storing the data internally (basically to avoid a possible encoding ambiguity). Andreas pgpxXQNoRi2gs.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 17. Januar 2007 22:49:11 +0100 Dieter Maurer [EMAIL PROTECTED] wrote: Andreas Jung wrote at 2007-1-17 17:48 +0100: ... So Martijn's and my proposal remain. They are not very different. In the end the behavior is almost identical. But I will adopt your suggestion to remove the preamble when storing the data internally (basically to avoid a possible encoding ambiguity). In future times, the preamble might contain information which should not be dropped, e.g. when there is an XML version different from 1.0. We're faster with new Zope versions than the W3C with any standard. For PageTemplates, we know that the encoding information is probably not relevant after the parsing -- unless we want to use it as a default for the Content-Type charset but I doubt that this is a good thing. If the Content-Type's charset is given explicitely, then the encoding of the XML declaration needs to be adapted to this value during the serialization anyway -- thus overriding any encoding present there. ? -aj pgpGl17OH27Hh.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 15. Januar 2007 13:26:16 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: How would you propose to parse the following unicode string? u?xml version=1.0 encoding=ISO-8859-1?foo / If your parser is unicode-aware then the encoding of the preamble does not matter since you have already unicode internally and can process your file totally on XML. If your parser isn't unicode-aware then you will likely convert it to utf-8 and work internally with utf-8 encoded strings. In fact xml.parsers.expat since to support unicode (it can return unicode strings to the handlers, see 'returns_unicode' property). However you need to reconstruct the XMl preamble when you reconstruct your XML from the parsed data. Or am I missing something? Andreas pgpQNy99FMGyu.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 15. Januar 2007 14:52:42 +0100 Martijn Faassen
[EMAIL PROTECTED] wrote:
Hey,
Gmane isn't updating so I can't really reply to the message (not visible
in gmane) that I want to, but I saw the following solution proposed:
def ourparse(text):
if isinstance(text, unicode):
text = text.encode('UTF-8')
xml_parser.parse(text)
now consider what will happen if you do the following:
text = u?xml version=1.0 encoding=ISO-8859-1 ?fooSome non-ascii
characters here/foo
ourparse(text)
what will happen is that text is converted to a UTF-8 string (8-bit
ascii). It's then passed to a hopefully compliant XML parser. This XML
parser sees an 8-bit ascii string, and checks the encoding header for
more information on the encoding of the string. It will therefore assume
the string is in latin-1. The parse will break with an obscure error and
the developer doing this is probably very confused.
ok, got it. But this problem can be solved easily by changing the encoding
within the preamble.
-aj
pgpi1m3ddiYBz.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 15. Januar 2007 15:44:01 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: Hey, On 1/15/07, Andreas Jung [EMAIL PROTECTED] wrote: [snip] ok, got it. But this problem can be solved easily by changing the encoding within the preamble. I would say refusing to guess and bailing out with an error message is better in this case. The Zen of Python: In the face of ambiguity, refuse the temptation to guess. Sorry but I don't get your point. What's happening with a XML inside a ZPT? - XML data encoded as XXX comes in (either by editing the XML file through the ZMI or FTP/WebDAV upload) - ZPT converts the encoded string to unicode based on the encoding in the preamble - for parsing it is up to the application to decide what to do with the data. It is not up to the editor to decide how the ZPT engine should deal with XML internally. The ZPT engine decides to serializes the unicode string as utf-8 and to fix the XML preamble (which will result in a valid XML file which should identical with the original file - except the encoding might be different). I still don't see what should ambiguous with this approach. Andrea pgpq0GGi0oSZu.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
--On 15. Januar 2007 22:15:46 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: My point is that: u?xml version=1.0 encoding=ISO-8859-1?fooSome non-ascii text/foo is confusing at best. One part of this says it's a unicode string, the other part says it's in encoding latin-1. The string above would be used for internal storage but *not* for processing. Btw. this is not different from storing HTML files as unicode string. An application must convert the unicode string back to a serialized string - either to the encoding as specified inside the preamble or to a 'general' encoding (that covers the unicode database) like utf-8 with changing the encoding inside the preamble - both are legitimate approaches. There is no ambiguity. A smart XML parser will represent a XML document *independent* of the source encoding in most general way (storing a textual content a unicode (or utf-8 at least). I still don't see what should ambiguous with this approach. Ambiguous in that the string seems to say it's in two encodings at once. You're then guessing: you're letting the Python string type trump the declaration. Then, since we've shown that leads to bugs, you propose actually change the encoding declaration of the XML document. I wonder what people then expect to happen upon serialization. In effect, your proposal would, I think, serialize to UTF-8 only, right? (in which case the encoding declaration can be dropped as it's the default. When you download a ZPT through FTP/WebDAV then the unicode representation of the XML will be converted using the 'output_encoding' property of the corresponding ZPT which is set when uploading a new XML document (and taken from the premable). So when you upload an latin1 XML file you should get it back as valid latin1 through FTP/WebDAV. When you download text/xml content through the ZPublisher then the ZPublisher will convert unicode textual content to some encoding which is either taken from an already set 'content-type: text/...; charset=X' HTTP Header or as fallback from the zpublisher-default-encoding property as defined in the zope.conf file. So the application can specify in both case the encoding of the serialized XML content. Where is the problem? Andreas pgpUMJ3Mc5Oh4.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] zope.tal.xmlparser.XMLParser() dislikes unicode
--On 14. Januar 2007 10:48:06 +0100 Bernd Dorn [EMAIL PROTECTED] wrote: I am not sure if this behavior is intentional?! Is the XMLParser supposed to deal with unicode strings or will it only accept a standard Python string? A workaround inside parseString() would to check for unicode and convert the string on-the-fly to a Python string with utf-8 encoding. This is possibly a limitation of the underlying Expat parser...any recommendation how to deal with this issue? IMHO it should only accept strings, because in the value should be a xml string and therefore always has to be encoded in 'utf-8' or in the encoding specified in the processing instruction. I disagree with that. Since Zope 3 is supposed to use unicode internally (at least that's the legend) it should support unicode also at the parser level. Other languages like Java store XML also as unicode strings and support parsing it. Andreas pgp8ib4BIWYFC.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] zope.tal.xmlparser.XMLParser() dislikes unicode
Hi,
the XMLParser.parseString() method raises an exception
File /opt/python-2.4.4/lib/python2.4/unittest.py, line 260, in run
testMethod()
File
/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/tests/test_xmlparser.py,
line 127, in test_xx
self._run_check(xml, ())
File
/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/tests/test_xmlparser.py,
line 106, in _run_check
parser.parseString(source)
File
/Users/ajung_data/sandboxes/Zope/Zope/lib/python/zope/tal/xmlparser.py,
line 77, in parseString
self.parser.Parse(s, 1)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
43-48: ordinal not in range(128)
if the string to be parsed is a unicode strings and contains some non-ascii
chars. The following snippet from a private unittest (test_xmlparsers.py)
shows the error.
def test_xx(self):
xml = unicode('?xml version=1.0
encoding=utf-8?fooüöä/foo', 'iso-8859-15')
self._run_check(xml, ())
I am not sure if this behavior is intentional?! Is the XMLParser supposed
to deal with unicode strings or will it only accept a standard Python
string? A workaround inside parseString() would to check for unicode
and convert the string on-the-fly to a Python string with utf-8 encoding.
This is possibly a limitation of the underlying Expat parser...any
recommendation how to deal with this issue?
Andras
pgpqL51ow2oL9.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SOAP support?
--On 8. Januar 2007 10:42:34 -0330 Rocky Burt [EMAIL PROTECTED] wrote: On Sun, 2007-07-01 at 14:54 -0500, Tres Seaver wrote: http://wanderingbarque.com/nonintersecting/2006/11/15/ I think that an add-on product which provided a SOAP server, implementing one of the competing semantics, could be interesting as a starting point, although it might not be terribly resuable. While I'm not necessarily a huge SOAP advocate (personally I just want RPC that works) that pasted link does a *very* good job of portraying a subjective view on how confusing soap is. That is... it's only propaganda. Sticking with just SOAP (no wsdl, no uddi, no xml schema) you can make services as simple as xml-rpc. I fully agree with that. SOAP is widely adopted but everything else on SOAP might be considers as YAGNI. Everything beyond standard soap tries to give it an infinite amount of power that is best compared to the extremely large number of corba specifications. This stuff is in some way too overengineered and too complex for being adopted in projects. Specs that are only understandable for the editors are specs for the trashcan. Andreas pgpd99CluCYAC.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] SOAP support?
Hi, I am actually looking at options for bringing SOAP support into Zope 2. Is there some SOAP infrastructure available in Zope 3 (or some add-ons) and might be re-used in a reasonable way? Andreas pgp3pdt4srmvH.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] Some ZPT insights needed
--On 6. Januar 2007 12:15:19 -0500 Stephan Richter [EMAIL PROTECTED] wrote: On Saturday 06 January 2007 12:03, Andreas Jung wrote: returns always unicode for non-strings but keeps standard Python strings as they are. I think we always require to return unicode text within Zope 3, which is a good policy so there should never be a regular string in there. this policy must be enforced? :-) I have some ideas how make resolving UnicodeDecode error configurable but I am not sure if this code should go into the Zope 3 or should remain in the Zope 2 core. Does Zope 3 has to deal with such kind UnicodeDecode errors? I think this is a pure Zope 2 problem at this point, no? We certainly have way of handling UnicodeDecode errors. If you can show that this could potentially be a problem in Zope 3 as well, I would be for adding your UnicodeDecode resolver to the Zope 3 core. It's possibly a major Zope 2 issue. However since we are putting more and more Zope 3 stuff into Zope 2 is becomes also (in some way) a Zope 3 issue. I just wonder if it would be better to move more logic into the related Zope 2 wrapper code (making it more fat) or putting it into the Zope 3 core... I have to brainstorm about it. BTW, weren't you in the room when we had the initial discussions pretty exactely 5 years ago? Yes, you were! :-) http://wiki.zope.org/zope3/Feb2002InternationalizationSprint Oh my god :-) Yet some more years we survived with Zope :-) -aj pgp7USG8D73j1.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: [Zope-dev] Is there an alternative to zdaemon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On 22. Dezember 2006 15:55:48 -0500 Jim Fulton [EMAIL PROTECTED] wrote: It has 2 major disadvantages: - It is ours. :) We are bearing the burden of maintaining it. This is offset by the fact that it hasn't required much maintenance. ..which is actually a sign of it-just-works. - It is largely undocumented. This makes it much harder to use than it needs to be. It also makes it under appreciated. I made a start at fixing this yesterday: http://svn.zope.org/zdaemon/trunk/src/zdaemon/README.txt?view=auto It isn't very hard to use, so documenting it isn't really all that hard. ...which is almost True for a lot of parts of the Zope 2 core :-) I wonder if we should be using some other daemon manager. Arguably, there's no reason for the Zope project to maintain one if something is available that does what we need. I think (meanwhile) that this is not enough to justify the replacement of a component. Replacing a Zope 2 component always caused some pain. So as a rule for replacing something in the Zope 2 core we consider those rules: - the replacement solves existing functional problems - it adds major functional benefits - no issues with backward compatibility, well tested etc. For the Zope 2 core we must be very careful about changing stuff. Stability and backward compatibility are much, much more important for the end-user than satisfying our replace-all-with-something-better drive :-) Don't get me wrong but we've done some minor mistakes with replacing stuff in the past and because of that I became a bit conservative about changing things. Of course I am only speaking for the Zope 2 core. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFjLuICJIWIbr9KYwRAgsRAJ9p3Td7KOmKzHzLn89nnQpSdYMtnwCcDyDR iKgZV5H76vnCpjqO3Mccrv4= =DYYW -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Python version for Zope 3.4 ?
--On 28. September 2006 16:17:54 -0400 Jim Fulton [EMAIL PROTECTED] wrote: We should definitely try to *support* Python 2.5, but we can't require it till Zope 2 has been certified for it. Why isn't Python 2.5 even supported at present? There are lots of test failures. Also, untrusted Python code doesn't work with 2.5 due to major changes in the compiler. (Zope 3 does almost no custom Python compiling, but it does do some.) Also Zope 2.10 dies under Python 2.5 with some famous crashs. -aj pgpbvMiP3G4pc.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: [Zope-dev] Re: [Zope3-dev] Release management refinements
--On 13. September 2006 20:12:50 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Philipp von Weitershausen wrote at 2006-9-13 11:05 +0200: Over the last couple of days we've been discussing Zope's new release cycle and the release management. I would like to sum up what seems to be the gist of those discussions: 9 month release period? --- I am almost convinced that we will make the same experience as the Plone people: when we strive for a 9 month release cycle, we will get a 12 month cycle... I think this is almost a law for software development: completing in time is the exception not the rule. That's not the point here. We are discussing about the release periods in order to do not flood the community with new versions but not about the reasons why we are often running behind our schedule...that's a different issue :-) Andreas pgpluNfeu86yX.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] Release schedule for Zope 2.11/3.4?
Hi all, since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts? Andreas pgpIoIUF7RJpI.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: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 12:28:10 +0200 Martijn Faassen [EMAIL PROTECTED] wrote: Andreas Jung wrote: since we are three month late with the current releas, it would make sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?! Is the reasoning here that since a release cycle has taken 9 months, so should the next? I'm not convinced expanding the release cycle is going to make us be on time more. Not really, just a thought in order to stick with the June/December cycle...but not really an important argument. If we want to stick with the half-yr cycles, we need to schedule the next release for around March/April next yr. Thoughts? That's one option. The other option is to stick with the plan and catch up, as Christian Theune proposed. It would mean getting very unambitious, but perhaps that isn't a bad idea. The idea of a release is to have a reasonably stable, known-good version of the trunk, and it doesn't matter that much how much the trunk changes. Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) 3 month for a new release cycle is just too short. We should not follow the IMO broken concept of release early, release often but to follow release regular, release solid. At least me I refuse to release something just for the sake of making a release at a certain date. Andreas pgpSiZKwtHn0V.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: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 13:06:05 +0200 Martijn Faassen [EMAIL PROTECTED] wrote: Andreas Jung wrote: --On 12. September 2006 12:28:10 +0200 Martijn Faassen [EMAIL PROTECTED] wrote: [snip] Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :) 3 month for a new release cycle is just too short. We should not follow the IMO broken concept of release early, release often but to follow release regular, release solid. At least me I refuse to release something just for the sake of making a release at a certain date. The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release. The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time. Not much happened during the three month or I did I miss something? Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release? We just don't have nothing new right now. Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. I've heard from my major customer but also from other ppl. IN December we would have *three* maintained versions 2.9, 2.10 and 2.11. We definitely can't deprecate Zope 2.9 in December because this version is required by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for the mid-future. So my personal impression right now is: we're flooding the community with new major releases and the community does not adapt those releases. My theory: a major part of the ppl running Zope are running Plone. on top of Zope...so with have to deal with this fact somehow. Andreas I think the egg-story is one candidate for being too big, and a possible reason to shift the release schedule. Then again, we do not need the egg story to land in the upcoming release anyway. Regards, Martijn -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpKzG0VOomAk.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
--On 12. September 2006 16:55:31 +0200 Martijn Faassen [EMAIL PROTECTED] wrote: Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.) I think that this is an edge case of time-based releasing: the absolute minimal work we need to do to make a time-based release is to release the trunk. Hopefully we'll be doing more than the minimal amount of work, and we'll actually fix some bugs before we release the trunk. A release can be a good opportunity to fix lingering bugs, after all. I am thinking since one hour about how to reply to Benji's proposal. It's not much acceptable. Major release have to be planned to a certain degree and must be tested (as good as we can) - means we must have alpha and beta releases. Everything else does not make sense to me. Zope 2 is not a kindergarten project and we use it for professional projects and we as a community should act (somewhat) professional. You can of course make daily snapshots available but most developers are using SVN checkouts and professional users don't want depend on snapshots - they expect official releases. Andreas pgp0MBvxjRcPa.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2 maintenance
--On 8. September 2006 14:13:05 -0400 Tres Seaver [EMAIL PROTECTED] wrote: When you check in a bug fix, you almost always need to: * Check in the fix on the current release branch branches(!). For Zope 2 we actually maintain 2.10, 2.9 and still a bit 2.8. -aj pgp2jdg3pXfMa.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] Testbrowser failure
Benji, when running the Zope 2.10b2 unittests I see the following tests failing (however this is not a blocker for the 2.10b2 release): Failure in test test_strip_linebreaks_from_textarea (zope.testbrowser.tests) Failed doctest test for zope.testbrowser.tests.test_strip_linebreaks_from_textarea File /develop/sandboxes/Zope-2.10/2.10.0b2/lib/python/zope/testbrowser/tests.py, line 222, in test_strip_linebreaks_from_textarea -- File /develop/sandboxes/Zope-2.10/2.10.0b2/lib/python/zope/testbrowser/tests.py, line 245, in zope.testbrowser.tests.test_strip_linebreaks_from_textarea Failed example: browser.getControl(name='textarea').value Expected: 'Foo\n' Got: '\nFoo\n' -- File /develop/sandboxes/Zope-2.10/2.10.0b2/lib/python/zope/testbrowser/tests.py, line 263, in zope.testbrowser.tests.test_strip_linebreaks_from_textarea Failed example: browser.getControl(name='textarea').value Expected: '\nFoo\n' Got: '\n\nFoo\n' Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgp0qwaTjdDF3.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] Testbrowser failure
--On 19. August 2006 17:25:39 +0530 Baiju M [EMAIL PROTECTED] wrote: This is already fixed according to: http://www.zope.org/Collectors/Zope3-dev/645 The fix is in 'ClientForm.py', this file is *not* set as an svn:external in Zope 2. Just setting this as svn:external to Zope 3.3 will fix this problem, otherwise update this module. Thanks, I copied over the file. Unfortunately svn:externals don't work on files but only on directories. -aj pgp8OKVxOs1qJ.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
--On 16. August 2006 08:36:55 -0400 Benji York [EMAIL PROTECTED] wrote: Jodok Batlogg wrote: Log message for revision 69426: Initial import from Lovely Systems repository Changed: A lovely.rating/ This package appears to depend on GPLed software (schooltool, specifically: http://svn.zope.org/lovely.rating/trunk/src/lovely/rating/interfaces.py?r ev=69429view=markup) I'm not sure it's appropriate to put it in the zope.org repo. huh? The contributor agreement says nothing about external dependencies. As look as the checked-in code is ZPL, your software can depend on any other external package (independent of its license). -aj pgpOGZy7r6NA3.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
--On 16. August 2006 15:42:41 +0200 Martijn Faassen [EMAIL PROTECTED] wrote: Anyway, nothing is said about dependency on GPL-ed code. That's a different debate. It's strictly not against rules, but it does mean one expectation is broken: one might want to expect that all code in the repository is freely usable without having to worry about GPL-provisions. This is not the case for code that depends on GPL-ed code. Even though this may be already a grey area for other reasons, it still makes sense to think about the intent and people's expectations when checking in a codebase. I don't see any grey area. The purpose of cvs|svn.zope.org is to be a repos for ZPLed software and the contributor agreement makes this purpose clear. But it was never the task of the repos to enforce a particular license - the ZPL - when building software with/on-top parts taken from svn|cvs.zope.org. It is up to the individual developers to take the software and use it under the terms of the ZPL. Andreas pgpX6qn1fBH4R.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
--On 17. August 2006 01:11:44 -0400 Tres Seaver [EMAIL PROTECTED] wrote: The appropriate thing here would be to remove the code which depends on the GPL, and then ask the foundation's permission before readding it. In the meanwhile, codespeak.net might provide a reasonable place from which to continue development of said code. That's extremly odd. Consider the following case: I am writing a ZPLed Zope product but include some migration shell scripts that call some common GPLed unix programs for a particular task...I wouldn't be allowed to checkin this software on svn.zope.org? The advice to move the code out of the repository is not really legitimate. Neither rules as given through the contributor agreement nor unspoken rules were violated. Once again: using GPLed software does not make your own ZPLed software automatically GPLed. -aj pgpbHaCbPdq3z.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: [Zope-dev] Should PageTemplate._text be a unicode or an encoded string in Zope 2.9.3?
--On 22. Juli 2006 15:34:01 +0200 Tino Wildenhain [EMAIL PROTECTED] wrote: Well, pagetemplate files are another thing. They have to deal with the lack of charset information of a filesystem file and what they do once they load the data is even another thing. Even filesystem pagetemplates should work with unicode internal, making it easy to recode them for output and combine with other potentially unicode stuff. huh?..even on the file system a pt file is encoded using some encoding. For an XML pagetemplate file the encoding is clearly defined through the BOM (if available) and/or the XML preamble. So the most reliable solution would be to use XML PTs only. -aj pgpfaEeT0wOes.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] The bug fixing problem
--On 16. Juli 2006 09:33:33 -0400 Jim Fulton [EMAIL PROTECTED] wrote: I'll note that *none* of the solutions include tests. Tests are often the bulk of the work. A submitter should not assume that just because a patch is provided, than someone only has to check it in. Submitter do often provide unit tests if you gripe about the missing tests. At least griping in the Zope 2 world worked out fine in the past :-) -aj pgpSNFRmFBpcW.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] State of Zope 3.3?
Hi, could someone please summarize the current state of Zope 3.3? When can we produced with the next releases? We are currently running a bit late behind our original schedule :-) Andreas pgpCDQqRbcoyW.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: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
--On 26. Juni 2006 11:25:05 +0100 Chris Withers [EMAIL PROTECTED] wrote: Philipp von Weitershausen wrote: It's dead from a maintenance point of view. If you still want to maintain it, be our guest. But you yourself said that maintaining too many branches is madness. My point is that we're creating too many branches ;-) Bascially 3 at this time. As I pointed out earlier it does not take too much effort e.g. to apply fixes to the 2.8 branch *as needed*. Andreas pgpptBSJWQq1z.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: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
--On 19. Juni 2006 16:25:32 +0200 Lennart Regebro [EMAIL PROTECTED] wrote: I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. We don't talk about Zope 2.7 which is dead. -aj pgpxH1ETQngYX.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: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
--On 18. Juni 2006 14:36:06 -0400 Christian Theune [EMAIL PROTECTED] wrote: However, Zope 2.8 is still available for stable download ... so we currently have 7 branches to watch out for. Yes, but in most cases a fix only affects only Zope 2 or Zope 3. So we are back to 3. -aj -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpIvbmC9paLN.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] Zope 3.3.0 beta 1 released!
--On 9. Mai 2006 11:02:33 +0530 baiju m [EMAIL PROTECTED] wrote: On 5/9/06, Stephan Richter [EMAIL PROTECTED] wrote: Hello everyone, The Zope 3 development team is proud to announce Zope 3.3.0 beta 1. Congratulations to all worked behind this release! I was trying to install this release using Python 2.5 alpha2 There was some warning like this from some modules : Warning: 'with' will become a reserved keyword in Python 2.6 Maybe substitute `with` with `with_` And when I run server, there was another warning : /extra/Zope-3.3.0b1p25/lib/python/zope/configuration/config.py:184: DeprecationWarning: the gopherlib module is deprecated Anyway this release is running in Python 2.5 Should I report this in collector? Python 2.5 is not officially released and not offically not supported and not recommended for Zope 3. So stick with the supported versions. -aj -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpLy6F8Jq7IA.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] Zope and a RDB
--On 6. Mai 2006 10:12:21 +0200 John Catt [EMAIL PROTECTED] wrote: Hello, JSR 170 http://www.cmswatch.com/Feature/123 http://www.artima.com/lejava/articles/contentrepository3.html seems to be the next standard of the CMS world. Wouldn't be a good thing to make Zope 3 compatible with this standard ? I think Nuxeo with its Zope 3 ECM project is working on JSR 170 support. See z3lab.org. -aj -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpr2HOwXPxRU.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: [Zope-dev] Reminder: Feature Freeze May 1
--On 21. April 2006 08:55:26 -0400 Jim Fulton [EMAIL PROTECTED] wrote: Don't forget that the feature freeze for the June release is May 1! That is only 10 days away! New features should be check in in a *stable* form by then. While we won't necessarily do a beta release then, anything checked in for the new release must be ready for a beta release when it is checked into the trunk. We need agree on a release schedule. Perhaps we should agree on a schedule on IRC? Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpJJVcyZBBTW.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
--On 14. März 2006 06:23:33 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Budding in: It would be nice to be able to use Zope schema for conversion and validation. ZConfig was developed at around the same time as Zope schema. The ZConfig developers fealt they couldn't wait and reuse the work on zope.schema. and developed their own schema system. It sucks to have to maintain 2. It's also a pain for people who might want to use ZConfig's to have to figure out another. ZConfig obviously fits your brain. It doesn't fit mine at all. Could you please explain how zope.schema would deal with hierarchies? As I mentioned earlier the file format is uninteresting at this point. Having an easy and flexible framework for defining a configuration schema should be the goal and I have currently no idea how you would define some more complex configuration schemas using zope.schema. -aj --- - Andreas JungZOPYX Ltd. Co KG- - E-mail: [EMAIL PROTECTED] Web: www.zopyx.com, www.zopyx.de - --- pgpOYKkAlIFTj.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration
--On 14. März 2006 17:17:12 + Laurence Rowe [EMAIL PROTECTED] wrote: I know that everyone here in pythonland seems to hate xml, Nothing but a stupid rumor :-) it may not be pretty, but we have to use it for at least some things anyway. We probably all spend quite a bit of our time writing xhtml, why not just standardize on one format. Please, I don't want to learn any more configuration languages. Where is the effort for learning ZConfig or INI-style configuration when you edit pre-configured zope.conf file? -aj pgp4wGdonGqDw.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[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] 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
Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration
--On 9. März 2006 18:21:16 +0530 baiju m [EMAIL PROTECTED] wrote: I don't know whether there is something for Zope, anyway just posting. http://groups.google.co.uk/group/turbogears/browse_thread/thread/f77979a d0e1dacd0/b97cc6d6af9439d6?tvc=2q=turbogears+configobj#b97cc6d6af9439d6 http://www.voidspace.org.uk/python/configobj.html ugly and obscure. -aj pgp9DwP4Nf1Jn.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration
--On 7. März 2006 06:51:00 -0500 Chris McDonough [EMAIL PROTECTED] wrote: My $.02: I suspect it might be better to just use XML than configparser as a ZConfig replacement. The config format is a stretch under CP due to the lack of hierarchy. I'm beginning to think the don't make admins use XML argument should die. Everybody knows how to edit XML nowadays, and if you need hierarchy, its familiarity is tough to argue with. XML as config format must die :-) ZConfig has the right balance between a stupid INI format and XML. The weak point at this discussion (as I mentioned earlier) is that we are discussion about a format and not about a flexible configuration framework that solves the problems at ZConfig has. The format used at the end to feed the framework with data is pure syntactical sugar. The idea to use schemas makes sense especially because schemas seem to provide everything you need right now. The only thing I have no clue about is how one would define hierachies through schemas (possibly through nested schemas)? Writing a parser for some kind of INI format or ZConfig-style parser is an engineering task for an average programmer..I think we should discuss the framework and not a particular format (I agree with Dieter: it's unreadable and only applicable to small configuration files). -aj pgpFDjuYpV0Op.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
--On 4. März 2006 21:26:30 -0500 Jim Fulton [EMAIL PROTECTED] wrote: At: http://dev.zope.org/Zope3/UseConfigParserForHighLevelConfiguration Is a proposal for using ConfigParser, rather than ZConfig for high-level configuration. Comments welcome. -1 The right way would be to refactor ZConfig and decouple it in a reasonable way from its dependencies. ZConfig is a very smart module to define configurations and to verify configuration files. Replacing ZConfig with a very dumb format and moving more complexity (verification, argument conversion etc.= into the app layer is the wrong way. Apps should not have the need to deal with such low-level issues. -aj pgpGNV4s1KHzI.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
--On 5. März 2006 13:56:38 -0500 Jim Fulton [EMAIL PROTECTED] wrote: The right way would be to refactor ZConfig and decouple it in a reasonable way from its dependencies. I think this would be a major rewrite. Possibly but I don't consider that to be a strong argument for introducing a weaker mechanism. They have to deal with it now, but now it's really hard. I think that a simpler approach would allow much simpler configuration support. To extend ZConfig now, you have to create XML schema descriptions, and have deep knowledge of how ZConfig works. Why do you think it's better to have to create a monolithic schema for all applications bits that want to use the configuration file, rather than letting individual applications define how to read their own data independently? A monolithic schema is of course a problem. I am sure it could be solved by refactoring ZConfig. There could still be frameworks to make handling configuration data easier. I agree but I really dislike the idea of flattening a hierarchical structure into a INI-like format. Having /x/y/z as section names looks both funny and somewhat unprofessional. The format looks as if would have been invented by a first grader. There is no question that ZConfig has the problems you described. But I consider such a flat representation as poor and a step back instead of a step forward (independent of the effort needed to simply and refactor ZConfig). -aj pgpzRPpYccAEU.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
--On 5. März 2006 14:43:48 -0500 Jim Fulton [EMAIL PROTECTED] wrote: There is no question that ZConfig has the problems you described. But I consider such a flat representation as poor and a step back instead of a step forward (independent of the effort needed to simply and refactor ZConfig). I agree, however, I think that there are other benefits of a move to ConfigParser that far outweigh this disadvantage. Let's try to approach from the other side. We both agree at ZConfig sucks at some point. We need something else. The something else should be provide a similar functionality as ZConfig: - some support for hierarchies - schema-based - validation - default values - local configurations, no global schema In the first place such a framework would be independent of any input format. A ZConfig-style parser or a .INI parser could use such a framework to make configuration information available through a unique API. So the basic problem of this whole issue is how such a framework would look like, how a schema-definition would look like etc. Writing a parser that adopts a particular input format to the abstract configuration framework is at best an engineering challenge and the decision to use a ZConfig-style or an INI-Style configuration file format as default is like a personal preference for beer or wine (beer for the mass, wine for the power users :-)) -aj pgpzzcQaftHUO.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Two visions
--On 28. Februar 2006 16:06:55 +0100 Philipp von Weitershausen [EMAIL PROTECTED] wrote: I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. +1 -aj pgp3JPYef1z8N.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: [Zope-dev] Re: [Zope3-dev] Two visions
--On 27. Februar 2006 21:57:46 -0500 Stephan Richter [EMAIL PROTECTED] wrote: On Monday 27 February 2006 10:37, Jim Fulton wrote: 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 2) In an alternate vision, Zope 2 evolves to Zope 5. As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code. Like it or not...I agree with Jim's vision will just be the reality. As long as we do support Zope 2 we will move more and more Z3 technology into Zope 2 which will strengthen Zope 2. I still do not see that Zope 3 will provide everything we need to build large-scale applications. Having CMF 2.0 and having some future Plone version running on top I don't see that Zope 2 will fade out. Andreas pgpUc3AvCaf1Q.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
--On 12. Februar 2006 19:18:51 +0100 Max M [EMAIL PROTECTED] wrote: a href=# tal:attributes=href here/absolute_url; title here/title; id here/getId tal:content=here/TitleTitle/a I could write this: a href=here/absolute_url id=here/getId title=here/Title tal:attributes=href; id; title tal:content=here/TitleTitle/a That's really syntactical sugar. The purpose of the tal: names is clearly to tell the parser to do _something_ with the value of an attribute. Now should a parser guess if the value of an attribute is something to be processed or not? -1 for such ideas. -aj pgpfoecidL4qX.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] Release schedule and deprecation decisions
--On 5. Februar 2006 12:11:08 -0500 Jim Fulton [EMAIL PROTECTED] wrote: A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. - We will support deprecated features for 1 year. I consider there to be decisions. :) Also +1 -aj pgpSOq50rodlE.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: ZConfig and other formats for ZCML
--On 23. Januar 2006 18:29:18 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: And the intended audience of ZCML is a very different audience - developers versus sysadmins. This separation is artificial. I've never seen a single Zope installation where a system administrator had to care about Zope configuration issue. There was always a Zope developer in charge to deal with configuration issues. -aj pgpxjpq6I6vAS.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: ZConfig and other formats for ZCML
--On 23. Januar 2006 19:06:02 +0100 Martijn Faassen [EMAIL PROTECTED] wrote: Anyway, this whole discussion may be moot; Jim's proposal is rather hard to interpret for people in this thread, so now I don't know anymore what he's proposing. :) I agree. I seconds Philipps proposal to simplify ZCML wherever possible and to make it less verbose. -aj pgpMqxRvCzLMN.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: [Zope-dev] December release post-mortem
--On 18. Januar 2006 07:36:35 -0500 Jim Fulton [EMAIL PROTECTED] wrote: In the future, if someone introduces a major change, they *must* be committed to be available to deal with issues that arise during the release cycle. Perhaps we need to pick different release dates to avoid holidays. Stephan has suggested moving the dates up to November/May rather than December/June. +1 for moving the dates. Speaking for the Zope 2 release: - the zpkg chances were introduced very late and it was somewhat annoying to deal with this almost untested changes during the betas (not blaming Philipp here, he has done a tremendous lot of work) In addition such major changes should happen on a branch and not on the trunk and such changes should be started early before the next release (not week or two before the first beta). And then there are the Windows releases. Making Zope 2 windows releases is very painful and there don't seem to be many people willing to help. We've avoided the pain for Zope 3 by being less ambitious. We let distutils do most of the work. The result is that making a windows release takes minutes and is highly automated, but the experience for the end user is less than ideal, Many would rightfully argue that it is inadequate. What we need is a release process that is as easy as the Zope 3 windows release process and produces a result as usable as the Zope 2 windows release. I'm not sure exactly what the answer is, but I am sure we need to take a fresh approach. Whatever approach we take needs to be highly automated and must not require a lot of specialized Windows expertise. The basic problem with the windows release is that there is currently nobody in charge for the windows release (although Tim is again doing working on the Windows side, ALL HAIL TIM). Note that I'm banking heavily on eggs without personally having worked with them much. I'm very hopeful that we can make them work for us. In the end, I consider the December release to be largely successful, given the challenges. It was basically a birth with some pain :-) These were some of my reactions to this first attempt at time-based releases. What do other folks think? I think 2.9.0 is the _real_ 2.9 beta which will be widely used by ppl :-) -aj pgpCRLW9aQMe0.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: [Zope-dev] December release post-mortem
--On 18. Januar 2006 10:31:03 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Andreas Jung wrote: ... The basic problem with the windows release is that there is currently nobody in charge for the windows release (although Tim is again doing working on the Windows side, ALL HAIL TIM). I'll repeat or emphasis that the windows release process needs to be simple enough that *I* can do it. Well, that's a perfect goal :-) But my experience with doing slightly simple programming tasks on Windows is that Windows will slap you wherever possible - even when you're trying to solve simple problems. I stopped dreaming that anything on Windows works as it should. just-being-a-frustrated-windows-hacker-(sometimes), Andreas pgpTf8XcFlc8o.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: RFC: abolishing python: expressions in ZPT TALES
--On 29. Dezember 2005 10:08:03 -0330 Rocky Burt [EMAIL PROTECTED] wrote: Andreas Jung wrote: Another argument against removing python expressions: in Zope 2 scripters could directly modify and test templates, script etc. (also using the skins tool). In Z3 you have to restart the server at least for view classes (but not for templates). Personally I would say implement logic that allows view classes to be reloadable rather than relying on zpt for exactly this reason if this is indeed something developers need/want (I would love for such a feature). This was also one of the nice things about writing python scripts as a skins item with CMF as it was instantly reloadable. To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) -aj pgpC5PO9Jq6U4.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] attr name space (was: RFC: abolishing python: expressions)
--On 30. Dezember 2005 08:22:18 -0700 Jeff Shell [EMAIL PROTECTED] wrote: The same would probably be relevant for tal:defines, something like: div define:mammals=here/getMammals define:fish=here/getFish / - It looks nice! :) That's relative. It would call it: syntactic sugar. -aj pgpum1nYYWhKO.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] attr name space
--On 30. Dezember 2005 11:50:16 -0500 Jim Fulton [EMAIL PROTECTED] wrote: I'm gonna stay out of this except to note that this discussion should be happening on the ZPT list (zpt@zope.org), as it affects much more than Zope 3 (or even Zope for that matter). Wasn't the ZPT list considered obsolete some time ago? -aj pgp35d5UMHk2k.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: abolishing python: expressions in ZPT TALES
--On 28. Dezember 2005 17:29:11 +0100 Andreas Jung [EMAIL PROTECTED] wrote: --On 28. Dezember 2005 11:04:09 -0500 Jim Fulton [EMAIL PROTECTED] wrote: What do you all think? +1 Views make it much easier to keep Python code in Python modules. python expressions should be strongly discouraged in ZPT, IMO. -0.5 - there a situations especially when prototying things when view classes are just overhead and counterproductive. Another argument against removing python expressions: in Zope 2 scripters could directly modify and test templates, script etc. (also using the skins tool). In Z3 you have to restart the server at least for view classes (but not for templates). -aj pgp4b3r3tr8eh.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] [ZPT] API of pt_getContext()
I am currently working on the integration of Zope 3 ZPTs into Zope 2. This works so far expect that I get an error Macro expansion failed when creating a new ZPT. in pagetemplate/pagetemplate.py there is the following code: self.pt_render(self.pt_getContext(self, None), source=1) That does not match with the interface definition: def pt_getContext(**kw) and that does match with the implementation of pt_getContext() in pagetemplate.py: def pt_getContext(self, args=(), options=_default_options, **ignored) And the original ZPT implementation of Zope 2 defines: def pt_getContext(self): So my theory is that the pt_getContext() call above is wrong?! Why passing 'self' and why 'None' as non-kw-argument? This makes no sense to me. What is the intention in this case? Andreas pgpGwRElEzF6V.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
--On 8. Dezember 2005 13:57:10 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Andreas Jung wrote: --On 8. Dezember 2005 11:47:10 -0500 Tres Seaver [EMAIL PROTECTED] wrote: Yep. Nobody has complained to us about this yet. I personally do not use ZEO, so I could not fix the issue anyways. If twisted and ZEO are incompatible, then twisted needs *never* to be the default; ZEO is an essential part of Zope's real world story. I can't imagine even *developing* without ZEO, much less deploying applications in production. This raises the question about what projects are important and what are the risks. Replacing the publisher appears to me like nice-to-have project but it does not appear so important to me. I would prefer to get e.g. the ZPT implementation from Z3 into Z2. This would resolve hopefully most of the current annoyances with ZPT in Z2. Cool, then work on it. Will do! -aj pgpgDoxjGdKxY.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2.0 Beta 1 released
--On 7. Dezember 2005 14:08:29 -0500 Craeg Strong [EMAIL PROTECTED] wrote: I am using FC4 and Python 2.4.1 comes built in. This is just a play/development machine, nothing needs to be airtight. Can anyone provide a summary of what is likely to go wrong using Zope 3.2b1 with Python 2.4.1 rather than the recommended/supported 2.4.2? I checked the release notes for python 2.4.2, but there was nothing obviously important. Installing Python 2.4.2 from the sources takes you two minutes and it is in general better to use your own build Python interpreters vs. the system Python installations. -aj pgplzE6Apdz3D.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] Time for a beta!
--On 5. Dezember 2005 09:52:38 -0500 Stephan Richter [EMAIL PROTECTED] wrote: On Sunday 04 December 2005 14:35, Jim Fulton wrote: Stephan, what needs to be done to get a beta out? Okay, I'll cut it. It might take me till Wednesday, though. Will do the same for Zope 2.9 on Wednesday...eeek -aj pgpd0mOHXlyBw.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] zope.app.application.HTTPPublicationRequestFactory interprets text/xml requests as XML-RPC
--On 23. November 2005 18:39:39 + Chris Withers [EMAIL PROTECTED] wrote: Andreas Jung wrote: For Zope 3.2 publishers are pluggable and can be configure through ZCML. The registration is based on the request method and mime-type. Then what is this zope.app.application.HTTPPublicationRequestFactory that John has found? I can't remember. Zope 3 uses at that point a bunch of abstractions you can't keep in mind without dealing with the code every day :-) -ajh pgp8ZRPkOOvLm.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: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
--On 24. November 2005 07:09:00 +0100 Morten W. Petersen [EMAIL PROTECTED] wrote: We are not even getting bug reports. Likely because Zope 3 *just-works* :-) -aj pgpC8hG89OHHQ.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] zope.app.application.HTTPPublicationRequestFactory interprets text/xml requests as XML-RPC (was: [Zope] Hard-coded Content-type:text/xml as xmlrpc in Zope (2.8.1))
--On 22. November 2005 20:37:16 +0100 Dieter Maurer [EMAIL PROTECTED] wrote: You should complain about this misfeature on zope3-dev@zope.org. Definitely, there should not be a fixed (not configurable) association between text/xml requests and XML-RPC as text/xml can be interesting for the application and for SOAP. For Zope 3.2 publishers are pluggable and can be configure through ZCML. The registration is based on the request method and mime-type. -aj pgpxRnn3mdlXL.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Re: branched Zope 2.9
--On 17. November 2005 07:45:48 +0800 Philipp von Weitershausen [EMAIL PROTECTED] wrote: Andreas Jung wrote: --On 16. November 2005 14:03:05 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Does this mean that the existing 2.9 branch needs to be removed and that the trunk remains frozen? Didn't Florent delete the branch? Obviously he did not as I assumed. So in this case Philipp needs to commit his fixes to the existing 2.9 branch and the HEAD and the HEAD would be open for new code. Yes, I comitted all the changes to both the trunk and the Zope 2.9 branch. They should be identical. So at this point I don't care whether we get rid of it again and recreate it at a later point or simply leave it. Again, Andreas' call. Delete the 2.9 branch at this time just for the sake of deleting it would be stupid. I hope that Philipp will finish his work soon so this this issue is not so important. That means: 2.9 branch: feature frozen, open for fixes of course HEAD: open for whatever... I hope the things are clear now :-) Andreas pgpwLgszI8EUV.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Re: branched Zope 2.9
--On 14. November 2005 14:25:17 -0500 Jim Fulton [EMAIL PROTECTED] wrote: On Tue, 2005-11-15 at 00:20 +0800, Philipp von Weitershausen wrote: Florent Guillaume wrote: BTW I'm for removing the 2.9 branch for now. You didn't, so I presume 2.9 branch stays? It's important to clear the status of this branch because bugfixes need to be merged to it (see my email about Tres' bugfix, for example). This is Andreas' call. Philipp is still working on the zpkg issue and he will require some more days. As soon as this issue is resolved will cut the 2.9 branch and head for the 2.9 b1 release. Andreas pgpS4CEBeYA0B.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: [Zope-dev] Re: branched Zope 2.9
--On 15. November 2005 00:20:00 +0800 Philipp von Weitershausen [EMAIL PROTECTED] wrote: Florent Guillaume wrote: BTW I'm for removing the 2.9 branch for now. You didn't, so I presume 2.9 branch stays? It's important to clear the status of this branch because bugfixes need to be merged to it (see my email about Tres' bugfix, for example). By the way, in the future, just to avoid confusion, I think release branches should be made by the release manager (in thise case Andreas Jung). They clearly fall under their responsibility and supervision. Jup. So when I see clear the only problem is the zpkg issue (where Philikon is working on it)...right? -aj pgpcdWU0FoWEl.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] branched Zope 2.9
--On 13. November 2005 10:55:19 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Do you also track bugs? I can only what I know of. If there are bugs then they should be documented in the collector. I'm not sure how, aside from feature completeness, we decide we're ready for a beta. For Zope 3, we prioritize bugs as critical to indicate that they must be resolved before a release. Is there a similar process for Zope 2. There are no 2.9 related issues in the collector but I assume there a bunch of unreported issues. I realize that you make a significant contribution just making the release. Jup. I'm not sure if you are also trying to be the one to decide (or to manage the decision) to make releases. The decision to make release basically depends on the OK from everyone having contributed lately to the trunk. This affects basically the Five contributions, the zpkg changes and some changes from you. So that's why was asking about the status (see my other posting on zope-dev). We currently have 9 critical Zope 2 bugs. Where are they documented? They should be documented in the collector or least there should be some communication on zope-dev about ongoing release issues. I can not follow every discussions on IRC (time constraints, different timezones).. Andreas pgpV2rQD1q6lz.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] branched Zope 2.9
--On 13. November 2005 11:25:21 -0500 Jim Fulton [EMAIL PROTECTED] wrote: ... http://www.zope.org/Collectors/Zope/collector_contents?searching=yepSear chableText=status%3Alist%3Aignore_empty=Acceptedstatus%3Alist%3Aignore_ empty=Pendingclassifications%3Alist%3Aignore_empty=bugimportances%3Alis t%3Aignore_empty=critical Ups, I got your point. I thought you were talking about 9 critical error *directly* related to Zope 2.9 e.g. the packaging issue, Five etc..I am aware of this issues. Issue marked by the issuer as critical might appear critical to them..so one needs to decide which issues are blockers. Andreas pgp9Fw9W71QVq.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: branched Zope 2.9
--On 13. November 2005 20:33:01 +0100 Florent Guillaume [EMAIL PROTECTED] wrote: Anyway if we want to go further we need to schedule bug days. One per week, or something like that. Otherwise nobody will set aside the time to discuss, investigate and fix the current bugs. Right, right, but there must be enough people to fix bugs...the last bugs days we had were not sooo successful. There is no way to enforce contributors to fix bugs. Speaking for myself I look at bugs from time to time and see what I can fix. There are bunch of bugs where you don't know if it is a bug or a feature...it's basically a question of having time... -aj pgpSbJILq4iLv.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: branched Zope 2.9
--On 14. November 2005 02:42:31 +0100 Florent Guillaume [EMAIL PROTECTED] wrote: [Reply-To and Followup-To zope-dev] Andreas Jung wrote: Anyway if we want to go further we need to schedule bug days. One per week, or something like that. Otherwise nobody will set aside the time to discuss, investigate and fix the current bugs. Right, right, but there must be enough people to fix bugs...the last bugs days we had were not sooo successful. Then let's try again :) You're going to organize them? :-) -aj pgpSDOb3FCt8m.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] branched Zope 2.9
--On 12. November 2005 22:08:38 -0500 Chris McDonough [EMAIL PROTECTED] wrote: FYI (this is mostly for the benefit of the Five folks), I've created a Zope 2.9 branch from the trunk as of about 10 minutes ago. This branch is frozen for feature work; it may need some changing of externals to reflect what we want the initial version of Zope 3 that we want 2.9 to ship with. I don't know what that version is, so this is a note to say that if these externals changes get made on the Zope 2 trunk, please also make them on the 2.9 branch. I would have created the 2.9 branch in case the current trunk would be ready to branch. At least one week ago there were unresolved issues (with zpkg I think) that deferred the 2.9 release (scheduled for last Monday). So in general what is the current state of the remaining work to get 2.9b1 out to the people? Andreas pgpdCmBJ7gtTt.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] fssync and export/import for Zope 3
--On 7. Oktober 2005 11:25:00 -0500 Garrett Smith [EMAIL PROTECTED] wrote: - The export/import functionality people are used to with Zope 2 I suspect the export/import feature alone will be attractive to anyone with production servers, as it enables object-specific backup and restore. Export/import is likely much more important than being able to edit content on the filesystem. Writing simple mechanisms for exporting/importing schema-based content to XML/from XML should not be so hard. -aj pgpkOWZo95InH.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] error checking in included ZCML files
From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Error checking in included zcml files Date-Sent: Samstag, 21. Mai 2005 13:03 Uhr Hi, I tried to refactor the configure.zcml of TextIndexNG3 into a configuration file which is related to the core engine and one file that contains Zope 2 specific directives (browser:view etc). The main configure.zcml (to be used by Five) is in Products/TextIndexNG3/configure.zcml and contains a line include package=textindexng file=configure.zcml / So far so good.just for testing purposes I added the an utility directive multiple times (which identical attributes) in Products/TextIndexNG3/src/textindexng/configure.zcml .I restarted Zope and expected that Zope would not start because of the identical directives...however it came up. Adding the same identical in Products/TextIndexNG3/configure.zcml caused an exception when Zope was starting. So why do we have different behaviour here? Bug or Feature? -aj --- - Andreas JungZOPYX Software Development and Consulting - - E-mail: [EMAIL PROTECTED] Web: www.zopyx.com - --- pgpkR8Cg20Nxi.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] getUtilitiesFor() fools me
Hi, I restructured the TXNG 3 source so that the core implementation can be used as package (within Zope 2.8/Five) ...so far so good. The configure.zcml under Products/TextIndexNG3 contains several statements of the form: utility provides=textindexng.interfaces.IConverter component=textindexng.converters.doc.DocConverter name=application/vnd.ms-word / Inside a browser view class there is the following method: def get_converters(self): return all available converters from zope.app import zapi from textindexng.interfaces import IConverter print [x for x in zapi.getUtilitiesFor(IConverter)] return zapi.getUtilitiesFor(IConverter) But the getUtilitiesFor() call always returns nothing. In my case textindexng/interfaces contains several files with interfaces and all interfaces are aliased in interfaces/__init__.py. The textindexng package itself lives unter Products/TextIndexNG3 and sys.path is extended in Products/TextIndexNG3/__init__.py to be able to import the textindexng package without the need to use Products.TextIndexNG3 in importsso any ideas why the utility machinery refuses to return the registered utilities for the given interface? A Andreas pgppEgVgAzNmB.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
