Re: [Zope-dev] XMLRPC and Basic Auth problems
I have lodged a collector issue on this Rgds Tim On Fri, 2002-08-16 at 04:31, Nils Kassube wrote: > Casey Duncan <[EMAIL PROTECTED]> writes: > > > The server returns a 200 response status. Strangly, the response > > headers do include WWW-Authenticate. So, the xml-rpc code must be > > changing the response status. > > Yes. It's probably this piece in ZPublisher/xmlrpc.py: > > --cut-- > # Do the damage. > self.setBody(f) > self._real.setStatus(200) > --cut-- > > Damage, indeed :-) or better :-( > > ___ 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] WebDAV access for DTML Methods and Documents
Hello, This may be something that cannot easily be fixed, but the permission "FTP Access" is required for a user to have "WebDAV Access" to an object. Since the method is shared by FTP and WebDAV a more general permission name should be used. Thanks, -Brian ___ 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] XMLRPC and Basic Auth problems
Casey Duncan <[EMAIL PROTECTED]> writes: > The server returns a 200 response status. Strangly, the response > headers do include WWW-Authenticate. So, the xml-rpc code must be > changing the response status. Yes. It's probably this piece in ZPublisher/xmlrpc.py: --cut-- # Do the damage. self.setBody(f) self._real.setStatus(200) --cut-- Damage, indeed :-) or better :-( ___ 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: OT: folding editors
I can also define any foldmarks I wish in Jed. What do you suggest ?
I actually didn't care until this mail ;-)
--On Donnerstag, August 15, 2002 16:21:15 +0200 Jean Jordaan
<[EMAIL PROTECTED]> wrote:
> > > # {{{ ... #}}} crutches ;^)
> >
> > I use a folding editor (jed) and these are the folding marks.
>
> Use Vim, it folds based on indentation (or anything else you care to
> teach it)! ;>
>
> --
> Jean Jordaan
> Upfront Systems http://www.upfrontsystems.co.za
>
Mit freundlichen Grüßen Joachim Schmitz
AixtraWare Ingenieurbüro für Internetanwendungen
Hüsgenstr. 33a, D-52457 Aldenhoven
Telefon: +49-2464-8851, FAX: +49-2464-905163
Key fingerprint = DA10 CC82 62F8 1DBB 39A1 1EDC 725B 3317 A8D7 C3A6
Keyserver: http://www.keyserver.net/en/
___
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] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
> I guess the main complaint was that given a set of indexes sharing a > lexicon, deleting the lexicon and replacing it with another one had > no effect on the indexes and in fact removes your ability to manage > their lexicon at all. So you must replace all of the indexes to use > the new lexicon by hand. What ability to "manage" the lexicon are you talking about? The lexicon has nothing manageable once it's created, except its name. :-) IMO we should remove the external Lexicon from ZCTextIndex and let ZCTextIndex create the Lexicon for you. That means that the pipeline options need to be selected when you create a ZCTextIndex -- this is actually simpler because it's now one-stop shopping (except for the need to still create a ZCatalog). --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] OT: folding editors
> > # {{{ ... #}}} crutches ;^)
>
> I use a folding editor (jed) and these are the folding marks.
Use Vim, it folds based on indentation (or anything else you care to
teach it)! ;>
--
Jean Jordaan
Upfront Systems http://www.upfrontsystems.co.za
___
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] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
> I think that there is at least potential value in sharing lexicons. > Of course, a down side is that it complicates set up. This is where I say "YAGNI" and announce that I'll be happy to refactor the code if and when a real need is discovered. > On the subject of referencing lexicons by path rather than using > direct references, I'm inclined to agree that direct references are > better for simplicity and speed. It's easy enough to add a new index > when you want to change a lexicon. (Well, there are some > complications having to do with making sure that you get all the > needed data into the new index...) What was the use case for switching lexicons in the first place? I bet it was just someone idly playing around and noticing that it didn't work right... --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
Casey Duncan wrote: > On Thursday 15 August 2002 09:21 am, Jim Fulton wrote: > ... > I'm not sure what you mean. The pipelining is defined and executed in the > lexicon. My mistake. > >>I think that there is at least potential value in sharing lexicons. >>Of course, a down side is that it complicates set up. >> > > I guess the main complaint was that given a set of indexes sharing a lexicon, > deleting the lexicon and replacing it with another one had no effect on the > indexes and in fact removes your ability to manage their lexicon at all. So > you must replace all of the indexes to use the new lexicon by hand. > > Admittedly this is really more of a user interface and management issue then > anything. Zope is just not very good at managing one to many relationships > unless the one is the container of the many. 8^( Maybe that's not Zope's job. Perhaps the lexicon should keep track of the indexes using it. Then, if you try to delete it, you'd at least get a warning letting you know that you may need to recreate a bunch of indexes, and telling you which ones. > >>On the subject of referencing lexicons by path rather than using direct >>references, I'm inclined to agree that direct references are better for >>simplicity and speed. It's easy enough to add a new index when you >>want to change a lexicon. (Well, there are some complications having to do >>with making sure that you get all the needed data into the new index...) >> > > The current fix is a compromise that does a traversal as seldom as possible. > unfortunately it means it must be even more complex then either a simple > direct ref or path reference would be. Yup, and this brittle. > I'm thinking about adopting an alternative fix, which keeps the direct > reference and the path to the lexicon and gives you a management interface to > select a new lexicon or simply connect to a replacement (which would clear > the index). It could also tell you if the lexicon used by the index is the > actual one referenced from the path. That sounds OK. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (888) 344-4332http://www.python.org Zope Corporation http://www.zope.com 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 Day 8/02 recap
From: "Dieter Maurer" <[EMAIL PROTECTED]> > Matt Behrens writes: > > Zope Bug Day August 2002 was an unqualified success, with our largest > > bug total squashed to date: 45! The number of still-open collector > > issues dropped by almost 25%. Thanks to all those who participated! > > ... > I want to note that I am *very* pleased with recent Collector activities! > > > Dieter Yeah! Of course, I forgot it was a bug day, and I saw the collector mailbombing me - I was about to file a bug report on it, I couldn't believe that much activity was genuine! :) Good work guys! Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk ___ 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] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
On Thursday 15 August 2002 09:21 am, Jim Fulton wrote: > The original reason to share vocabularies was that multiple fields > often came from the same human "vocabulaties". The idea was that vocabularies > would encompass a number of features including: > > - Words (or n-grams) used > > - Synonyms > > - Stemming rules > > - Stop words > > - Splitting rules > > There was, potentially, a lot of information to be shared and it would > often be important, for consistency to share the same rules for different > fields that contained the same sort of content. Sharing had as much > to do with using consistent rules than it did with optimization. > > Unfortunately, the old text index never implemented a lot of these ideas. :( > > The pipe-lining model used by ZCTextIndex moves some of this functionality > out of the lexicon and leaves some of these ideas unimplemented, as did > TextIndex. I'm not sure what you mean. The pipelining is defined and executed in the lexicon. > I think that there is at least potential value in sharing lexicons. > Of course, a down side is that it complicates set up. I guess the main complaint was that given a set of indexes sharing a lexicon, deleting the lexicon and replacing it with another one had no effect on the indexes and in fact removes your ability to manage their lexicon at all. So you must replace all of the indexes to use the new lexicon by hand. Admittedly this is really more of a user interface and management issue then anything. Zope is just not very good at managing one to many relationships unless the one is the container of the many. 8^( > On the subject of referencing lexicons by path rather than using direct > references, I'm inclined to agree that direct references are better for > simplicity and speed. It's easy enough to add a new index when you > want to change a lexicon. (Well, there are some complications having to do > with making sure that you get all the needed data into the new index...) The current fix is a compromise that does a traversal as seldom as possible. unfortunately it means it must be even more complex then either a simple direct ref or path reference would be. I'm thinking about adopting an alternative fix, which keeps the direct reference and the path to the lexicon and gives you a management interface to select a new lexicon or simply connect to a replacement (which would clear the index). It could also tell you if the lexicon used by the index is the actual one referenced from the path. I dunno though, maybe we would be better off as before and just document how you go about the replacement procedure by hand. The management interface could still be improved though, perhaps allowing you to manage the lexicon through the index in the case that the original lexicon reference was removed. Before there was no disclosure and no way to get to the "deleted" lexicon. -Casey ___ 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] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
The original reason to share vocabularies was that multiple fields often came from the same human "vocabulaties". The idea was that vocabularies would encompass a number of features including: - Words (or n-grams) used - Synonyms - Stemming rules - Stop words - Splitting rules There was, potentially, a lot of information to be shared and it would often be important, for consistency to share the same rules for different fields that contained the same sort of content. Sharing had as much to do with using consistent rules than it did with optimization. Unfortunately, the old text index never implemented a lot of these ideas. :( The pipe-lining model used by ZCTextIndex moves some of this functionality out of the lexicon and leaves some of these ideas unimplemented, as did TextIndex. I think that there is at least potential value in sharing lexicons. Of course, a down side is that it complicates set up. On the subject of referencing lexicons by path rather than using direct references, I'm inclined to agree that direct references are better for simplicity and speed. It's easy enough to add a new index when you want to change a lexicon. (Well, there are some complications having to do with making sure that you get all the needed data into the new index...) Jim Casey Duncan wrote: > On Wednesday 14 August 2002 06:03 pm, Guido van Rossum wrote: > >>>Fix for issue #505 >>>ZCTextIndex is now associated by path to its lexicon. After replacing a >>> > lexicon used by an index, clear the index to make it use the new lexicon. > >>So the semantics are that when you replace the lexicon, the index is >>reset to empty, right? Why not create a new index instead? Then the >>lexicon could be internal to the index. Sharing lexicons doesn't >>sound like a probable use case, the more I think about it. >> >>--Guido van Rossum (home page: http://www.python.org/~guido/) >> >> > > I don't disagree. This was a conceptual holdover from the previous generation > TextIndex. I'm switching this over to zope-dev for wider discussion: > > The current implementation of ZCTextIndex is like the old TextIndex in that > you can create one Lexicon (the sucessor to Vocabularies) shared by multiple > ZCTextIndexes. > > I imagine the thought was that there are only a finite number of words and > that sharing the lexicon would save space and possibly index time, since a > given word would only need to be inserted once into the lexicon regardless of > the number of indexes it occurred in. More significant might be the (cache) > memory savings of only having to keep one copy of the words in memory across > several indexes. Plus fewer loads and stores to the database overall by > sharing the word list. > > On the other hand I think query speeds may be compromised since one large > lexicon would take longer to search for a given word (or words) then several > smaller ones. This would be especially true for small indexes sharing a > lexicon with a much larger one. > > The other downside (as illustrated by issue #505) is the complication of > linking index to lexicon and making the link manageable so that you can tweak > the indexing system easily. My fix is not entirely complete because a hard > ref to the lexicon is still stored in the low-level index (to which the > ZCTextIndex class delegates). In order to fix this effectively without > introducing Zope dependancies at the low level (which we have looked to > avoid) I would need to create some sort of Lexicon proxy that can access the > correct lexicon on demand by a path efficiently. This proxy would be > referenced by the low level index in place of the actual lexicon. > > Of course the other solution, which is much simpler is to dispense with this > notion of sharing lexicons entirely and as Guido suggests, just make the > lexicon part of the index. > > Without hard use cases to the contrary, I lean toward that simpler design. > However I would like to perform some additional testing on large corpuses > with many indexes to assess the memory/performance differences between these > two approaches. We have already ascertained that with the new ZODB cache code > in 2.6, the cache setting can have a profound affect on query performance > (like a factor of 10), so I think testing would be helpful. > > Anyone care to weigh in with use cases for shared lexicons? > > -Casey > > ___ > 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 ) > > -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (888) 344-4332http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev
Re: [Zope-dev] PythonWin/Textpad, external import of Zope module and Persistence
At 10:54 2002-08-15 +0100, Chris Withers wrote: >Johan Carlsson [Torped] wrote: >>I'm trying to setup to run with either TextPad, which can run external >>program like python scripts >>and then parse the result and making Traceback lines linked to the >>line/file where the error occurred. > >No sure exactly what you're trying to do here, can you privde more detail? Well, I solved "the problem" another way, when I realized that I could parse the Stupid Log File and make traceback's clickable in that file: I added a small python script that only gives me the latest stuff in the SLF, and it works quite nice. Now when I get an error I just press CTRL-1 inside Textpad and I get the traceback, click on the error rows and it will automatically open the correct file and scroll to the row where the error occured. For anyone using TextPad on Windows this should quite a time saver. (I know that I forgot to implement a check for if the SLF has been reseted, something my Zope start-up script does everytime I restart the server. http://www.zope.org/Members/johanc/Tips_and_HowTos/textpad_tooltips_howto It's almost like having a RAD tool for Zope. Well not really, but it's an improvement. It should also be possible to make a small script that takes a input file with REQUEST information and then make the HTTP request to the development server and return any traceback messages from the reply to TextPad. (SLF only shows error messages when a product is refreshed, this way it should be possible to retrieve traceback from the running code. (Interactive debugging has to wait, but in Windows it would be terrific to use PythonWin for the task. But starting Zope from within PythonWin usually has the effect of PythonWin hangling. I might be because I have a really slow laptop :-) >>Or try using Python which has an build in debugger which I like to be >>able to use. >>The first problem I encounter in both scenarios is that when a file >>"import Globals" >>which in its turn "from Persistence import Persistent", this fails. >>Mostly because Persistence is "hot patched" by ZODB. >>Is there any smart way to setup a "virtual Zope" environment without >>importing Zope >>(which mounts the Data.fs) or by importing Zope by in a light way without >>mounting >>a storage or just mounting a lights storage. > >'import Zope' is the only sane thing I can think you'd want to do. Zope >has lots of magic that happens when you do that, and unless you do that, >things won't behave as you expect. >You will need to mount the ZODB, but if you use ZEO then this isn't a >problem as your webserver can mount the same storage. I think I have a look at how unit test does this, when I have the time. It would probably solve my problems. Running UnitTest from within TextPad or PythonWin would be a nice way to develop thing in. (Unfortunately I'm not up in speed with writing UnitTests) Thanks. Johan >cheers, >Chris -- Torped Strategi och Kommunikation AB Johan Carlsson [EMAIL PROTECTED] Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Visit: Västmannagatan 67, Stockholm, Sweden Phone +46-(0)8-32 31 23 Fax +46-(0)8-32 31 83 Mobil +46-(0)70-558 25 24 http://www.torped.se http://www.easypublisher.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 )
Re: [Zope-dev] PythonWin/Textpad, external import of Zope moduleand Persistence
Johan Carlsson [Torped] wrote: > > I'm trying to setup to run with either TextPad, which can run external > program like python scripts > and then parse the result and making Traceback lines linked to the > line/file where the error occurred. No sure exactly what you're trying to do here, can you privde more detail? > Or try using Python which has an build in debugger which I like to be > able to use. > > The first problem I encounter in both scenarios is that when a file > "import Globals" > which in its turn "from Persistence import Persistent", this fails. > Mostly because Persistence is "hot patched" by ZODB. > Is there any smart way to setup a "virtual Zope" environment without > importing Zope > (which mounts the Data.fs) or by importing Zope by in a light way > without mounting > a storage or just mounting a lights storage. 'import Zope' is the only sane thing I can think you'd want to do. Zope has lots of magic that happens when you do that, and unless you do that, things won't behave as you expect. You will need to mount the ZODB, but if you use ZEO then this isn't a problem as your webserver can mount the same storage. 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 )
Re: [Zope-dev] Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins]CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
Casey Duncan wrote: > Anyone care to weigh in with use cases for shared lexicons? Well, the use case you describe: several indexes with roughly the same lexicon is the one to watch out for. If you're going to do some quantitative tests on this, it'd be interesting. Still, KISS and all that would suggest the simpler design is better. my 2p, 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] Bug Day 8/02 recap
Matt Behrens writes: > Zope Bug Day August 2002 was an unqualified success, with our largest > bug total squashed to date: 45! The number of still-open collector > issues dropped by almost 25%. Thanks to all those who participated! > ... I want to note that I am *very* pleased with recent Collector activities! 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] to __of__ or not to __of__ ?
>At 23:38 2002-08-14 -0400, Casey Duncan said:
>>The Item class mixes in Traversable, which is probably responsible for
>>making
>>this work TTW. It also gives you a bunch of other stuff that many Zope
>>classes need, like DAV support, copy support, ZMI tab support and security.
>>It doen't mix-in acquisition tho.
>>
>>If you need support for acquistion machinery (including __of__ which creates
>>wrappers), then you need to mix-in Acquisition.Implicit. The SimpleItem
>>class
>>mixes this and Persistence in for you (along with Item), so many Zope
>>classes
>>derive form SimpleItem. You need Persistence to store instances of your
>>class
>>in the ZODB, and implicit acquisition is the standard for Zope objects.
>>
>>In short I would recommend mixing in SimpleItem or you may find that your
>>objects are not stored properly in the ZODB.
>>
>>-Casey
You also might want to wrap the object before returning them,
because the are stored in _item and not in the AixtraTableProduct.
def getItem(self,key): #{{{
"returns item"
data = self._items
if data.has_key(key):
item = self._items[key]
if not hasattr(item,'key'):
setattr(item,'key',key)
return item.__of__(self) <--- wrap the item before returned
Regards,
Johan Carlsson
--
Torped Strategi och Kommunikation AB
Johan Carlsson
[EMAIL PROTECTED]
Mail:
Birkagatan 9
SE-113 36 Stockholm
Sweden
Visit:
Västmannagatan 67, Stockholm, Sweden
Phone +46-(0)8-32 31 23
Fax +46-(0)8-32 31 83
Mobil +46-(0)70-558 25 24
http://www.torped.se
http://www.easypublisher.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 )
