RE: [Zope-dev] ZPatterns: getItem returns None
Seems like the first element of the list of result objects returned by sqlGetAllotmentArea doesn't define anything called 'AllotmentArea_ID'. Could it be a case problem? What datbase/db_adaptor are you using? It is a case problem, which really surprised me because Interbase is not case sensitive. I feel a bit stupid for not having considered this as a possible problem but for anybody using the Gvib Interbase DA, note that column names are capatilized in results. Dammit stupidity can waste a lot of time. Thanks for pointing out the obvious. Roch ___ 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: Status of aq_chain (was: RE: getPhysicalPath?)
Brian Lloyd wrote: snip, regarding aq_chain So nobody (including the various Products I have installed) uses this incredibly useful attribute. I have numerous places in my source where I loop through aq_parent attributes. A good question is whether aq_chain really should be a public interface. Yes. It was added (I think) as a debugging aid rather than necessarily to be used by application code. This is probably one for Jim to answer (I've CC'ed him on this). Done. ;) If Jim thinks it should be part of the public interface, then someone should add a documentation bug report on this so that Amos and Michel can see that it is included in the right places. Well, it is documented, along with other module goodies in the Interfaces Wiki: http://www.zope.org/Members/michel/Projects/Interfaces/AcquisitionModuleInterface It'd be nice to have even a mention in the acquisition documentation. Poking around the Acquisition C source tells me that there's another attribute, aq_inner, that isn't documented either. It's documented in the Wiki too. I think aq_inner is a public interface - this should also be a doc bug report. Before anyone asks, note that 'aq_uncle' is _not_ part of the public interface, and is only an exercise in Jim having fun :^) And Bob's your uncle. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.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 )
[Zope-dev] Comment on CVS change of default textindex search operator
To: [EMAIL PROTECTED] Date: Mon, 19 Mar 2001 19:47:31 -0500 (EST) From: [EMAIL PROTECTED] (Chris McDonough) Subject: [Zope-Checkins] CVS: Zope2 - UnTextIndex.py:1.33.2.9 Update of /cvs-repository/Zope2/lib/python/SearchIndex In directory korak:/home/chrism/sandboxes/2_3Branch/lib/python/SearchIndex Modified Files: Tag: zope-2_3-branch UnTextIndex.py Log Message: Changed default query operator to 'AND' instead of 'OR' (way improved search results). This strikes me as a Very Bad Thing. Not the idea of having AND be the default query operator, but the fact of *changing* the default. If I remember correctly the default is documented (insofar as it is documented) as being AND, but the default has been OR for so long that I'm sure there are many sites that will break if this change is committed to a release. Worse, the behavior of a site as seen by end users will change. Finally, it is my experience that most search engines use OR as the default operator. I prefer AND myself, but OR appears to be something of a defacto standard. I'm willing to be convinced, though grin. A way to set the default would be cool, but might open up a can of worms. --RDM ___ 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] Adding a property to a batch of objects ?
Hi, I wanted to do sonething like this: dtml-in "objectIds(['DTML Document']) dtml-call manage_addProperty('foo','bar','string') /dtml-in But I am missing the part :-( I can happily add the property to myself or the folder above (if a DTML Method is used) but I just cant seem to be able to add the property to an object I want. Any suggestions ? I would be sooo hapyy, since I have to add three props to about 1200 DTML Documents :-( - Holger --- catWorkX GmbH Hamburg Dipl.-Ing. Holger Lehmann Stresemannstr. 364 22761 Hamburg Tel : +49 40 890 646-0 Info: 0700 catWorkX ( 0700 22 89 67 59 ) Fax : +49 40 890 646-66 mailto:[EMAIL PROTECTED] http://www.catworkx.de http://www.catbridge.de ___ 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] FTP interface being worked on?
On Mon, 19 Mar 2001, John D. Heintz wrote: I'm not sure that in the most general case this would solve the problem either. :-( How do we know when the value (or rather the change in value) of a property for some Zope object should trigger some method? This is a definate advantage of having the class of the object implement (have the opportunity to implement) the read/write interface. It can do whatever needs to be done at write time. This applies most clearly if you are talking about an edit cycle using an external editor. When the new version is committed back, whatever triggered actions are necessary can be done. But I think it applies even if you are serializing a collection of objects, editing them, and committing the collection back. The complication there is that the order in which the objects are committed can affect the outcome. However, the outcome is still self consistent. Now, if you are talking about reconstructing a collection back to a previous (CVS) version, things get more complicated. I'm not sure that one is solvable in the general case, other than by the system that Zope itself uses (whole-db transaction based versions). --RDM ___ 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] Adding a property to a batch of objects ?
On Tue, 20 Mar 2001, Holger Lehmann wrote: I wanted to do sonething like this: dtml-in "objectIds(['DTML Document']) dtml-call manage_addProperty('foo','bar','string') /dtml-in But I am missing the part :-( I can happily add the property to myself or the folder above (if a DTML Method is used) but I just cant seem to be able to add the property to an object I want. I would have thought that this would work. dtml-call "_.getitem('sequence-item',0).manage_addProperty('foo','bar','string')" ought to. Or, if they are zclass instances, .propertysheets.yoursheet.manage_addProperty... Of course, I'm saying this without testing anything, so caveat emptor. This would be a good thing to do in a pythonscript rather than a dtml method, by the way. --RDM ___ 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] Adding a property to a batch of objects ?
Hi! I wanted to do sonething like this: dtml-in "objectIds(['DTML Document']) dtml-call manage_addProperty('foo','bar','string') /dtml-in You might want to use dtml-in "objectValues(['DTML Document'])" (or objectItems). then just say dtml-call "manage_addProperty(...)" or you might change the ... to dtml-call "_.getattr(this(),_['sequence-item']).manage_addProperty(...)" (hope this is right, have not tested it.) First form directly builds a list of the objects instead of the Ids, second form first looks up the id with _['sequence-item'] and then looks up the object with that id in the local object (your folder). Hope this helps.. -- mr topf -- COM.lounge http://comlounge.net/ communication design [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 )
[Zope-dev] ZCatalog bug in 2.3.1b2
I posted this before but didn't get a reply. Has any one seen this bug, Or do they know a fix? ATM this is stopping me using 2.3.1b2 which is a bad thing(tm) --- Zope Errorr Zope has encountered an error while publishing this resource. Error Type: TypeError Error Value: len() of unsized object With this traceback: Traceback (innermost last): File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/OFS/DTMLMethod.py, line 189, in __call__ (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_String.py, line 538, in __call__ (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Let.py, line 146, in render (Object: Results="Catalog(REQUEST=REQUEST)") File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Util.py, line 334, in eval (Object: Catalog(REQUEST=REQUEST)) (Info: REQUEST) File string, line 0, in ? File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/ZCatalog.py, line 530, in searchResults (Object: Traversable) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog.py, line 654, in searchResults File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog.py, line 591, in _indexedSearch TypeError: (see above) Here is the line which calls the search: sr = self.searchResults({'Type' : type, 'sort_on':'lowercase_title_'}) fyi. type = 'TypeTest' The indexes are as follows: Status = Text Index Type = Field Index Identifier = Field Index lowercase_title_ = Field Index parent_identifiers_ = Keyword Index The meta types are like this: Title id identifier There are only 13 records in the catalog. And there are some results to be returned. Cheers -Andy ___ 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] Adding a property to a batch of objects ?
Thanks, dtml-call "_.getattr(this(),_['sequence-item']).manage_addProperty(...)" worked just like a beauty. I thought I tried that one, but I must have made a mistake :-) - Holger --- catWorkX GmbH Hamburg Dipl.-Ing. Holger Lehmann Stresemannstr. 364 22761 Hamburg Tel : +49 40 890 646-0 Info: 0700 catWorkX ( 0700 22 89 67 59 ) Fax : +49 40 890 646-66 mailto:[EMAIL PROTECTED] http://www.catworkx.de http://www.catbridge.de On Tue, 20 Mar 2001, Christian Scholz wrote: Hi! I wanted to do sonething like this: dtml-in "objectIds(['DTML Document']) dtml-call manage_addProperty('foo','bar','string') /dtml-in You might want to use dtml-in "objectValues(['DTML Document'])" (or objectItems). then just say dtml-call "manage_addProperty(...)" or you might change the ... to dtml-call "_.getattr(this(),_['sequence-item']).manage_addProperty(...)" (hope this is right, have not tested it.) First form directly builds a list of the objects instead of the Ids, second form first looks up the id with _['sequence-item'] and then looks up the object with that id in the local object (your folder). Hope this helps.. -- mr topf -- COM.lounge http://comlounge.net/ communication design [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] Comment on CVS change of default textindex search operator
"R. David Murray" wrote: To: [EMAIL PROTECTED] Date: Mon, 19 Mar 2001 19:47:31 -0500 (EST) From: [EMAIL PROTECTED] (Chris McDonough) Subject: [Zope-Checkins] CVS: Zope2 - UnTextIndex.py:1.33.2.9 Update of /cvs-repository/Zope2/lib/python/SearchIndex In directory korak:/home/chrism/sandboxes/2_3Branch/lib/python/SearchIndex Modified Files: Tag: zope-2_3-branch UnTextIndex.py Log Message: Changed default query operator to 'AND' instead of 'OR' (way improved search results). This strikes me as a Very Bad Thing. Not the idea of having AND be the default query operator, but the fact of *changing* the default. If I remember correctly the default is documented (insofar as it is documented) as being AND, but the default has been OR for so long that I'm sure there are many sites that will break if this change is committed to a release. Worse, the behavior of a site as seen by end users will change. Finally, it is my experience that most search engines use OR as the default operator. I prefer AND myself, but OR appears to be something of a defacto standard. I'm willing to be convinced, though grin. A way to set the default would be cool, but might open up a can of worms. --RDM I'm a little torn between being alarmed at this and agreeing with it. I think if this is done there should be an TTW interface in ZCatalog to switch between AND and OR as the default. That would be the best solution IMHO. Also a _documented_ way to switch it in Catalog as well. My $0.02 -- | Casey Duncan | Kaivo, Inc. | [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 )
[Zope-dev] NewLoggingAPI
I have written a proposal for the improvement of logging. It builds on ideas proposed by Chris and Andreas at Digital Creations. It is designed to augment Zope's enterprise-level capabilities. Please comment! http://dev.zope.org/Wikis/DevSite/Proposals/NewLoggingAPI 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] Python 2
Is python 2 ready for the upcoming beta? Will the next release of zope win32 come with python 2 or use the installed python if available? Rgs, Kent Sin - kentsin.weblogs.com kentsin.imeme.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] Comment on CVS change of default textindex search operator
R. David Murray writes: To: [EMAIL PROTECTED] Date: Mon, 19 Mar 2001 19:47:31 -0500 (EST) From: [EMAIL PROTECTED] (Chris McDonough) Subject: [Zope-Checkins] CVS: Zope2 - UnTextIndex.py:1.33.2.9 Update of /cvs-repository/Zope2/lib/python/SearchIndex In directory korak:/home/chrism/sandboxes/2_3Branch/lib/python/SearchIndex Modified Files: Tag: zope-2_3-branch UnTextIndex.py Log Message: Changed default query operator to 'AND' instead of 'OR' (way improved search results). This strikes me as a Very Bad Thing. I second that! Changing the default is a drastic interface change. It should not be done light-heartedly. Finally, it is my experience that most search engines use OR as the default operator. Yes, and it is the more natural interpretation when someone enters a set of (unrelated) words... 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 )
[Zope-dev] 2.3.x Catalog Brains
In doing some development using Catalogs in 2.3.x, I have run across some interoperability bugs between the various Catalog classes. 1. Catalog brains are slightly broken when applied agains plain Catalogs. Looking at __getitem__ in Catalog.py (line 225 and 231 in 2.3.1b2 in particular), the result record is made into a brain which is an aquisition wrapper of the parent of the Catalog object. When using a ZCatalog this is fine because the ZCatalog is the parent of the Catalog. However, when a Catalog is used alone the getPath, getURL, getObject, etc. methods of the brain do not work because they expect to find a getpath method which only exists in ZCatalog. Since this is merely a lookup into the Catalog's paths dictionary, I see no reason why this getpath method can't be in Catalog. A patch will be needed for Catalog.py and CatalogBrains.py to accomplish this, and I would be happy to provide one. However, I need to know why exactly the brains are wrappers of the Catalog's parent rather than the Catalog itself. Is this a security issue of some kind? Another fix for this would be to use slightly different brains for Catalogs vs. ZCatalogs. From what I see the mechanism for this is already in place. 2. This one is less of a bug than a feature request. I have created a CatalogPlus class that basically enhances the Catalog so that is plays well with CatalogAware. This entails just adding the catalog_object and uncatalog_object methods from ZCatalog to Catalog. It would seem to me to be quite easy to modify Catalog or CatalogAware to account for this automatically. Also why are subtransactions part of ZCatalog and not Catalog? My guess is that it is a ZODB specific feature so it doesn't belong in Catalog, is that right? -- | Casey Duncan | Kaivo, Inc. | [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] Comment on CVS change of default textindex search operator
It's so broken with OR for large datasets that the search results are virtually meaningless. We see this first-hand on Zope.org (which is now ANDed after an upgrade) and in most of our consulting projects. I strongly agree that there should be an easy way to switch textindex default queries between OR and AND on a per-index basis. I'd be willing to switch it back, but gad... OR is just *so* useless. ;-) - Original Message - From: "Casey Duncan" [EMAIL PROTECTED] To: "R. David Murray" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 11:07 AM Subject: Re: [Zope-dev] Comment on CVS change of default textindex search operator "R. David Murray" wrote: To: [EMAIL PROTECTED] Date: Mon, 19 Mar 2001 19:47:31 -0500 (EST) From: [EMAIL PROTECTED] (Chris McDonough) Subject: [Zope-Checkins] CVS: Zope2 - UnTextIndex.py:1.33.2.9 Update of /cvs-repository/Zope2/lib/python/SearchIndex In directory korak:/home/chrism/sandboxes/2_3Branch/lib/python/SearchIndex Modified Files: Tag: zope-2_3-branch UnTextIndex.py Log Message: Changed default query operator to 'AND' instead of 'OR' (way improved search results). This strikes me as a Very Bad Thing. Not the idea of having AND be the default query operator, but the fact of *changing* the default. If I remember correctly the default is documented (insofar as it is documented) as being AND, but the default has been OR for so long that I'm sure there are many sites that will break if this change is committed to a release. Worse, the behavior of a site as seen by end users will change. Finally, it is my experience that most search engines use OR as the default operator. I prefer AND myself, but OR appears to be something of a defacto standard. I'm willing to be convinced, though grin. A way to set the default would be cool, but might open up a can of worms. --RDM I'm a little torn between being alarmed at this and agreeing with it. I think if this is done there should be an TTW interface in ZCatalog to switch between AND and OR as the default. That would be the best solution IMHO. Also a _documented_ way to switch it in Catalog as well. My $0.02 -- | Casey Duncan | Kaivo, Inc. | [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 ) ___ 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] ZCatalog bug in 2.3.1b2
I cannot reproduce this, Andy, although I'm sure something is up. If it continues to fail under b3, can you possibly send me a Data.fs that exhibits the problem? Sorry, - C - Original Message - From: "Andy Dawkins" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 11:02 AM Subject: [Zope-dev] ZCatalog bug in 2.3.1b2 I posted this before but didn't get a reply. Has any one seen this bug, Or do they know a fix? ATM this is stopping me using 2.3.1b2 which is a bad thing(tm) --- Zope Errorr Zope has encountered an error while publishing this resource. Error Type: TypeError Error Value: len() of unsized object With this traceback: Traceback (innermost last): File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/OFS/DTMLMethod.py, line 189, in __call__ (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_String .py, line 538, in __call__ (Object: executeSearch) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Let.py , line 146, in render (Object: Results="Catalog(REQUEST=REQUEST)") File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/DocumentTemplate/DT_Util.p y, line 334, in eval (Object: Catalog(REQUEST=REQUEST)) (Info: REQUEST) File string, line 0, in ? File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/ZCatalog .py, line 530, in searchResults (Object: Traversable) File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog. py, line 654, in searchResults File /usr/local/src/Zope-2.3.1b2-linux2-x86/lib/python/Products/ZCatalog/Catalog. py, line 591, in _indexedSearch TypeError: (see above) Here is the line which calls the search: sr = self.searchResults({'Type' : type, 'sort_on':'lowercase_title_'}) fyi. type = 'TypeTest' The indexes are as follows: Status = Text Index Type = Field Index Identifier = Field Index lowercase_title_ = Field Index parent_identifiers_ = Keyword Index The meta types are like this: Title id identifier There are only 13 records in the catalog. And there are some results to be returned. Cheers -Andy ___ 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] Overriding traversal
We have a SQL method that works quite nicely by messing around with __bobo_traverse__ meaning we can pass in long URL's as arguments such as /SQLMethod/a/b/c, /a/b/c is an argument into ZSQL. This is extremely useful to use. We do this by overiding __bobo_traverse__. The problem occurs when we mess around with the management interface it seems things such as manage_workspace can't be returned by using the usual suspects and I get permission error since guessBaseRequest cant seem to get the correct roles/guess What would be really nice is if I can call __bobo_traverse__ and do my thing and if it all goes wrong, what the hey I just return with no change. This post could go on for a while, but I dont want to bore you. Any advice? Thanks in advance. -- 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] Overriding traversal
Actually just notice VirtualHostMonster does the same thing our quick hack does: if name in ('manage_main', 'manage_workspace'): return self.manage_main Hmm. I guess using before_ or after_traversve hooks would be better than overriding traverse. - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 6:01 PM Subject: [Zope-dev] Overriding traversal We have a SQL method that works quite nicely by messing around with __bobo_traverse__ meaning we can pass in long URL's as arguments such as /SQLMethod/a/b/c, /a/b/c is an argument into ZSQL. This is extremely useful to use. We do this by overiding __bobo_traverse__. The problem occurs when we mess around with the management interface it seems things such as manage_workspace can't be returned by using the usual suspects and I get permission error since guessBaseRequest cant seem to get the correct roles/guess What would be really nice is if I can call __bobo_traverse__ and do my thing and if it all goes wrong, what the hey I just return with no change. This post could go on for a while, but I dont want to bore you. Any advice? Thanks in advance. -- 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 ) ___ 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] ZPatterns style question
Hello, I dont know if i'm missing something, or if this is just a style question. But where do the implimentation specific get/set methods go (the functions called within a SkinScript for example)? Do i just stick them anywhere in the aquistion path, or is there some logical place I should place them? How can I write my application so that the user can switch data sources with a click of a button (ie, without having to delete one implimentations' methods, and paste the new ones)? I hope my question makes sense. BTW once i figure this out, i'll be able to finish my tutorial on ZPatterns: http://www.zope.org/Members/eukreign/ZPatternsTutorial - lex __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.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 )
Subject: Re: [Zope-dev] Comment on CVS change
Casey Duncan [EMAIL PROTECTED] wrote: "R. David Murray" wrote: To: [EMAIL PROTECTED] Date: Mon, 19 Mar 2001 19:47:31 -0500 (EST) From: [EMAIL PROTECTED] (Chris McDonough) Subject: [Zope-Checkins] CVS: Zope2 - UnTextIndex.py:1.33.2.9 Update of /cvs-repository/Zope2/lib/python/SearchIndex In directory korak:/home/chrism/sandboxes/2_3Branch/lib/python/SearchIndex Modified Files: Tag: zope-2_3-branch UnTextIndex.py Log Message: Changed default query operator to 'AND' instead of 'OR' (way improved search results). This strikes me as a Very Bad Thing. Not the idea of having AND be the default query operator, but the fact of *changing* the default. If I remember correctly the default is documented (insofar as it is documented) as being AND, but the default has been OR for so long that I'm sure there are many sites that will break if this change is committed to a release. Worse, the behavior of a site as seen by end users will change. Finally, it is my experience that most search engines use OR as the default operator. I prefer AND myself, but OR appears to be something of a defacto standard. I'm willing to be convinced, though grin. A way to set the default would be cool, but might open up a can of worms. I'm a little torn between being alarmed at this and agreeing with it. I think if this is done there should be an TTW interface in ZCatalog to switch between AND and OR as the default. That would be the best solution IMHO. Also a _documented_ way to switch it in Catalog as well. I've gotta weigh in here, too; the breakage induced by this change will be large. Give that what *real* users expect is *neither* a Boolean "AND" *nor* a Boolean "OR", but instead a DWIM/Googlesque "affinity" search, I don't think the win is clear enough to warrant the breakage: * "AND" searches return *small* result sets; non-programmers will be surprised by the often-empty lists they get back, and won't have any clue how to broaden their search. False negatives suck. * "OR" searches return *long* results sets; non-programmers will be unhappy that the items they want are buried in the muck. False positives suck. Given that any site manager can override the policy trivially, using only two lines of DTML, should we really be switching the (admittedly arbitrary) existing polciy embedded in the core? Tres. P.S. dtml-let search_terms="_.string.split( search_text )" search_with_and="_.string.join( search_terms, ' and ' )" dtml-var searchCatalog /dtml-let OK, so it is two and a half lines. -- === Tres Seaver[EMAIL PROTECTED] Digital Creations "Zope Dealers" 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: Subject: Re: [Zope-dev] Comment on CVS change
I've gotta weigh in here, too; the breakage induced by this change will be large. Give that what *real* users expect is *neither* a Boolean "AND" *nor* a Boolean "OR", but instead a DWIM/Googlesque "affinity" search, I don't think the win is clear enough to warrant the breakage: * "AND" searches return *small* result sets; non-programmers will be surprised by the often-empty lists they get back, and won't have any clue how to broaden their search. False negatives suck. I think most people are getting used to narrowing their search by adding terms. Google, Yahoo, Lycos and the like have trained them to do this. I think the idea that folks, even nonprogrammers, don't know to do this in the post-1995 world may be a little flawed. Given that any site manager can override the policy trivially, using only two lines of DTML, should we really be switching the (admittedly arbitrary) existing polciy embedded in the core? No, I suppose not. I'll change it back. :-( Not happy about it. ___ 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 )