[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: 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: Item Title or Id 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: tal:repeat="item context/values" tal:condition="python: IVentureSet.providedBy(item)"> 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
[Zope3-dev] ZEO and Zope 3.2
Jim Fulton wrote: Stephan Richter wrote: > but then Jim just figured out that there is no problem. ;-) Oh, there is a problem. It's not readily apparent though. But, don't worry, I'll figure out why I can't see a problem that I know is there. :) If you use the Rotterdam skin, there will appear to be no problem. This is because of a bug in the skin that causes a database access on every page view. If I fix that bug, then I can see a problem. The problem isn't as pronounced as I'd feared, as ZODB managed to do a good job of staying up to date even without the asyncore main loop. (It aranges to explicitly synchronize at the end of each transaction. In fact, if it did the same at the start of each transaction, we'd probably be golden.) The symptom is that the first web requests that doesn't update any information or make any uncached database calls and that is the first request after another ZEO client updated the database may see out of date information. So, we still do need a fix for the ZEO problem. I'll check in the skin fix. The bug slowed down non-management display of a folder with 9 items by around 20%. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 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
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
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] Re: Twisted Publisher and Zope 2
Stephan Richter wrote: 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; Yup, this needs to change. > but then Jim just figured out that there is no problem. ;-) Oh, there is a problem. It's not readily apparent though. But, don't worry, I'll figure out why I can't see a problem that I know is there. :) 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 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
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 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 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
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] 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
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] 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
[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
On Thu, Dec 08, 2005 at 01:25:21PM -0500, 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. OK, no it doesn't: it's just different. http://www.python.org/peps/pep-0333.html#buffering-and-streaming I don't know how Z3 handles the issues mentioned in the PEP. -- 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 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
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 Design"http://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] 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
--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. -aj pgpHQwQBcMstZ.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
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
[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 Design"http://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] Twisted Publisher and Zope 2
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, I think it's rather too big a shift. I think that 'the old startup script still referring to the old server code' is definitely one that isn't appropriate for Zope 2; either the new server code is backwards compatible and almost everything will run perfectly, or the new code is not very backwards compatible and most Zope apps will break. If you are talking about the server, as opposed to the publisher, I don't see a problem with supporting both the old and new server. Note that the new server is twisted and is largely outside our control. There's no reason to expect twisted to be backward compatible with ZServer. Also, with WSGI, we can use any WSGI server technology, including mod_python. Eventually, we'll phase out ZServer, making it a separate download. OTOH, the publisher itself needs to be backward compatible. In the former case, hard to reach, I think we just want to upgrade everybody. In the latter case, possibly more likely, a zope.conf option is the least we can do. I'd be more in favor of a granular approach, where I can tell the system 'for this piece of content, use the Zope 2 behavior, for that, the Zope 3 behavior'. Hm, maybe you are talking about the publisher. :) 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. But I think we'll have to see which approach is best when there's actual experimental code; I guess only then we'll be able to judge how much of Zope 2 we can safely replace. Yup. 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
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
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
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 think it's rather too big a shift. I think that 'the old startup script still referring to the old server code' is definitely one that isn't appropriate for Zope 2; either the new server code is backwards compatible and almost everything will run perfectly, or the new code is not very backwards compatible and most Zope apps will break. In the former case, hard to reach, I think we just want to upgrade everybody. In the latter case, possibly more likely, a zope.conf option is the least we can do. I'd be more in favor of a granular approach, where I can tell the system 'for this piece of content, use the Zope 2 behavior, for that, the Zope 3 behavior'. But I think we'll have to see which approach is best when there's actual experimental code; I guess only then we'll be able to judge how much of Zope 2 we can safely replace. 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: Ajax in Zope 3
Benji York wrote: Florent Guillaume wrote: Myself I absolutely love the approach taken by CrackAjax (http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework) It's funny you mention that. I was intrigued by that too, but I can only characterize his implementation as a toy. :( I've been working on something similar but have tried to be a bit more "professional" about it (unit tests, trying to be a good designer, etc.). [snip] I consider this a mad scientist experiment, so I don't expect it to be officially included anywhere or even get any work from me once the novelty wears off. You are warned; I don't want angry villagers with pitchforks and torches coming to my castle. :) Another attempt to do something like this is the RPython->Javascript translator part of the PyPy project. RPython is the subset of Python that PyPy is developed in, and there's work on a translator being done by Eric van Riet Paap. The strength of the PyPy approach would be the strong foundation PyPy brings concerning language implementation and testing of such. The weakness, at least currently, I believe, is that it doesn't have a story yet for how to interface with the client-side APIs such as DOM. Definitely one to watch too. 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] Ajax in Zope 3
Benji York wrote: Tarek Ziadé wrote: I was talking about a toolkit because it seems that most of the time there's a cohesion between a web framework, its community, and a js toolkit I would hate to see Z3 create its own JS toolkit. +1 While it may be useful to have some glue in JS that extends an existing JS toolkit to work better with Zope, and there are of course experiments possible, the basic idea would be to stick with toolkits that are already there, not for Zope 3 to invent a new one. It's one wheel that Zope 3 shouldn't be in the business of reinventing. 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] logout patterns: a small proposal
On Thu, Dec 08, 2005 at 10:11:46AM -0500, Gary Poster wrote: | 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. Sounds good to me. 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. Hope that helps, -- 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
[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] Twisted Publisher and Zope 2
Has anyone verified that ZEO doesn't work when using the twisted server? Has anyone noted any negative symptoms? I expect that ZEO does still work, although in a less than optimal way. Jim Dario Lopez-Kästen wrote: 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 -- 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
Dario Lopez-Kästen wrote: 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. I'll respond to this thread on the zodb-dev list. 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
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... We will need to evaluate the difficulty of maintaining two publishers. It is easier to support two servers because WSGI provides a nice interface for abstracting server differences. The pubisher is far more tightly integrated. The first effort should be to use a single publisher for Zope 2 and Zope 3. 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
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
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
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 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] 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 Thu, Dec 08, 2005 at 09:38:32AM +, 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... 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? -- 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] RFC: Simplify Skinning
Philipp von Weitershausen wrote: Thanks for the input so far, please revise it and let me know if you see any other issues. +1 I like it. Thank you! Your connotation assertion here is incorrect. The default layer stands for: "If the browser directive did not specify a layer, use the default layer." By default, the Basic and thus Rotterdam skin incorporate that layer, but others like Dominik and Garrett do not want to include that layer. Right. I wonder if we should make the 'layer' argument mandatory then. Right now we have the connotation "You can leave the layer argument out in which case Zope will use some arbitrary layer that might or might not be in your skins and is boldly called 'default'." I find the current optional layer argument ok. In our current pratice we allways use the default for the basic or general views of a package. This offers a simple way to configure a out-of-the-box-general-purpose-administration-skin like the Rotterdam whitout the drawback that such a general skin should have to know a dedicated layer itself. If we provide other dedicated layers we always do additional registrations to those layers. A fairly usefull pattern that becomes manifest in our pratice: 1. Layers for one or more features belonging together. For such a unit we define three different layers that covers the following aspects of an application: -> minimal_feature layer: Invisible functionality like traverser that should be there even if there is no ui -> user_feature layer: All views for general end-user usage -> admin_featur layer: Views for administration purposes. (One example for a minimal layer tiks svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/skins/minimal) 2. Those feature layers are used to compose the a custom skin afterwards. -> pretty modular and clearly arranged whitout beeing to granular. 3. Because we still register to the default layer a general zmi like the rotterdam skin can be used too. ->this is cool, because everybody can use its favority general-purpose skin and it doesn't hurts his brain to guess where he should configure something (compared to plone in hybrid zope2/plone applications) Maybe we should introduce a minimal_zope_core and other important layers which might simplify such application for all parties. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ 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
[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] 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: 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: 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
