Re: [Zope3-dev] RFC: undeprecate auto-message id translation
Martijn Faassen wrote: Dmitry Vasiliev wrote: [snip] * currently you can translate any string (not only a message id) like this: p tal:content=string: STRING TO TRANSLATE i18n:translate=/p In this case the string will be automatically converted to message id and then translated. I think we definitely shouldn't translate any string, only message ids. This is an interesting usecase. If I understand you correctly, the question, put a bit broader, is the following: p tal:content=some/call i18n:translate=/p Should this translate whatever string (not message id) is returned from some/call or should it leave it alone? You seem to be arguing it shouldn't. I can also see a usecase where this would be handy -- you can just add the string to your translation dictionary without having to mark anything in your codebase. This is a *disadvantage* if you're already using extraction tools, though. I think only message ids should be translated since you always need to have a message id at some stage anyway to be extracted by i18nextract. Translating a string (not message id) returned by 'tal:content' is just a chortcut for lazy programmers. :-) -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/testbrowser/ fix bug caused be impedance mis-match between Mechanize and zope.testbrowser
Benji York wrote:
+def _quote(self, url):
+# the publisher expects to be able to split on whitespace, so we have
+# to make sure there is none in the URL
+return url.replace(' ', '%20')
Perhaps we should be using urllib's quote function insteead of this
class method?
What happens with urls have other dodgy characters in them (?;:, etc)?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Stephan Richter wrote: I wonder whether a similar approach as the one taken for the Twisted server migration is possible. There, if you have an instance running on ZServer an upgrade will not cause the switch to Twisted, since your startup script still refers to the old server code. You explicitely have to change your startup script to start using Twisted. I think this is the way to go and a zope.conf option would be an ideal way of making the choice... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/testbrowser/ fix bug caused be impedance mis-match between Mechanize and zope.testbrowser
On Thursday 08 December 2005 04:04, Chris Withers wrote: What happens with urls have other dodgy characters in them (?;:, etc)? I hope it would have sometimes a ? in them, since this is a totally valid character. also : will be in 90% of the URLs. The idea here is that we want to support those silly apple URLs. Regards, Stephan ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: Just one thing that struck me right now. ZServer uses medusa/asyncore and twisted has it's own 'main loop'. How do they play together in Zope 3? Or they dont? They don't. Either you use ZServer or you use Twisted, but not both. So if you want to use Twisted-specific packages, like the scheduler, you have to use twisted, otherwise you are out of luck. I think this is totally fine. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So if you | want to use Twisted-specific packages, like the scheduler, you have to use | twisted, otherwise you are out of luck. I think this is totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So | if you want to use Twisted-specific packages, like the scheduler, you | have to use twisted, otherwise you are out of luck. I think this is | totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? Yep. Nobody has complained to us about this yet. I personally do not use ZEO, so I could not fix the issue anyways. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Stephan Richter wrote: On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So | if you want to use Twisted-specific packages, like the scheduler, you | have to use twisted, otherwise you are out of luck. I think this is | totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? Yep. Nobody has complained to us about this yet. I personally do not use ZEO, so I could not fix the issue anyways. I don't expect other people for me to fix this for me, but I suggest that this be noted somewhere where it can be seen, because ZEO is quite important for us running larger sites. Even though many people do not use ZEO themselves, when considering and comparing web-app frameworks, it is a major pro for Zope to be able to provide cluster capabilities out of the box. So the capability to use an alternative to ZServer for ZEO sites should, I suggest, be considered as a desirable future feature by ye Zope3 Gods. My 0.02 € /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. Lyrics applied to programming application design: emancipate yourself from mental slavery - redemption song, b. marley ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] logout patterns: a small proposal
There are a surprising number of components in zope.app designed to help with logging out. They are all trying to solve the problem that some authentication can't log out, so you shouldn't show logout links then. I only care about the pluggable auth in zope.app.authentication. Therefore what I want is a way to determine whether the credentials plugin used supports logout. I want this to be dynamic, responding to TTW configuration of the pluggable auth, which the current zope.app solutions are not. Jim suggested that a subscriber to principal creation event might scribble an attribute on the (transient) principal object that indicated that the credentials plugin used to create the principal supported logout. This would be easy to do, light-weight, robust (i.e., even in the face of multiple active credentials plugins), something that I could do without committing the zope project to the solution, and easy to use (my tal could do something like tal:condition=request/principal/canLogout|nothing). The problem is that the principal creation event does not include the credentials plugin used by the authentication. The easiest way to approach this, given the current pluggable auth design, is to add a 'credentialsPlugin' attribute on the info object passed to the principal creation factory. The 'credentialsPlugin' attribute would have a reference to the credentialsPlugin used, and would be assigned by the authentication utility. This is a solution because the event fired already includes the info object. Pros: - It enables a more dynamic and much simpler story for determining whether an app can support logging out than the current pertinent zope.app code (as long as you only use pluggable auth). - It's a one-line change to the code itself (not including interface and test changes). No grand architecture changes. - the 'info' object seems to be a reasonable place to add information about the process used to create the principal. - It's ignorable, for those that wish to ignore it. Cons: - This is the only use case I know of for the behavior, so it has a small feel of 'scratch an itch'. Maybe that's not too bad here. Thoughts? Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] logout patterns: a small proposal
On Dec 8, 2005, at 10:58 AM, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 10:11:46AM -0500, Gary Poster wrote: | ... Sounds good to me. Cool. Only one issue that you should have in mind, and that has bitten me several times with the Zope 2 PluggableAuthService is the following: If you use the 'HTTPBasicAuthHelper' for login, that doesn't mean you can use it for logout. That is specially true if you happen to use the 'CookieAuthHelper', which translates cookie-based credentials to http basic. What happens is that it in PAS, if you call logout() it will call all the 'ICredentialsReset', however if the HTTPBasicHelper happens to be one of those, it will raise a 'Unauthorized' exception, because that's how you log someone out using http basic auth, and then two things happen: 1. The cookie credentials don't get erased because of the Unathorized 2. Any plugins that happened to be enabled for ICredentialsReset won't fire. Thanks: that is interesting, and answers some idle questions I had lying around in my head. In the case of the Zope 3 pluggable auth, though, there are a number of reasons why this (currently) doesn't come into play. A particularly pertinent reason is that the default basic auth plug-in doesn't do the 'raise Unauthorized' trick--it just rolls over and plays dead (i.e., 'pass'). Logging out is effectively not available if you are logged in via the standard basic auth. This is a case in which you would not want to offer 'log out' in the UI (or you'd want to work out some other compromise). Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Dario Lopez-Kästen wrote: Stephan Richter wrote: On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? Yep. Nobody has complained to us about this yet. I personally do not use ZEO, so I could not fix the issue anyways. I don't expect other people for me to fix this for me, but I suggest that this be noted somewhere where it can be seen, because ZEO is quite important for us running larger sites. Right, as far as I understand from this thread now ZEO and a straight install (not upgrade?) of Zope 3.2 don't work? That's rather a big change. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Twisted Publisher and Zope 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So | if you want to use Twisted-specific packages, like the scheduler, you | have to use twisted, otherwise you are out of luck. I think this is | totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? 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. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmGOO+gerLs4ltQ4RAh5WAKDKV/3O77THXAFJZWK6ePEXxyMo8wCeL9O7 +fK7fCbh6uMXE2NgrRCRAFU= =5WMQ -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: Twisted Publisher and Zope 2
Hi, Am Donnerstag, den 08.12.2005, 11:47 -0500 schrieb Tres Seaver: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So | if you want to use Twisted-specific packages, like the scheduler, you | have to use twisted, otherwise you are out of luck. I think this is | totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? 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. I'm also rather surprise about those MANY incompatibilities that haven't been discussed and shall silently be accepted. Right now I am aware of three problems: - WSGI disallows response streams - Twisted handles chunked requests differently (zsync checkin breaks) - ZEO is broken or at least suboptimal This makes me pretty nervous about our development process / decision making. Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Jim Fulton wrote: Martijn Faassen wrote: Chris Withers wrote: Stephan Richter wrote: I wonder whether a similar approach as the one taken for the Twisted server migration is possible. There, if you have an instance running on ZServer an upgrade will not cause the switch to Twisted, since your startup script still refers to the old server code. You explicitely have to change your startup script to start using Twisted. I think this is the way to go and a zope.conf option would be an ideal way of making the choice... I'm not sure whether we're talking about the server or the publisher, True, I realized after posting this and thinking a bit that things got a bit muddled in this thread. I'm mostly concerned about the publisher. The server part I guess is easier to port, though I also suspect less of a gain on the short term. Hm, maybe you are talking about the publisher. :) Yes, I was. Sorry for the confusion. In which case, I expect this all to be controlled via adapters, so what you suggest should be possible. In any case, existing Zope 2 code should function as it does now without change. That would be good. I wonder how this interacts with things like error handling, though. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
Tres Seaver wrote: 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. Tres. -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com Endorsing this statement. We've got Zope 2 running in a cluster with ZEO (and DirectoryStorage). Besides being the right way to do our application, ZEO was essential in getting past the CIO asking What do you mean you won't be using Sql Server? -- Wade Leftwich Ithaca, NY ___ 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 Thu, Dec 08, 2005 at 07:31:56PM +0100, Christian Theune wrote: - WSGI disallows response streams It what??? Seriously? That's a showstopper for a lot of projects. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Twisted Publisher and Zope 2
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So | if you want to use Twisted-specific packages, like the scheduler, you | have to use twisted, otherwise you are out of luck. I think this is | totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? 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. Don't worry, we'll (I'll :) work this out. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
Christian Theune wrote: Hi, Am Donnerstag, den 08.12.2005, 11:47 -0500 schrieb Tres Seaver: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So | if you want to use Twisted-specific packages, like the scheduler, you | have to use twisted, otherwise you are out of luck. I think this is | totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? 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. I'm also rather surprise about those MANY incompatibilities that haven't been discussed and shall silently be accepted. Oh come on. Nobody is silently accepting anything. Right now I am aware of three problems: - WSGI disallows response streams - Twisted handles chunked requests differently (zsync checkin breaks) Are you refering to the lack of response.write? It wasn't clear to us that anyone was using this. Do you think that there is application code that's using this? We didn't catch zsync because it didn't have adequate tests. - ZEO is broken or at least suboptimal This is news. We are responding. If you think something is a problem then file a collector entry and we'll deal with it. This makes me pretty nervous about our development process / decision making. How would you improve it? What would you di differently? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
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. Twisted integration was important to the people who worked on it. No one asked *you* to work on it. For myself, I think it is pretty important to: - Support WSGI well, as that gives people a lot more flexibility on how to deploy Zope. - Get out of the network server business. In a year or two, I'll be quite happy not to support ZServer anymore. Are these the things *I* would have done first, maybe not, but I didn't do most of the work. It has to be pretty discouraging to Stephan to get these sort of complaints. That's just not fair. Change entails risk. A change to the ZPT machinery is bound to introduce problems that need to be fixed. That's why we need people to contribute by testing things. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Martijn Faassen wrote: Jim Fulton wrote: ... Hm, maybe you are talking about the publisher. :) Yes, I was. Sorry for the confusion. I don't think it was anyone's fault. In which case, I expect this all to be controlled via adapters, so what you suggest should be possible. In any case, existing Zope 2 code should function as it does now without change. That would be good. I wonder how this interacts with things like error handling, though. I dunno. I guess we'll figure it out. I doubt it will be the biggest of our problems. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
Paul Winkler wrote: On Thu, Dec 08, 2005 at 07:31:56PM +0100, Christian Theune wrote: - WSGI disallows response streams It what??? Seriously? That's a showstopper for a lot of projects. Uh, what is the it/that that you are talking about? I have no idea what WSGI disallows response streams above means. WSGI is designed sprecifically to support streaming via Python iteraction. The Zope 3 publisher didn't previously support either streaming or efficient handling of large output. It *now* supports efficient handling of large output. This is a step forward. The major change is that the response 'write' method is no longer supported. If that causes breakage of existing Zope 3 apps, then we can add it back. It was our judgement that it wasn't being used, so we dropped it. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: 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: Twisted Publisher and Zope 2
On Thu, Dec 08, 2005 at 02:05:55PM -0500, Jim Fulton wrote: Paul Winkler wrote: On Thu, Dec 08, 2005 at 07:31:56PM +0100, Christian Theune wrote: - WSGI disallows response streams It what??? Seriously? That's a showstopper for a lot of projects. Uh, what is the it/that that you are talking about? I have no idea what WSGI disallows response streams above means. WSGI is designed sprecifically to support streaming via Python iteraction. Yes, I see that now, and posted as much in parallel to your reply. Sorry for being alarmist. The major change is that the response 'write' method is no longer supported. If that causes breakage of existing Zope 3 apps, then we can add it back. It was our judgement that it wasn't being used, so we dropped it. I think this is only a problem if/when this stuff is used in Zope 2. There's an awful lot of zope 2 code using RESPONSE.write(). But of course you know that, so I'll shut up now. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
On Thursday 08 December 2005 13:57, Jim Fulton wrote: It has to be pretty discouraging to Stephan to get these sort of complaints. That's just not fair. I'll note that it is even more discouraging to Michael Kerrin, who put in a hell of a lot of time to get this working, specifically the FTP code. Overall I agree with Jim on his comments. We have been extremely careful not to step on anyones toes and provide as smooth of a transition as possible. We asked repeatedly for feedback/testing and all the tests are passing (including ZEO). Alone the thought that ZEO depends on the server Zope is using, makes me worried about ZEO; but then Jim just figured out that there is no problem. ;-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
On Thursday 08 December 2005 14:05, Jim Fulton wrote: The major change is that the response 'write' method is no longer supported. If that causes breakage of existing Zope 3 apps, then we can add it back. It was our judgement that it wasn't being used, so we dropped it. And I remember us asking specifically on the mailing list whether someone is using it. In any case I think the IResult API is cleaner, so we should attempt a solution there. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Twisted Publisher and Zope 2
[Stephan Richter] ... Overall I agree with Jim on his comments. We have been extremely careful not to step on anyones toes and provide as smooth of a transition as possible. Impending releases always create panic. Embrace it as an opportunity for spreading joy ;-) We asked repeatedly for feedback/testing and all the tests are passing (including ZEO). The ZEO _tests_ set up their own asyncore mainloop. If you think about it, it has to be that way, else we couldn't run the ZEO tests from a standalone ZODB checkout. Alone the thought that ZEO depends on the server Zope is using, makes me worried about ZEO; but then Jim just figured out that there is no problem. ;-) There is a problem, but it in one sense it's shallow: it only takes a few lines of code to set up an asyncore mainloop ZEO is maximally happy with. The hard part for Jim will be figuring out where to put them ;-) The deeper problem is that ZEO _ever_ relied on someone else to set up a mainloop; Jim sent a note about that to zodb-dev today (ZEO should change to set up its own asyncore cruft). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] xml import / export in z2 z3
There's also Amara, which is designed to be Pythonic: http://uche.ogbuji.net/uche.ogbuji.net/tech/4suite/amara/ On 12/7/05, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: Martijn Faassen wrote: Andreas Jung wrote: I'm about to write an xml importer for importing simple data (properties, dictionaries). Exporting is easy, importing is trickier because a parser is required. Is there any prefered framework for doing such things in zope3 (zope2)? Sax or DOM...it depends on the usecase and the algorithmic approach you take. Sax is fast but you have to build your own datastructures, DOM is slow, takes a lot of memory but it gives you a tree to perform any fancy operation on it.. DOM is also not particularly Pythonic (neither is SAX, but it is relatively simple at least). You could also look into ElementTree (or lxml, which implements that API too). ElementTree (though not yet lxml) also introduces iterparse, which is a kind of streaming version of the ElementTree API. ElementTree's API is a much nicer way to work with XML from Python than DOM. Also it's more lightweight than even MiniDOM. Regards, Martijn thanks for the info Martijn, I'm going to look at it. I've done some work with ElementTree for CPSIO, and I haven't found it very easy to use because of all the extra namespace URI, and xpath stuff used for the tree navigation (xpath_findall, ..) which seem to get in the way. Also it could be that I find the DOM approach easier since I'm used to it in javascript already. the question is also about being able to reuse parts of the export/import code of CMFSetup / GenericSetup and possibly simplify the zope2 - zope3 migration of existing applications. best /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/tristil%40gmail.com -- -J. Method -- -J. Method ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: xml import / export in z2 z3
Jean-Marc Orliaguet a écrit : I've done some work with ElementTree for CPSIO, and I haven't found it very easy to use because of all the extra namespace URI, and xpath stuff used for the tree navigation (xpath_findall, ..) which seem to get in the way. Also it could be that I find the DOM approach easier since I'm used to it in javascript already. The iterparse approach is by far the mots pythonic approach ever (tm): http://effbot.org/zone/element-iterparse.htm Quoting the URL, here is the RSS-reader-in-less-than-eight-lines example which is quite expressive: from urllib import urlopen from cElementTree import iterparse for event, elem in iterparse(urlopen(http://online.effbot.org/rss.xml;)): if elem.tag == item: print elem.findtext(link), -, elem.findtext(title) elem.clear() # won't need the children any more This combines the simplicity of the ElementTree data structure with the possibility to stream-process your input in similar way to SAX, cleaning the memory as you go. -- Olivier ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: How to add objects?
Philipp von Weitershausen wrote:
Florian Lindner wrote:
Of course, I've a already defined a addform, but this is only for the
ZMI:
addform
label=Add CSEvent
name=AddCSEvent.html
schema=..interfaces.IEvent
content_factory=..event.Event
permission=zope.ManageContent
/
In Zope 2, only for the ZMI would be correct. In Zope 3, the line
between the ZMI and a custom user interface has been blurred. Stuff that
you define for the ZMI can largely be reused in a custom user interface.
I other words, the ZMI in Zope 3 is just *one* user interface. Take it,
customize it, and voila, you have your own user interface.
Coming from Zope 2 myself, where you always had to create parallel add/edit
presentation forms if you wanted your objects to be both ZMI and non-ZMI
manipulatable, I see his confusion. I'm wrestling with it now and still see
gaps, perhaps to my newbie understanding of Zope 3.
I'm wondering if, in the Zope 3 world, it's going to become common to expose
the ZMI, in a tightly-controlled, re-skinned way, to the non-technical
end-user. Something we could never do in Zope 2.
My questions are:
a) How to I configure such a add form?
You already did so (the above addform directive). Your assumption that
this only works in the ZMI is incorrect. It works in any user
interface (=skin) that you create and that is based on the 'default' layer.
c) If the form needs a supporting view class, how do the class has to
look like?
Most of the time you don't need a class that supports the view unless
you want to do some very customized stuff.
I was hoping that but I'm not finding this to be true. It seems I need a
view in common cases.
[1] If I want to redirect the user to an operation completed page, I must
define a view with a nextURL() method. However if I want to reuse that same
page for ZMI add operations, I must duplicate it so that it goes to
@@contents.html and leave out my view. It seems I want a default nextURL()
that just uses HTTP_REFERER, so that after an add/edit, you are returned to
where you started, ZMI or not ZMI (although the original HTTP_REFERER would
have to be passed thru a sequence of pages related to the view).
Perhaps I could do this with layers/skins, but it doesn't seem to be the
case that ZMI and non-ZMI seamlessly use different skins in which I could
factor such things.
So my solution is, for each object, to define a newblah.html and an
addblah.html, where the former is used for non-ZMI and the latter is placed
on the ZMI add-menu bar. And the only difference in those .html definitions
is one has a class= view defined and the other doesn't. Seems kludgey.
[2] The other use-case that requires views is any filtering at all. Under
Zope 2 it was common here to off-the-cuff (TTW) drop the following into the
index_html of a folder to display a list of items of specific metatypes:
li tal:repeat=item container/objectValues
span tal:condition=python:item.meta_type == 'Folder'
a tal:attributes=href string:${item/getId}
tal:content=item/title_or_id Item Title or Id /a
/span
/li
I saw the argument posted elsewhere that TAL should not be used for
filtering, and I agree TAL has been abused for complex logic over the years.
But requiring a view class just to perform something like item.meta_type
== 'Folder' (eg. (IFolder.providedBy(item)) seems a bit burdensome.
I've tried doing something like the following but after several hours for
something so simple its not working:
li tal:define=IVentureSet
modules/webaccountant.ventures.interfaces/IVentureSet
tal:repeat=item context/values
tal:condition=python: IVentureSet.providedBy(item)
a tal:attributes=href string:${item/@@absolute_url}
tal:content=python: item.name/a
/li
So a view class it is.
But the main thing for me is object addition, in a flexible manner and
discovering the new philosphy of ZMI versus non-ZMI.
-Jeff
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
