[Zope-dev] [Announce] API Documentation Fishbowl Project
Or how about this person? http://lists.zope.org/pipermail/zope-cmf/2001-June/007435.html oh oh a storm gotta go -jimbo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bulletproof ZCatalog proposal
Please remove the del statement in the ZODB __init__.py file to make this possible. I am simply trying to create my own Transaction objects and can't without patching the StandaloneZODB release to do this. Thanks, John On Friday 08 June 2001 16:21, Phillip J. Eby wrote: > At 04:58 PM 6/8/01 -0400, Shane Hathaway wrote: > >On Thursday 07 June 2001 21:28, Phillip J. Eby wrote: > > > Upon being told to perform a transaction or subtransaction commit, > > > the transaction would notify all the ruleAgents, and then all the > > > indexingAgents. Objects could still subscribe to either queue while > > > this notifying is taking place. (So that triggered actions could > > > cause indexish objects to register as indexingAgents, not to mention > > > causing updated objects to fire additional triggers.) > > > > > > Once all agents in a queue are notified, that queue should be cleared > > > so that notifications are on a per-subtransaction basis. Once both > > > queues are cleared, normal transaction behavior goes forward. > > > >Would you say this would occur before tpc_begin() messages or just > >after? > > Before. I'm saying this would take place immediately at the start of the > existing Transaction.commit() method. > > > > Hm. That's simpler than I thought it was going to be. Shoot, I can > > > even see how to implement it as a runtime patch, that would've been > > > simpler than all the shenanigans ZPatterns goes through to fake out > > > the transaction machinery... and it's a better > > > implementation. Ah well. At the time I wanted to avoid trying to > > > convince Jim to add machinery to transactions "just" for ZPatterns, > > > given that ZPatterns wasn't a particularly established product at the > > > time. > > > > > > Let me know if you guys put something like this in, though, and I'll > > > definitely look at reworking ZPatterns to use the mechanism. It > > > could potentially cut a lot of code out and improve the robustness at > > > the same time. > > > >I don't foresee us adding this capability right away since we need to > >understand it better and it only applies to one working product and a > >hypothetical product. I'd suggest you go ahead with the runtime patch. > > I think I'll wait until ZPatterns works with Zope 2.4, unless it becomes > necessary otherwise. Replacing what I've got now is a pretty significant > undertaking, and risk-prone to boot, so I don't want to delay the finishing > of ZPatterns' support for Zope 2.3.x. > > Basically, the runtime patch would be to replace > ZODB.Transaction.Transaction with a subclass that implemented the > notification queues in the commit() method. There'd be a few other little > extensions needed, like clearing the queues on any abort operation, and > adding registerIndex() and registerRule() or some such methods. > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ] [Announce] API Documentation Fishbowl Project
--On Wednesday, June 06, 2001 11:50:43 AM -0700 jimbo <[EMAIL PROTECTED]> wrote: > I hope this helps. I wanted to add my feelings on the whole documentation > issue. It seems to me that the whole process caters around developers > too much. >>I have to disagree with you **in the context of this thread** for two >>reasons: Why disagree **in the context of this thread** at all? Alot of things change quickly in this field, so flexibility is a must to me. >> 1. DC has done a lot to improve the documentation for non-developers >> in the >> last year. The Zope Book(s) should have a major impact when they >>start to >> appear on shelves in the next month or so. My point >>Developer documentation has lagged behind. There still is alot of progress being made in that direction >> This thread is about a proposal to improve developer documentation. It says nothing at all about the other *existing* efforts by DC and others to improve other types of Zope documentation. I think you have a misunderstanding of freedom and opensource all in one topic. I'm don't follow you here since I know it helps to get feeback from users of a product. I'm talking about improving the API documentation. I seriously wonder how good that API is going to do me if I can't use it in the workplace today or next week. Everyday I see post like this http://lists.zope.org/pipermail/zope-cmf/2001-June/007427.html excerpt "I'm having trouble using the Guard expression in DCWorkflow 0.2. Everything else works fine; it's a great product. I think the call to expr() in the .. I do not really know what I'm doing there... but it works :) " My point is Python is/was suppose to be this language so easy and simple that it should be the first language to teach a person. Where does that simplicity get lost with Zope I wonder? Don't even answer because it does'nt matter to me or the other it departments that are going with other solutions. So go on while the confusion is there. Go ahead and justify it now by saying polishing the API will do it for the masses. When you look at the big picture the developer is the smallest user group of any software product.( you have the end-user, testers, admins,etc) That's why it's even more important to make sure the API docs make it easy to implement something and not "wow this is so cool and has so many features" without the benefits. I also think a pretty good example is what Ty and Phillip did with ZPatterns. They had plenty of how-to implement in the API Documentation. It did take alittle while though, but thanks many times over for the learning experience it was fun. In other words half scientific facts(This is)/ half hocus pocus(Do This). >>2. One of the main points DC made at this years Python conference was >>that >>they have tried to focus the Zope core on too many audiences at >>once. Yes a problem. >>They >>had to have a clearer focus and chose developers as that focus. Of course they did. We're talking about "Core" services here. Like I said before once again I think it's the impletation part I'm stuck on. >>Of course >>I like this choice because I am a developer, but the more important >>point >>is that this tighter focus has the potential to make life easier for >>all of >>us. No just developers. You can call it what you want, but it is a tool that developers can use to get a job done. Content mangers and other network admin types about the API anyway. I imagine most if not all of zope users are progammers in some sense. >>Incremental restructuring of the Zope core and improved Zope >>developer >>documentation makes it much easier and more practical for DC and >>others to >>create layered Zope products that address other communities. Seems to be my point also. Perhaps I stepped in some fishpoo and need to learn how to get involved with the "Fishbowl" process. Thanks, Jimbo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bulletproof ZCatalog proposal
At 04:58 PM 6/8/01 -0400, Shane Hathaway wrote: >On Thursday 07 June 2001 21:28, Phillip J. Eby wrote: > > Upon being told to perform a transaction or subtransaction commit, > > the transaction would notify all the ruleAgents, and then all the > > indexingAgents. Objects could still subscribe to either queue while > > this notifying is taking place. (So that triggered actions could > > cause indexish objects to register as indexingAgents, not to mention > > causing updated objects to fire additional triggers.) > > > > Once all agents in a queue are notified, that queue should be cleared > > so that notifications are on a per-subtransaction basis. Once both > > queues are cleared, normal transaction behavior goes forward. > >Would you say this would occur before tpc_begin() messages or just >after? Before. I'm saying this would take place immediately at the start of the existing Transaction.commit() method. > > Hm. That's simpler than I thought it was going to be. Shoot, I can > > even see how to implement it as a runtime patch, that would've been > > simpler than all the shenanigans ZPatterns goes through to fake out > > the transaction machinery... and it's a better > > implementation. Ah well. At the time I wanted to avoid trying to > > convince Jim to add machinery to transactions "just" for ZPatterns, > > given that ZPatterns wasn't a particularly established product at the > > time. > > > > Let me know if you guys put something like this in, though, and I'll > > definitely look at reworking ZPatterns to use the mechanism. It > > could potentially cut a lot of code out and improve the robustness at > > the same time. > >I don't foresee us adding this capability right away since we need to >understand it better and it only applies to one working product and a >hypothetical product. I'd suggest you go ahead with the runtime patch. I think I'll wait until ZPatterns works with Zope 2.4, unless it becomes necessary otherwise. Replacing what I've got now is a pretty significant undertaking, and risk-prone to boot, so I don't want to delay the finishing of ZPatterns' support for Zope 2.3.x. Basically, the runtime patch would be to replace ZODB.Transaction.Transaction with a subclass that implemented the notification queues in the commit() method. There'd be a few other little extensions needed, like clearing the queues on any abort operation, and adding registerIndex() and registerRule() or some such methods. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bulletproof ZCatalog proposal
On Thursday 07 June 2001 21:28, Phillip J. Eby wrote: > Yep. One of the last two times I spoke with Jim in person (either > the January DC visit or IPC 8, I forget which), he said something > about it maybe being a good idea to have some kind of priority system > like that. I'd love to see something like it exist, if it would make > some of ZPatterns' hackery unnecessary. Yes, I would too. I'm happy to see we're in complete agreement. > The implementation could consist of two subscription queues: > ruleAgents and indexingAgents. ZCatalog would register in > indexingAgents, and ZPatterns objects would register in one or the > other, usually ruleAgents. (I can think of some circumstances where > it would be nice to use the indexingAgents queue, but right now > ZPatterns apps have to work around this by defining their rules in > execution priority order.) Ah-ha, this is sounding familiar. You talked about rule agents and indexing agents in the ZPatterns wiki. > Upon being told to perform a transaction or subtransaction commit, > the transaction would notify all the ruleAgents, and then all the > indexingAgents. Objects could still subscribe to either queue while > this notifying is taking place. (So that triggered actions could > cause indexish objects to register as indexingAgents, not to mention > causing updated objects to fire additional triggers.) > > Once all agents in a queue are notified, that queue should be cleared > so that notifications are on a per-subtransaction basis. Once both > queues are cleared, normal transaction behavior goes forward. Would you say this would occur before tpc_begin() messages or just after? > Hm. That's simpler than I thought it was going to be. Shoot, I can > even see how to implement it as a runtime patch, that would've been > simpler than all the shenanigans ZPatterns goes through to fake out > the transaction machinery... and it's a better > implementation. Ah well. At the time I wanted to avoid trying to > convince Jim to add machinery to transactions "just" for ZPatterns, > given that ZPatterns wasn't a particularly established product at the > time. > > Let me know if you guys put something like this in, though, and I'll > definitely look at reworking ZPatterns to use the mechanism. It > could potentially cut a lot of code out and improve the robustness at > the same time. I don't foresee us adding this capability right away since we need to understand it better and it only applies to one working product and a hypothetical product. I'd suggest you go ahead with the runtime patch. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] explicit/controlled/filtered acquisition for Folders?
After dealing with using Zope for websites for two years, I've come to the point where I think implicit acquisition should be an optional feature when retrieving web content that looks less like objects and more like folders of documents. Implicit acquisition means that when you ask for "/folder1/folder2/folder3/mydoc.html", you might well get /mydoc.html . That might be useful in parts of the object world, but for folders and documents it is almost never right. Yes, if all your links are correct, that won't happen, but users don't always have links correct. Furthermore, the "infinite recursion" problem can easily happen when search engines follow self-referential links. It's possible to work around the problems by using "aq_explicit" and "absolute_url", but those strategies are cumbersome as they represent Zope-specific tailoring. Acquisition isn't limited just to implicit acquisition, though. Has anyone put any thought or work into creating an ObjectManager and Folder that allowed explicit, controlled or filtered acquisition? * ExplicitAcquisitionFolders would act as "limits" or "stops" that isolate different zope application trees from each other. * Controlled or filtered acquisition folders could have a property that declares which methods would be acquired, much like "import" statements in python. Either option would let developers choose, understand, and limit what they were acquiring from outside the local context. I think both document- and object-like Zope sites would benefit. Choice of mechanism is good. I've looked into the required changes some, but the ObjectManager and Folder classes know about each other in a way that doesn't seem completely straightforward to an outsider. I don't think I know enough to write the new classes, especially without a wholesale copy of the existing classes. To those in the know, how hard would it be to do, and what issues would be involved? Thanks. Michael Halle [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
Christian Theune writes: > Internet Explorer and Netscape ignore the path of the cookie > and assume '/'. Who told you that? We use code explicitly setting the cookie path and it appears both IE and Netscape handle this correctly. > Second: > > Opera is conform to the rfc of http 1.1, and this means, that > the cookie is only valid for the version itself, and is not > used in any place out of http://myzope:8080/blaah/myVersion That's the default cookie path. Maybe, setting the cookie path explicitly removes the problem. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] using php on zope
Erik Enge schrieb: > On Fri, 8 Jun 2001, Stian Jenssen wrote: > > > Hi there! > > Hello :) > > > I wan't to use php with zope, does anybody know how the header syntax > > shall look like? Tried diffrent syntaxes but i get wierd outputs, not > > as expected. > > Try this one: http://www.zope.org/Members/Mamey/PHP>. I want to use PHP too, but are there Zope-Objects which serve PHP like Script(PHP), which first are rendered and then send trough php back to the client as > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
On Fri, Jun 08, 2001 at 09:42:00AM -0400, Andreas Jung wrote: > > On Fri, Jun 08, 2001 at 09:36:53AM -0400, Evan Simpson wrote: > > > From: "Martijn Pieters" <[EMAIL PROTECTED]> > > > > REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure > ZServer > > > > environment, this is '/'. In a situation where the Zope server is > running > > > > behind another webserver, and is not at the root of that server, > > > > SCRIPT_NAME represents the path to the Zope server. > > > > > > SCRIPT_NAME is not reliable in the presence of virtual hosting. Use > > > REQUEST['BASEPATH1'] instead. > > > > When we fix this problem, we indeed should use BASEPATH1. BASEPATH1 is > > also empty when in a ZServer-only situation, so we should still use > > path=(REQUEST['BASEPATH1'] or '/') > > The fix is now in the 2.4 trunk. Note that there are 3 bugs open on this, 2291 (which you set to Forgotten'?), 2225 and 2234. Also, you'll have to hunt out all usage of path=REQUEST['SCRIPT_NAME'], not just the one that you fixed. There is at least one other in Version.py, and there may be more. I think you should search for setCookie. And last, this should also go in the 2.3 branch I think. It is a small enough bugfix, and some people will be reluctant to switch to 2.4.x just yet. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
- Original Message - From: "Martijn Pieters" <[EMAIL PROTECTED]> To: "Evan Simpson" <[EMAIL PROTECTED]> Cc: "Christian Theune" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, June 08, 2001 9:31 AM Subject: Re: [Zope-dev] Bug in Zope VersionControl > On Fri, Jun 08, 2001 at 09:36:53AM -0400, Evan Simpson wrote: > > From: "Martijn Pieters" <[EMAIL PROTECTED]> > > > REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer > > > environment, this is '/'. In a situation where the Zope server is running > > > behind another webserver, and is not at the root of that server, > > > SCRIPT_NAME represents the path to the Zope server. > > > > SCRIPT_NAME is not reliable in the presence of virtual hosting. Use > > REQUEST['BASEPATH1'] instead. > > When we fix this problem, we indeed should use BASEPATH1. BASEPATH1 is > also empty when in a ZServer-only situation, so we should still use > path=(REQUEST['BASEPATH1'] or '/') The fix is now in the 2.4 trunk. Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
On Fri, Jun 08, 2001 at 09:36:53AM -0400, Evan Simpson wrote: > From: "Martijn Pieters" <[EMAIL PROTECTED]> > > REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer > > environment, this is '/'. In a situation where the Zope server is running > > behind another webserver, and is not at the root of that server, > > SCRIPT_NAME represents the path to the Zope server. > > SCRIPT_NAME is not reliable in the presence of virtual hosting. Use > REQUEST['BASEPATH1'] instead. When we fix this problem, we indeed should use BASEPATH1. BASEPATH1 is also empty when in a ZServer-only situation, so we should still use path=(REQUEST['BASEPATH1'] or '/'). -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
From: "Martijn Pieters" <[EMAIL PROTECTED]> > REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer > environment, this is '/'. In a situation where the Zope server is running > behind another webserver, and is not at the root of that server, > SCRIPT_NAME represents the path to the Zope server. SCRIPT_NAME is not reliable in the presence of virtual hosting. Use REQUEST['BASEPATH1'] instead. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
On Fri, Jun 08, 2001 at 02:22:54PM +0200, Christian Theune wrote: > > > > I think we want to use: > > > > RESPOSE.setCookie( > > path=(REQUEST['SCRIPT_NAME'] or '/')) > > > > Could you file a bug in the Bug Collector at: > > > > http://classic.zope.org:8080/Collector > > > > Thanks! > > > > Thanks too, will do so. > There are too bugs already, one was mine, the other i don't know. Should > I really post a third? Please do. Refer to the other two bugs (2225 and 2234), but include my explanation (SCRIPT_NAME is '' in ZServer only setups, thus path is '', thus Opera ignores it). You can create a patch where you use the path=(REQUEST['SCRIPT_NAME'] or '/') code I proposed. Please say that I helped diagnose this, the core team'll contact me if they need more info. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
On Fri, Jun 08, 2001 at 02:17:06PM +0200, Christian Theune wrote: > yes. we are right. Opera only sends the cookie in the version, but i couldn't > figure out, what zope is sending (using the tcpwatch proxy). so i don't know > what zope returns ... > the should be a line > > <== Cookie: ... > > or something I think, but there isn't. As soon as you press the 'join' button, Zope will send a 'Set-Cookie' header. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] using php on zope
On Fri, 8 Jun 2001, Stian Jenssen wrote: > Hi there! Hello :) > I wan't to use php with zope, does anybody know how the header syntax > shall look like? Tried diffrent syntaxes but i get wierd outputs, not > as expected. Try this one: http://www.zope.org/Members/Mamey/PHP>. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[mj@digicool.com: Re: [Zope-dev] Bug in Zope VersionControl]
(Could we please keep the list in the loop for both wider discussion and archiving?) On Fri, Jun 08, 2001 at 01:43:29PM +0200, Christian Theune wrote: > > REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer > > environment, this is '/'. In a situation where the Zope server is running > > behind another webserver, and is not at the root of that server, > > SCRIPT_NAME represents the path to the Zope server. > > > > For instance, if your Zope server is presented to the outside world as > > 'http://a.server.com/a/path/to/zope/' then SCRIPT_NAME will be > > '/a/path/to/zope/', whereever you are in the Zope object hierarchy. > > > > Thus, a version cookie is bound to the root of the Zope server. In your > > case, it seems that Opera is ignoring the cookie path altogether, and > > instead falls back on the default, which is the path of the Version object > > itself. > > Okay. I have something for you. > > The REQUEST['SCRIPT_NAME'] is '' on my server. Could it be that - if zope > is on the root - it SHOULD be '/' but is ''? You are correct, SCRIPT_NAME is indeed '' in ZServer situations. However, see below. > Then per RFC it should be the location of the request (in this case > http://localhost:8080/asdf, where asdf is the version). The RFC is silent about this. Note that there are two specifications that may apply. One is the original Netscape specification, the other is RFC 2109: http://www.netscape.com/newsref/std/cookie_spec.html http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html There is also a RFC2965 which defines a new 'Set-Cookie2' header with a new syntax. Neither RFC 2109 nor the Netscape spec specify what happens when a 'path=;' cookie is sent, they only specify what happens if the path attribute is absent. The fact that we set an empty path attribute is thus confusing and we should avoid this. > IE and Netscape poorely ignore the path, but Opera restricts the cookie > to the location of the Version. IE and Netscape have decided that in that case the server must have ment to say 'path=/;', while Opera chooses to interpret it the same way as an omitted path attribute. > Probably you want to check: > > if REQUEST['SCRIPT_NAME']=='': > REQUEST['SCRIPT_NAME']='/' > > wherever this variable is created ... > ??? I think we want to use: RESPOSE.setCookie( path=(REQUEST['SCRIPT_NAME'] or '/')) Could you file a bug in the Bug Collector at: http://classic.zope.org:8080/Collector Thanks! -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: Fwd: [Zope-dev] How to return downloadable content from Python Method
Hi Gregor,
> First off, please don't send HTML mail to the list.
Ouch! Sorry! Easy mistake to make.
>
> You will have to set the Content-Type HTTP header to do that:
> REQUEST.RESPONSE.setHeader('Content-Type', content_type)
> where content_type is the right MIME type of the file you return, e.g.
> something like 'application/msword' in your case.
> Hope that helps.
Yes it works! Thankyou for your help.
Much appreciated,
Simon B.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: Fwd: [Zope-dev] How to return downloadable content from Python Method
> I am compressing files which need to be uncompressed inline
> before download. The DTML calles a python method
> in the product which returns the uncompressed file data. Say
> this file is an MSWord document, how do I return this as a file
> to download? Presently, the browser just tries to display the
> binary file and makes a mess of it.
>
> Regards,
> Simon B.
Hi Simon,
First off, please don't send HTML mail to the list.
You will have to set the Content-Type HTTP header to do that:
REQUEST.RESPONSE.setHeader('Content-Type', content_type)
where content_type is the right MIME type of the file you return, e.g.
something like 'application/msword' in your case.
Hope that helps.
Cheers,
Gregor.
--
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ANN: ReplacingDateTime proposal
On Fri, 8 Jun 2001, Stephan Richter wrote: > See an earlier post on a different thread. Chris wrote that the > license is BSDish and is therefore compatible with ZPL. This means > that mxDateTime could be distributed with Zope. Yes, but in the proposal Andreas mentions the GPL, not the ZPL, and that is what throws me off. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] AW: Zope-Dev digest, Vol 1 #1148 - 12 msgs
unsubscribe!!!
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag
von [EMAIL PROTECTED]
Gesendet: Freitag, 8. Juni 2001 12:08
An: [EMAIL PROTECTED]
Betreff: Zope-Dev digest, Vol 1 #1148 - 12 msgs
Send Zope-Dev mailing list submissions to
[EMAIL PROTECTED]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.zope.org/mailman/listinfo/zope-dev
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Zope-Dev digest..."
Today's Topics:
1. Re: Property Storage (Phillip J. Eby)
2. Re: Bulletproof ZCatalog proposal (Shane Hathaway)
3. Re: [Announce] API Documentation Fishbowl Project (R. David Murray )
4. Re: Bulletproof ZCatalog proposal (Shane Hathaway)
5. Re: Bulletproof ZCatalog proposal (Phillip J. Eby)
6. DCOracle2 Beta 2 (Matt Kromer)
7. RE: A simple dtml-if question... (Jeff Nielsen / UgoFast)
8. using php on zope (Stian Jenssen)
9. Re: ANN: ReplacingDateTime proposal (Erik Enge)
10. Re: ANN: ReplacingDateTime proposal (Stephan Richter)
11. Re: Bug in Zope VersionControl (Martijn Pieters)
12. How to return downloadable content from Python Method (Blandford,
Simon [BSS Audio UK])
--__--__--
Message: 1
Date: Thu, 07 Jun 2001 15:46:42 -0500
To: "Chris Withers" <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
From: "Phillip J. Eby" <[EMAIL PROTECTED]>
Subject: Re: [Zope-dev] Property Storage
At 09:29 PM 6/7/01 +0100, Chris Withers wrote:
>
>If I change one property on, say, a DTML Document, does that store a whole
>new copy of the document in the ZODB?
It updates the object in the ZODB. Whether that causes a copy to be made,
depends on the underlying storage. FileStorage makes copies,
BerkeleyStorage (at least Ty's first implementation thereof) does not.
>Is so, then how about storing properties in their own mini-class that just
>subclassed Persistent, so each property got its own pickle jar?
There are a lot of things you'd have to tinker with to get that behavior.
You would probably be better off just using a storage that doesn't make
copies, or using ZPatterns to store selected attributes in such a storage
(such as a differently-backed ZODB, the filesystem, or an SQL or LDAP
database).
--__--__--
Message: 2
Date: Thu, 7 Jun 2001 17:13:06 -0400 (EDT)
From: Shane Hathaway <[EMAIL PROTECTED]>
To: "Phillip J. Eby" <[EMAIL PROTECTED]>
Cc: Erik Enge <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: Re: [Zope-dev] Bulletproof ZCatalog proposal
On Thu, 7 Jun 2001, Phillip J. Eby wrote:
> >I was thinking that certain types of objects would be committed by the
> >transaction manager before all others. In this case, the catalog (or a
> >special object in the catalog) would be committed first. It would
> >resolve all conflicts in the contained indices before they occur by
> >replaying the changes in the persisted queues from the transaction
> >history, then setting the _p_serial attributes to convince the storage
> >that the conflicts have already been resolved.
>
> Hm. Sounds to me like what you actually want is for the transaction
> manager to do this *after* everything else, rather than before. Thus, you
> would catch any changes which occur *during* transaction commit - such as
> commit-phase cataloging (as some folks do with ZPatterns currently).
Maybe I didn't explain this clearly enough. Let me write some quick
pseudocode:
class Catalog (Persistent):
finished_changes = None # Mapping: {path -> (object, adding)}
unfinished_changes = None # Same as above
tid = None# Transaction ID
def catalogObject(self, ob, path):
unf = self.unfinished_changes
if unf is None: self.unfinished_changes = unf = {}
unf[path] = (ob, 1)
def uncatalogObject(self, path):
unf = self.unfinished_changes
if unf is None: self.unfinished_changes = unf = {}
unf[path] = (ob, 0)
def searchResults(self, ...):
self.finishChanges()
# ... Perform search ...
return results
def finishChanges(self):
unf = self.unfinished_changes
if unf is not None:
fin = self.finished_changes
if fin is None or self._p_serial != self.tid:
# Create finished_changes if not yet created
# and clear it if we're in a different transaction
# from the last time finished_changes was changed.
self.finished_changes = fin = {}
self.tid = self._p_serial
for path, (ob, adding) in unf.items():
if adding: self.addToIndexes(ob, path)
else: self.removeFromIndexes(path)
fin[path] = (ob, adding)
self.unfinished_changes = None
def __getstate__(self):
# Called during transaction commit.
self.finishChanges()
return Persistent.__getstate__(self)
def _p_priority(self):
# Causes this object
[Zope-dev] How to return downloadable content from Python Method
I am compressing files which need to be uncompressed inline before download. The DTML " calles a python method in the product which returns the uncompressed file data. Say this file is an MSWord document, how do I return this as a file to download? Presently, the browser just tries to display the binary file and makes a mess of it. Regards, Simon B.
Re: [Zope-dev] Bug in Zope VersionControl
On Thu, Jun 07, 2001 at 08:30:26PM +0200, Christian Theune wrote: > Okay ... I admit using opera and enjoying it. > > Problem is, that opera is sooo standardsconform. > > See Zope/lib/python/Products/OFSP/Version.py:175 > in function enter() > > Somebody thats the path for the cookie as SCRIPT_NAME. > This seems that the scope of the versions should be > limited to the subtree where the version object was > instanciated. Nice idea. > > But this doesn't work. > > First: > > Internet Explorer and Netscape ignore the path of the cookie > and assume '/'. > > Second: > > Opera is conform to the rfc of http 1.1, and this means, that > the cookie is only valid for the version itself, and is not > used in any place out of http://myzope:8080/blaah/myVersion > > Proposed solution: > > Change the path to '/'. And have the same behaviour on all > browsers. > > Or: > > Change the path to REQUEST["URL1"] (is this the parent folder?) > and have the intended mechanism working at least on opera. > > The last is my personal favorite, because you can have different > versions concurrently open on different projects @ one server. > > Proposed patch for both solutions comes as attachement. REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer environment, this is '/'. In a situation where the Zope server is running behind another webserver, and is not at the root of that server, SCRIPT_NAME represents the path to the Zope server. For instance, if your Zope server is presented to the outside world as 'http://a.server.com/a/path/to/zope/' then SCRIPT_NAME will be '/a/path/to/zope/', whereever you are in the Zope object hierarchy. Thus, a version cookie is bound to the root of the Zope server. In your case, it seems that Opera is ignoring the cookie path altogether, and instead falls back on the default, which is the path of the Version object itself. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ANN: ReplacingDateTime proposal
>Shouldn't it be focused on compatability with the ZPL instead of the >GPL? From what I hear, there still are issues with, for example, >distributing Python Products as GPL with Zope. > >Anyone with better knowledge about this care to enlighten me? See an earlier post on a different thread. Chris wrote that the license is BSDish and is therefore compatible with ZPL. This means that mxDateTime could be distributed with Zope. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ANN: ReplacingDateTime proposal
On Thu, 7 Jun 2001, Andreas Jung wrote: > Feel free to review and comment the propsal to replace > the current DateTime module of Zope by the mxDateTime module: >From the proposal: """ License issues mxDateTime stands under the EGENIX Public License that is considered to be an Open Source license. It should be compatible to GPL except there is discussion about the choice of the law clause between R. Stallmann and M-A. Lemburg """ Shouldn't it be focused on compatability with the ZPL instead of the GPL? From what I hear, there still are issues with, for example, distributing Python Products as GPL with Zope. Anyone with better knowledge about this care to enlighten me? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] using php on zope
> Hi there! > > I wan't to use php with zope, does anybody know how the header syntax > shall look like? > Tried diffrent syntaxes but i get wierd outputs, not as expected. > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
