[Zope-dev] Re: Escaping special characters in ZCTextIndex.QueryParser?
Dieter Maurer wrote:
Robert Casties wrote at 2007-11-25 19:32 +0100:
is it possible to escape parentheses in ZCTextIndex searches?
If not, why not and how can I do a simple search in an index bypassing
the QueryParser?
I fear nobody of us knows this.
Therefore, you must yourself look at the sources.
I had a quick look at the QueryParser source before but it wasn't
obvious to me. I will have a deeper look again.
If you need this feature and ZCTextIndex does not provide
it, then you may use a different text index.
I know that with TextIndexNG3 you can select different
parsers (among others a parser that does not interpret '(' and ')')
or provide your own one.
Is the parser for the search query also pluggable? I will have another
look at TextIndexNG.
I have an index where words can contain parentheses and I am unable to
enter a query for these words because the QueryParser interprets all
parentheses as search expression groupings.
Then, you will need to change the lexicon as well.
Usually, the lexicon breaks words at non alnum characters
(with a few exeptions).
I have my own splitter for the Lexicon so I think the right words are in
the index but I haven't been able to check because I can't search the
index...
Thanks
Robert
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug in AbsoluteURL Adapter
Hi there, while using the AbsoluteURL Adapter in a view, it only returns the path of the object, not the URL. This is because the object does not have a request and therefore the method absolute_url() used by the adapter cannot call the physicalPathToURL() method. Because we always have the request object in this adapter we can call the physicalPathToURL() method directly and convert the physical path of the object and return it. Here is a diff with the fix: Index: browser/absoluteurl.py === --- browser/absoluteurl.py (Revision 81990) +++ browser/absoluteurl.py (Arbeitskopie) @@ -35,8 +35,8 @@ self.context, self.request = context, request def __str__(self): -context = aq_inner(self.context) -return context.absolute_url() +path = self.context.getPhysicalPath() +return self.request.physicalPathToURL(path) __call__ = __str__ Any comments? -- Sebastian Wehrmann gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale · germany www.gocept.com · work. +49 345 122988912 · fax. +49 345 12298891 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Mon Nov 26 13:00:00 2007 UTC to Tue Nov 27 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Nov 26 20:53:25 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008706.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Nov 26 20:54:55 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008707.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 26 20:56:26 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008708.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 26 20:57:56 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008709.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Nov 26 20:59:26 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008710.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Additional locales for zope.i18n.locales.data?
I've run into a problem this morning with i18n in Zope3, and I'm not exactly sure what the appropriate approach is. We have a set of South African translations, paticularly Zulu (zu) and Sotho (st) that are getting picked up correctly. Upon some inspection it appears that the i18n negotiator is skipping over them, with an exception such as: The desired locale is not available. Path: /Users/nathan/p/cc.engine/branches/production/eggs/zope.i18n-3.4.0-py2.4.egg/zope/i18n/locales/data/st.xml Upon inspection I can confirm that the locales which are not working are those without .xml files in the data directory. So a few questions: * Is there an external source for those .xml files, or do we create them ourselves? * Translation seems to work OK (in the case of Zulu, not Sotho) from ZPT, but not from Python; does this sound sane, or perhaps I'm missing something? Thanks, Nathan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Additional locales for zope.i18n.locales.data?
Nathan Yergler wrote: I've run into a problem this morning with i18n in Zope3, and I'm not exactly sure what the appropriate approach is. We have a set of South African translations, paticularly Zulu (zu) and Sotho (st) that are getting picked up correctly. Upon some inspection it appears that the i18n negotiator is skipping over them, with an exception such as: The desired locale is not available. Path: /Users/nathan/p/cc.engine/branches/production/eggs/zope.i18n-3.4.0-py2.4.egg/zope/i18n/locales/data/st.xml Upon inspection I can confirm that the locales which are not working are those without .xml files in the data directory. So a few questions: * Is there an external source for those .xml files, or do we create them ourselves? The XML files are from the ICU repository (http://www.unicode.org/cldr/). AFAIK we're using quite an old version of the files. The problem is we can't simply upgrade to the newest release because the XML DTD changed and the code in zope.i18n.locales isn't very robust regarding DTD changes (which is quite hard anyway). I don't think anybody would object if the files and the code were updated *wink* ;). * Translation seems to work OK (in the case of Zulu, not Sotho) from ZPT, but not from Python; does this sound sane, or perhaps I'm missing something? How are you translating from Python? zope.i18n.translate(msg, context=request) should do it. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: unregistering components?
On 26 Nov 2007, at 19:22 , Chris Withers wrote: (and I'm guessing there is an ISite somewhere, as I could find no definition of setSiteManager, but how does IComponentArchitecture's getSiteManager relate to that of ISite?) zope.component.getSiteManager() will return whichever component registry is active. site.getSiteManager() will return the local component registry that has been associated with site (which provides ISite). Okay, what's the difference between these two registries? Well, site.getSiteManager() will return a very specific component registry, namely the one that's associated with the object named 'site'. zope.component.getSiteManager() will return *whichever* component registry is the active one. Only if 'site' has been remembered as the current site (e.g. during traversal), then both will return the same registry. I think I'm misreading the code in _api then. It looks to me that most things use getSiteManager (even though the comment says it needs to be deprecated) which always appears to return either the global registry or do an IComponentLookup adaptation. If no explicit context is supplied, how does anything other than the global registry end up getting used? getSiteManager is overloaded from zope.app.component. See hooks.py. Yay for indirection :). So zope.app.component replaces the getSiteManager implementation in zope.component? :-( Yes. subscriber is in site.py. The rest of the machinery is in hooks.py. As an aside, I assume zope.thread is needed because Zope doesn't yet run with Python 2.5 as a whole? Not sure I'm following you here. zope.thread.local provides an implementation for the thread-local variable, so that we can remember the 'site' object during traversal in a global place, but still not interfere with other threads. Note that this mechanism was donated to the Python stdlib and is available already in Python 2.4 under 'threading.local'. The latest version of zope.thread.local just refers to 'threading.local'. Also, where's the code which, in the local registry, defers to the global registry to find more adapters/subscribers/whatever? Look for the __bases__ property and its dynamic setter. I guess I'm nitpicking. I would just like to stress the focus of the zope-dev list. Well, I guess with splitting zope into seeprately usable components, this all becomes a much greyer area. I'm exploring the realtionship between components and trying to understand their implementation. That feels like development *of* zope to me, It doesn't to me (which doesn't have to mean anythign ;)) whereas zope3-users has felt like a list for people using the whole of zope 3, whatever that is nowadays... I think zope3-users is also for the users of the separately usable components. Well, as it turns out, they're not so separately usable right now, at least when you're tryinig to easy_install zope.component or so :(. But at least we're working on that. I'd be happy to use either list and even happier to see all 3 lists merge now that they're low volume enough (ie: just have [EMAIL PROTECTED], rather than zope-dev, zope and zope3-users) I think there's value in separating development from the rest of the traffic. As far as [EMAIL PROTECTED] is concerned, I see a lot of old- school (e.g. DTML-related) traffic there, but even though I think it'd make sense to merge it with zope3-users. PS: I am quite excited that it looks like I may actually be able to use bits of zope independently, and this wsgi stuff looks pretty cool too :-) Cool! Be sure to let us know about it afterwards. I think we could use some feedback on projects like this. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [OFF] Does Zope developers have time machine?
Hey, there! Looks like open source developers, especial Zope 3, have enough money to buy Time machine. Check Zope 3 profile on Ohloh.net http://www.ohloh.net/projects/4495?p=Zope+3 Codebase138,855,676 LOC Effort (est.) 49267 Person Years $2,709,689,938 Zope costs more that Vista? -- Mikhail Kashkin, skype:mkashkin, jabber:[EMAIL PROTECTED] Key Solutions (http://keysolutions.ru/) Offshore Zope3 development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Bug in AbsoluteURL Adapter
Sebastian Wehrmann wrote: while using the AbsoluteURL Adapter in a view, By the way, you're using Five's AbsoluteURL adapter. (It's different from the one in Zope 3). Also, the patch below seems to be for Five. Would be good to mention that :). it only returns the path of the object, not the URL. This is because the object does not have a request and therefore the method absolute_url() used by the adapter cannot call the physicalPathToURL() method. Because we always have the request object in this adapter we can call the physicalPathToURL() method directly and convert the physical path of the object and return it. Here is a diff with the fix: Index: browser/absoluteurl.py === --- browser/absoluteurl.py (Revision 81990) +++ browser/absoluteurl.py (Arbeitskopie) @@ -35,8 +35,8 @@ self.context, self.request = context, request def __str__(self): -context = aq_inner(self.context) -return context.absolute_url() +path = self.context.getPhysicalPath() +return self.request.physicalPathToURL(path) __call__ = __str__ Any comments? Can you round up a test that demonstrates how the current implementation fails to cover your case and how your suggestion change fixes that? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Escaping special characters in ZCTextIndex.QueryParser?
Robert Casties wrote: Hi, is it possible to escape parentheses in ZCTextIndex searches? Yes If not, why not and how can I do a simple search in an index bypassing the QueryParser? I said Yes :) I have an index where words can contain parentheses and I am unable to enter a query for these words because the QueryParser interprets all parentheses as search expression groupings. Enclosing the words with double quotes has not helped, neither have backslashes... You have to enclose your string with double quotes and then with single quote. So the parser gets the double quotes with the search string The parser does not interpret the string between double quotes. It works for me :) suppose you are searching for: my text (really good text) to search for txt = 'my text (really good text) to search for' brains = context.portal_catalog(searchableText=text) HTH Is there a way other than having to write a new ZCTextIndex? Thanks for any insight Robert ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Additional locales for zope.i18n.locales.data?
Nathan Yergler wrote: On 11/27/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Nathan Yergler wrote: I've run into a problem this morning with i18n in Zope3, and I'm not exactly sure what the appropriate approach is. We have a set of South African translations, paticularly Zulu (zu) and Sotho (st) that are getting picked up correctly. Upon some inspection it appears that the i18n negotiator is skipping over them, with an exception such as: The desired locale is not available. Path: /Users/nathan/p/cc.engine/branches/production/eggs/zope.i18n-3.4.0-py2.4.egg/zope/i18n/locales/data/st.xml Upon inspection I can confirm that the locales which are not working are those without .xml files in the data directory. So a few questions: * Is there an external source for those .xml files, or do we create them ourselves? The XML files are from the ICU repository (http://www.unicode.org/cldr/). AFAIK we're using quite an old version of the files. The problem is we can't simply upgrade to the newest release because the XML DTD changed and the code in zope.i18n.locales isn't very robust regarding DTD changes (which is quite hard anyway). I don't think anybody would object if the files and the code were updated *wink* ;). Where wink is defined as so why don't you go ahead and do it, I expect :). If you follow the wink, http://www.unicode.org/cldr/repository_access.html has the details to the files. Currently the latest is at http://unicode.org/Public/cldr/1.5.0/core.zip. Zope at this point still uses LDML 1.0 whereas the latest version is LDML 1.5. Upon casual inspection of the files it seems their basic structure is still the same, though more careful inspection is required. Hanno P.S. Updating those files is on my list for some month now, but I don't expect to have any time for that for real in the near future :( ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [OFF] Does Zope developers have time machine?
Mikhail Kashkin wrote: Looks like open source developers, especial Zope 3, have enough money to buy Time machine. Check Zope 3 profile on Ohloh.net http://www.ohloh.net/projects/4495?p=Zope+3 Codebase 138,855,676 LOC Effort (est.) 49267 Person Years $2,709,689,938 This is just due to a missing feature /bug in the ohloh website. The way ohloh works at the moment, you can either have correct contributers or correct LOC statistics. For the former you enlist the whole SVN repo of a project, for the latter you need to limit the enlistments to the trunk version of the project. As their SVN parser so far cannot follow copies and moves, trying the later in combination with all the reorganization of the codebase would result in useless contributer stats. The price is to have an awfully wrong LOC stat as you can see. Hanno P.S. Don't trust statistics you haven't forged yourself ;) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Additional locales for zope.i18n.locales.data?
[Re-including the list in the reply...] On 11/27/07, Hanno Schlichting [EMAIL PROTECTED] wrote: Nathan Yergler wrote: On 11/27/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Nathan Yergler wrote: I've run into a problem this morning with i18n in Zope3, and I'm not exactly sure what the appropriate approach is. We have a set of South African translations, paticularly Zulu (zu) and Sotho (st) that are getting picked up correctly. Upon some inspection it appears that the i18n negotiator is skipping over them, with an exception such as: The desired locale is not available. Path: /Users/nathan/p/cc.engine/branches/production/eggs/zope.i18n-3.4.0-py2.4.egg/zope/i18n/locales/data/st.xml Upon inspection I can confirm that the locales which are not working are those without .xml files in the data directory. So a few questions: * Is there an external source for those .xml files, or do we create them ourselves? The XML files are from the ICU repository (http://www.unicode.org/cldr/). AFAIK we're using quite an old version of the files. The problem is we can't simply upgrade to the newest release because the XML DTD changed and the code in zope.i18n.locales isn't very robust regarding DTD changes (which is quite hard anyway). I don't think anybody would object if the files and the code were updated *wink* ;). Where wink is defined as so why don't you go ahead and do it, I expect :). If you follow the wink, http://www.unicode.org/cldr/repository_access.html has the details to the files. Currently the latest is at http://unicode.org/Public/cldr/1.5.0/core.zip. Zope at this point still uses LDML 1.0 whereas the latest version is LDML 1.5. Upon casual inspection of the files it seems their basic structure is still the same, though more careful inspection is required. I've been avoiding even less interesting work this afternoon, taking a look at this. I started by dumping the new files into the data directory and just running the tests. As expected, things blew up in a really spectacular manner. After some wrangling I've discovered that in the newer versions of the CLDR dataset some of the information previously contained in the locale files (such as weekend start/end, etc), is now in located in a supplemental file. While this makes a certain amount of sense (it's tied to territories, not really languages), it does mean that the information needed for a Locale is no longer self-contained in a single XML file. So unfortunately it's going to require some more work to fix up the loader; I'll probably create a branch to work on this some... Hanno P.S. Updating those files is on my list for some month now, but I don't expect to have any time for that for real in the near future :( ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
