Re: [Zope-dev] un-own an object
"R. David Murray" wrote: Like I said (and the docs say), it is the interesection of the two sets of privileges, so it is effectively just the permissions of user nobody. This isn't very useful though ;-) I ended up re-creating a whole folder tree just because I wanted to delete the user who created them, and Zope 2.2.4 doesn't appear to have a 'Take Ownership' button :-( *grumbling* Chris :-) ___ 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] getattr'ing proxy object's methods
Kent Polk writes: I do not understand your goal precisely... However, the surrogate technique used in "CMFCore.DirectoryView.DirectoryView" may come near to your proxie objects. 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] un-own an object
I meant create an instance of a ZClass owned by a user who no longer exists (if my 'construct' word made no sense - haven't had coffee yet ;-) ). -Original Message- From: Tim McLaughlin Sent: Friday, April 13, 2001 7:31 AM To: 'Chris Withers'; R. David Murray Cc: Tim McLaughlin; '[EMAIL PROTECTED]' Subject: RE: [Zope-dev] un-own an object you can always do a copy and delete to take ownership... (albeit that may cause other probs...) my problem is that I need to be able to construct a zclass built by a user who no longer exists. My suspicion is that "nobody" does not have those privileges, and so it seems that I may be SOL :-( -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED]] Sent: Friday, April 13, 2001 5:50 AM To: R. David Murray Cc: Tim McLaughlin; '[EMAIL PROTECTED]' Subject: Re: [Zope-dev] un-own an object "R. David Murray" wrote: Like I said (and the docs say), it is the interesection of the two sets of privileges, so it is effectively just the permissions of user nobody. This isn't very useful though ;-) I ended up re-creating a whole folder tree just because I wanted to delete the user who created them, and Zope 2.2.4 doesn't appear to have a 'Take Ownership' button :-( *grumbling* Chris :-) ___ 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] Re: zope nautilus cabal
this is true. i tried to acces zope on my local machine at the address http://localhost:9673/ (note: *without* the manage!) and nautilus showed me everything. both mozilla and netscape show the welcome page. if i add manage nautilus simply refuse to authenticate. my impression is that even if http: is specified, nautilus uses some other kind of protocol (webdav?) to read the contents of the url. the bad thing is that you can read (not modify) every single document in the zope db. ciao, federico Scavenging the mail folder uncovered [EMAIL PROTECTED]'s letter: Hi, here in mixad have found a "mysterious" bug with zope and nautilus. We are investigating if is a bug or a feature. The problem is that nautilus can browse the internals of zope directory without authentication. The method is pointing nautilus to http://www.foo.bar:9673 simply. Please can someone try to reproduce the bug ? The version of the sw is: ii libnautilus0 1.0-3 Shared libraries that part of Nautilus ii libncurses55.2.20010318-1 Shared libraries for terminal handling ii nautilus 1.0-3 file manager and graphical shell rc nautilus-trilo 1.0-2 Nautilus component framework for services ii zope 2.3.1-1The Z Object Publishing Environment Regards Andrea Fanfani -- Andrea Fanfani Era talmente intelligente che, datogli in mano un cubo di Rubik, riusciva a mangiarlo in 15 secondi netti. (Anonimo) -- Federico Di Gregorio MIXAD LIVE Chief of Research Technology [EMAIL PROTECTED] Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] Abandon the search for Truth; settle for a good fantasy. -- Anonymous ___ 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] RE: [Zope] REQUIRING Python 2.1??
Second, I am MYSTIFIED (there's no better word) that DC is in such a rush to REQUIRE the use of Python 2.1 for Zope 2.4, when we're still waiting for Py 2.1 final to even come out. Why put all your eggs in that basket, and why force the community to choose between changing to a bleeding-edge Python or retiring to a frozen Zope rev? Does DC not realize that Python has OTHER applications besides Zope? and that for a given community site, changing Pythons might have unexpected side effects in systems whose developers are less gung-ho about rushing to 2.1 than DC is? You may have more than one Python installation on a machine. This in no way forces you to move "all of your applications" to 2.1. The binary releases in particular make this drop-dead easy; they come with a bundled Python, and do not affect any other Python you may have in any way. I thought I'd set my mind at ease by reading the wiki Brian referred to -- which is called "SupportPython21" although it should apparently have been named "RequirePython21" -- but all I could glean from their justifications was [1] it'll make i18n easier (wow, that's huge), [2] there's some other things with strings and such that "may" be useful, and [3] of course there's a raft of other potentially disruptive differences, but hey, at least we found a way to make i18n easier! You've correctly pointed out that I have not captured all of the reasoning. I'll try to correct that in the project docs. And note that Zope is a pretty diverse community - just because i18n is not very important to _you_ does not mean it is not important. There are plenty who consider it hugely significant, and who are at least as perturbed that we _haven't_ done this yet. Instead, for the sake of being able to let the Python developers stick a Zope logo on the 2.1 release, we are risking a boatload of trouble. I'm curious where you came up with that assertion - the PythonLabs guys have had absolutely nothing to do with this. On the basis of prior performance I do not expect this objection to make any difference in what DC does, but I needed to express it anyway. You may find that making your objections in a less inflammatory way will give them more impact. We are all for public debate - that is why we are doing this in the open, in a public project area on dev.zope.org. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ 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] RE: [Zope] REQUIRING Python 2.1??
You may have more than one Python installation on a machine. This in no way forces you to move "all of your applications" to 2.1. The binary releases in particular make this drop-dead easy; they come with a bundled Python, and do not affect any other Python you may have in any way. right, but by the same token the binary releases won't require special warnings to people about upgrading to 2.1. And note that Zope is a pretty diverse community - just because i18n is not very important to _you_ does not mean it is not important. There are plenty who consider it hugely significant, and who are at least as perturbed that we _haven't_ done this yet. The question is not whether i18n ought to be done, but whether you ought to require upgrading to Py 2.1 to achieve it. On the basis of prior performance I do not expect this objection to make any difference in what DC does, but I needed to express it anyway. You may find that making your objections in a less inflammatory way will give them more impact. I do not know how one would measure "impact" in order to test this proposition. If "impact" means changing DC policy or software in any way, then I suspect as previously stated that hearts+flowers wouldn't get it done either. If "impact" means that the question would get a response, well, this thread's existence may be a counterexample. What I do know is that requiring an upgrade to a not-yet-gold Py release as a prerequisite to the next Zope release is unwise software policy. ___ 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] RE: [Zope] REQUIRING Python 2.1??
On Fri, Apr 13, 2001 at 12:10:52PM -0400, anser wrote: You may have more than one Python installation on a machine. This in no way forces you to move "all of your applications" to 2.1. The binary releases in particular make this drop-dead easy; they come with a bundled Python, and do not affect any other Python you may have in any way. right, but by the same token the binary releases won't require special warnings to people about upgrading to 2.1. We made no such warnings. We warn people that follow the bleeding-edge head of the trunk taht we will be switching soon. And note that Zope is a pretty diverse community - just because i18n is not very important to _you_ does not mean it is not important. There are plenty who consider it hugely significant, and who are at least as perturbed that we _haven't_ done this yet. The question is not whether i18n ought to be done, but whether you ought to require upgrading to Py 2.1 to achieve it. Yes, we will require 2.1 to do that, because Unicode support in 1.5.2 is not by far adequate for our needs. The pain of trying to support our own Unicode libraries is too great to justify keeping to support 1.5.2. THis is apart from the other advantages that Python 2.1 offers. On the basis of prior performance I do not expect this objection to make any difference in what DC does, but I needed to express it anyway. You may find that making your objections in a less inflammatory way will give them more impact. I do not know how one would measure "impact" in order to test this proposition. If "impact" means changing DC policy or software in any way, then I suspect as previously stated that hearts+flowers wouldn't get it done either. If "impact" means that the question would get a response, well, this thread's existence may be a counterexample. What I do know is that requiring an upgrade to a not-yet-gold Py release as a prerequisite to the next Zope release is unwise software policy. That is not the policy. The Zope 2.4 release will require 2.1, and development of that release will start *after* Python 2.1 goes gold. This is clearly stated in the linked documents in the warning email. The next stable release may very well (very probably) be a 2.3.3 release. Which will still be a Python 1.5.2 release. I have the idea that you think that either the 2.3.x line will switch to Python 2.1 now (and 2.3.3 is to be released soon) or that no more development on the 2.3.x line will occur. -- 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 )
[Zope-dev] Re: zope nautilus cabal
On Fri, Apr 13, 2001 at 05:01:13PM +0200, Federico Di Gregorio wrote: http://localhost:9673/ \ There is another method From the zope-it ml andrea@mowgli:~$ cadaver http://foo.bar:9673 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/ ls Listing collection `/': (reconnecting...done) succeeded. [Put here the list of directory and files] Regards a.f. -- Andrea Fanfani Era talmente intelligente che, datogli in mano un cubo di Rubik, riusciva a mangiarlo in 15 secondi netti. (Anonimo) ___ 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] RE: [Zope] REQUIRING Python 2.1??
[anser] I can't quite help wondering whether someone at DC has maybe gotten so "into" the development of Py 2.1 that they just can't wait to use its new stuff, whether it's objectively what's best for Zope or not. The prudent thing to do would have been to add features as needed using 1.5.2-compatible code, or at best to offer a "new18n" branch that requires 2.1, which people who are THAT desperate for i18n could choose to follow if they wanted. Then, say 6-12 months after 2.1 is gold, you could unify and require it for 3.0. Instead, for the sake of being able to let the Python developers stick a Zope logo on the 2.1 release, we are risking a boatload of trouble. [albert] As far as I can make out the strategy you advocate is more or less exactly what they *did* do - so smoothly you didn't even notice. The *big* leap is from 1.5.2 to 2.0 which has been out for quite a while. I18N is *desperately* needed but had to be delayed because of the compatability problems you are rightly concerned about. So even after I18N became feasible with 2.0 the main branch was made compatible with using 2.0 but binaries released with 1.5.2 to avoid risking a boatload of trouble while enabling people desperate for I18N to start using 2.0 and at the same time discover as much as possible of the hiccups before general switchover. Waiting for the "odd numbered release" is also a generally sound policy. Essentially you are confusing that prudent delay in completing the smoothly planned (and very clearly announced long ago) switch from 1.5.2 to 2.x with a sudden rush to 2.1. Whatever problems do occur will be overwhelmingly from the 2.x, not from it being 2.1 in particular. ___ 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] RE: [Zope] REQUIRING Python 2.1??
If what Albert says is true, then Zope 2.4 should REQUIRE Py 2.0 and SUPPORT Py 2.1, not REQUIRE Py 2.1. --On Saturday, April 14, 2001 1:14 AM +1000 Albert Langer [EMAIL PROTECTED] wrote: The *big* leap is from 1.5.2 to 2.0 which has been out for quite a while. I18N is *desperately* needed but had to be delayed because of the compatability problems you are rightly concerned about. So even after I18N became feasible with 2.0 the main branch was made compatible with using 2.0 but binaries released with 1.5.2 to avoid risking a boatload of trouble while enabling people desperate for I18N to start using 2.0 and at the same time discover as much as possible of the hiccups before general switchover. Waiting for the "odd numbered release" is also a generally sound policy. Essentially you are confusing that prudent delay in completing the smoothly planned (and very clearly announced long ago) switch from 1.5.2 to 2.x with a sudden rush to 2.1. Whatever problems do occur will be overwhelmingly from the 2.x, not from it being 2.1 in particular. ___ 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] REQUIRING Python 2.1??
On the basis of prior performance I do not expect this objection to make any difference in what DC does, but I needed to express it anyway. Hey give DC a break! I think people keep forgetting this is a free open source product and they have strived to do everything they can to improve Zope, make a good businness out of it and listen to us whine at the same time. I find DC receptive to things I ask about and they just dont have the time and money to do everything we want. The fishbowl process is a great example of how DC clearly involves the community in upcoming changes. I do not know what "prior performance" you were talking about, but if its with emails like this, Im not surprised. Anyway I full agree 1.5.2 - 2.0 will be 99% of the pain for Brian. -- Andy McKay ___ 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] Re: [Zope] **Important Notice** for Zope public CVS users
On Friday 13 April 2001 02:22, Oleg Broytmann wrote: Hi! On Thu, 12 Apr 2001, Brian Lloyd wrote: We are soon going to begin checking in changes to the head of the Zope CVS that will require the use of Python 2.1. Once we start on the 2.4 tasks, you will not be able to use a public CVS checkout of Zope with older Pythons. Why not make a branch, and port some important things from one branch to the other? This allows people to checkout from the branch, not from the head. i asked brian much the same thing on zope-dev (i was trying to avoid cross posting). his is response follows. -kapil There is (and will continue to be) a "current release branch", which is the branch that stable (bug-fix) releases are made from. Currently the release branch name is 'zope-2_3-branch'. This is probably the branch that most CVS users actually want to be using anyway. Running from the trunk you get all of the latest bugfixes, but you also get all of the latest half-baked work for the next feature release - which might be worse than the bugs you were trying to avoid in the first place :) So if you are running from CVS (but are not running from the current release branch) you can go into your local copy and do: 'cvs up -d -P -r zope-2_3-branch' to update to the release branch checkout. The warning is mostly aimed at the bleeding-edge people who use the CVS trunk. If you are running the release branch you will continue to get bug fixes and will not need to upgrade to Python 2.1, as the changes in preparation for 2.1 will only go into the trunk. ___ 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] getattr'ing proxy object's methods
On 13 Apr 2001 05:50:01 -0500, Dieter Maurer wrote: Kent Polk writes: I do not understand your goal precisely... However, the surrogate technique used in "CMFCore.DirectoryView.DirectoryView" may come near to your proxie objects. I played around with that and can't quite see how to map the proxy namespace onto the current one. I basically want to do a dtml-with in Python for the proxy clients. so that: dtml-in "getTable(...)" automatically adds the proxy's namespace, instead of having to do: dtml-with Proxy dtml-in "getTable(...)" where: def Proxy(self): """Return the proxy associated with this object""" return getattr(self, self.proxy_id) __call__ is never called in this context as it's trying to locate a method (that doesn't exist for the proxy client), so that's out. __of__, of course probably is the key, but I can't determine how to push the proxy's namespace onto the current call, much less be able to do anything with it since hasattr(self, self.proxy_id) returns 0 in the context of the __of__ call for the proxy client. I don't understand that one since self appears to be the correct object. I presume it has something to do with preventing recursion... I also tried adding the proxy's namespace to the client when created, which was quite interesting, but not quite what I had in mind. :^) That appears to leave me with just __bobo_traverse__, which can correctly locate the proxy object but I can't determine how I could use it to either directly call the proxy method (can't identify the method from inside __bobo_traverse__) or add the proxy's namespace in the context of __bobo_traverse__. Thanks! ___ 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] Re: RackImage
Itai Tavor wrote: Thanks, Michael! Turns out I just had to make a few small changes in my product to get it to work, which I discovered looking at yours. Don't know if anything in my product that it would be interesting to add to yours... it's aimed at storing photos for a product catalog, most of what it adds to Image is methods for creating a photo based on another photo, used for creating a thumbnail. Sure, I'll take a look at it. The approach I'm taking (ZPatterns all the way!) is to generalize the creation and association of the RackImages with an ArchiveImage ZClass (that holds meta data). I've got things set up to the point that the ArchiveImages are traversable into their Rackimages, and the ids are rewritten appropriately. So the ArchiveImage ZClass intsances are stored and accessed like this: ArchiveImages/001 And the RackImages are stored like this: ArchiveImages/Renderings/001_original -notice the id! But I can access the image data from the apropriate RackImage like this: ArchiveImages/001/original Next up is RackImage instantiation based on scaled image data. I think examining your code may be helpful, but I probably only need your main .py file. The number and sizes of Renderings that Images have will be configurable at the application level. Cheers, Michael Bernstein. ___ 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] Re: zope nautilus cabal
How is this any different than visiting the site in a web browser? - Original Message - From: "Andrea Fanfani" [EMAIL PROTECTED] To: "Federico Di Gregorio" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, April 13, 2001 12:21 PM Subject: [Zope-dev] Re: zope nautilus cabal On Fri, Apr 13, 2001 at 05:01:13PM +0200, Federico Di Gregorio wrote: http://localhost:9673/ \ There is another method From the zope-it ml andrea@mowgli:~$ cadaver http://foo.bar:9673 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/ ls Listing collection `/': (reconnecting...done) succeeded. [Put here the list of directory and files] Regards a.f. -- Andrea Fanfani Era talmente intelligente che, datogli in mano un cubo di Rubik, riusciva a mangiarlo in 15 secondi netti. (Anonimo) ___ 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] Re: zope nautilus cabal
On Fri, Apr 13, 2001 at 01:49:24PM -0400, Chris McDonough wrote: How is this any different than visiting the site in a web browser? [...] The difference is that in this way you can see the internal structure of the data.fs and not only the http output from zope. You can access to the /manage part without user and pass and see but not modify the internal structure, bypassing the authentication part. In this way a evil-user can discover not-public informations Regards a.f. ___ 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] RE: [Zope] REQUIRING Python 2.1??
On Fri, 13 Apr 2001, Tom Neff wrote: If what Albert says is true, then Zope 2.4 should REQUIRE Py 2.0 and SUPPORT Py 2.1, not REQUIRE Py 2.1. But note what he said about "odd numbered releases". True to form, 2.0 adds a whole load of features, and 2.1 cleans up after 2.0. ;-) True, there is a 2.0.1 bugfix-only release of 2.0 due out, which puts some of the 2.1 fixes back into 2.0, but it's probably going to be a lot simpler just to (at least officialy) support 2.1 . I think this probably has a lot more to do with Python's more rapid release schedule since moving to SourceForge, than it does to someone at DC being unable to wait. At the older, more leisurely release non-schedule, 2.1 would probably have been the 2.0.1 release: at the current pace, Python is lapping itself! -- Steve Majewski ___ 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] Re: zope nautilus cabal
This isn't a bug, it's a feature. A bad one, likely, as there's no easy way to turn it off. ;-) I believe that if you turn off "Access Contents Information" permission for anonymous on the root folder, a WebDAV directory listing can't be retrieved. This, however, likely breaks lots of things that have nothing to do with WebDAV. The WebDAV (and XMLRPC) stuff either needs to be decomposed to run on its own port (and only that port) or more explicit permissions need to be associated with WebDAV/XMLRPC operations if we take for granted that being able to browse the root folder structure is a bad thing. - C - Original Message - From: "Andrea Fanfani" [EMAIL PROTECTED] To: "Chris McDonough" [EMAIL PROTECTED] Cc: "Federico Di Gregorio" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, April 13, 2001 2:42 PM Subject: Re: [Zope-dev] Re: zope nautilus cabal On Fri, Apr 13, 2001 at 01:49:24PM -0400, Chris McDonough wrote: How is this any different than visiting the site in a web browser? [...] The difference is that in this way you can see the internal structure of the data.fs and not only the http output from zope. You can access to the /manage part without user and pass and see but not modify the internal structure, bypassing the authentication part. In this way a evil-user can discover not-public informations Regards a.f. ___ 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 )
[Zope-dev] Query on ZODB handling of class variables
Hi all: I'm doing some prototyping using the standalone version of ZODB from AMK (March 30, 2001 release, the latest). Things generally work as AMK has documented them but one issue has cropped up on which I could use your feedback. My reading of the ZODB code is that it uses pickling to store objects and the Python documentation on pickles say that classes are not pickled, only their names are. I have a counter class which inherits from Persistent and contains a class attribute which needs to be persistent but seems to be the only thing in my system not restored when I reload my ZODB instance (and this jives with the pickle documentation). (If it matters, this class has an __getinitargs__ method but now __getstate__ or __setstate__ methods.) So how does one get class attributes (one attribute instance per class) stored into and restored from ZODB? If this is not automatic, it would seem that a __getclassargs__ type method might be required. Or am I just doing something wrong? Also, if there is any documentation on how to debug ZODB sessions (I know there are debugging conditionals built in but I haven't found any documentation.), I could use a pointer. Thanks, Bob ___ 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] un-own an object
I meant create an instance of a ZClass owned by a user who no longer exists (if my 'construct' word made no sense - haven't had coffee yet ;-) ). Well, the other option is that you can create a user with the same name and the manager role... cheers, Chris ___ 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] Re:2.3.3?
The next stable release may very well (very probably) be a 2.3.3 release. Which will still be a Python 1.5.2 release. I have the idea that you think that either the 2.3.x line will switch to Python 2.1 now (and 2.3.3 is to be released soon) or that no more development on the 2.3.x line will occur. Erk? What happened to 2.3.2? cheers, Chris (confused... ;-) ___ 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] general ZMySQL question-wierd results
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote: Here is how I created the tables: CREATE TABLE farm ( owner_id int primary key not null auto_increment, farm_name char (40), discipline char (30), owner_fname char(30), owner_lname char(30), farm_address1 char(50), farm_address2 char(50), city char(30), state char(2), zip char(5), country char (20), phone_area_code char(3), phone_no_area char(10), fax char(13), url char(30), email char(15), nearest_city char(15), nearest_city_distance int, add_date date, edit_date date, details char (250)) Here is how I populate the first record: insert into horse101.farm (owner_id,farm_name,discipline,owner_fname,owner_lname,farm_address1,farm_addr ess2,city,state,zip,country,phone_area_code,phone_no_area,fax,url,email,nearest_cit y,nearest_city_distance,add_date,edit_date,details) values(0,'Riverbed Farm','dressage','Vicki','Wall-Kelley','Volkerts Rd.','','Sebastopol','CA','95472','USA','707','829-5824','425-123- 1234','http://www.dressage.to','[EMAIL PROTECTED]','San Francisco',60,2001-04- 10,2001-04-10,'Providing dressage instruction, training, judging as well as offering for sale imported and domestic dressage prospects.') Here is how I attempt to see the records: select * from farm Here are my results: Owner id= P Farm name=r Discipline=o Owner fname=v ,etc. You see, the last field is being inserted into the other fields one char at a time. Any help would be GREATLY appreciated. Owner id (owner_id) can't be 'P' because it is a numeric column. I suspect if you use the mysql client program, you will find that the correct values are in there. -- Andy Dustman PGP: 0xC72F3F1D @ .net http://dustman.net/andy "Normally with carbonara you use eggs, but I used lobster brains instead." -- Masahiko Kobe (Iron Chef Italian): 30-year-old Giant Lobster Battle ___ 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] memory leak
Marco Nova [EMAIL PROTECTED] writes: I've replaced ParsedXML's ExpatBuilder with the pyXML package and I used the sax parser without modifing the code (except for the import), this is the refcounts results. Class April 12, 2001 11:55 am April 12, 2001 12:00 xml.dom.NodeList.NodeList 2103 3678 +1575 xml.dom.Text.Text 1263 2208 +945 xml.dom.NamedNodeMap.NamedNodeMap507 885 +378 xml.dom.Element.Element 499 871 +372 xml.dom.Attr.Attr339 591 +252 xml.dom.DocumentType.DocumentType 710 +3 xml.dom.Document.Document 710 +3 xml.dom.Document.Document increments by 1 each time an xml is procesed (I tried to add a del doc at the end but it's ineffective). So the problem is not ParsedXML but Zope itself or my bad methods. Not necessarily - it's been mentioned that PyXML requires releasing nodes after they're done, so I'd expect this if you replaced ParsedXML's DOM with PyXML's without adding the release. -- Karl Anderson [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 )
