April 2001 - Zope-Dev

ANN: Localizer 0.1
by palomar＠sg.uji.es 02 Apr '01

02 Apr '01

Hi all, The product Localizer version 0.1 has been released, download from: http://sourceforge.net/projects/lleu It helps to internationalize and localize Python products and web sites. It's built around the GNU gettext utilities, to do that the gettext and locale modules have been back ported from Python 2.0 to Python 1.5.2 and are included (if you already use Python 2 remove both files). As an example the Localizer itself is localized to french and spanish, though both translations aren't finished it's enough to show how to internationalize/localize python products. It has a README.txt file explaining how to use it. Hope I'll get feedback soon :) jdavid

1 0

Re: [Zope-dev] Memory problems with ParsedXML ?
by Karl Anderson 02 Apr '01

02 Apr '01

Godefroid Chapelle <gotcha(a)swing.be> writes: > Hi, > > I have imported about 2500 xml files in ParsedXML objects through the > use of : > > manage_addProduct['ParsedXML'].manage_addParsedXML(id, '', xmlString) > > This works perfectly. > > But when trying to browse the folder containing the ParsedXML instances, > a whole lot of memory is used by Zope and it took my machine down. > > Have I done something wrong or does this info help you debug the product > ? Hm, it's been pointed out to me that the inefficiency of the get_size method of ParsedXML is compounded with many instances because the standard management interface uses it. It's possible that some stuff isn't getting garbage collected until the transaction is done, and calling get_size on many ParsedXML instances in one transaction is the problem. I'll look into it. I didn't think that anyone would want to see a management screen with 2500 ParsedXML instances - or 2500 instances of anything - at one time. Have you tried using a BTree folder? Another thing to keep in mind is that the ParsedXML *product* is a DOM tree and a management interface around it. The management interface only gives you a convenient UI and a place to store a few bits that the DOM doesn't know about (content type, namespace usage, etc.). It's always more efficient to just use the DOM tree and related utilities (parsing, printing), although it is less convenient - you have to know a little bit more about what you're doing. Do you need each of those 2500 product instances? See the createDOMDocument method to create a DOM document without the management interface. It's easy to wrap a ParsedXML product around an existing DOM tree - see the initFromDOMDocument method. Currently, you have to create the persistent ParsedXML product which wraps the DOM Document node, and install that product in a Zope ObjectManager (or subclass like Folder) somewhere, to avoid a few warts. Someday I'd like to be able to just instantiate a management wrapper when I want a management interface, and then just throw it away, without bothering to add it to a folder. -- Karl Anderson karl(a)digicool.com

2 2

Re: [Zope-dev] ANN: Proposal for ZCatalog "drop-in" indexes
by Dieter Maurer 02 Apr '01

02 Apr '01

Chris McDonough writes: > I'd like comments on this proposal if you've got the time: > > http://dev.zope.org/Wikis/DevSite/Proposals/DropInIndexes Looks good. When you are changing the indexing and catalog stuff: * make the interface "index" public, such that it can be used from outside the ZCatalog * standardize the result type of index searches such that partial search results can easily be combined * provide operators "union", "intersection" and "difference" on search results. What would you gain? We could leave the rigit search interface of the ZCatalog and provide flexible queries that and/or subqueries against different indexes. Especially CMFTopic would profit much from this. Dieter

4 3

ZCatalog
by Marco Nova 01 Apr '01

01 Apr '01

Hello Guys, I'm a newbie about python and zope (about a week and a half till now), so probably most of what I say now is probably wrong. I was trying to customize the ZDiscussion product with file upload, editing of previous posts and deletes of old posts and I guess I've find a bug in the ZCatalog.uncatalogObject method. In the code there is: for btree in (data, paths): try: del btree[rid] except KeyError: LOG('Catalog', ERROR, ('uncatalogObject unsuccessfully ' 'attempted to delete rid %s ' 'from paths or data btree.' % rid)) else: try: self.__len__.change(-1) except AttributeError: pass # No managed length that means for each successfull unindex item, the __len__ counter will be decreased by 2, that's wrong. The correct code should look like: for btree in (data, paths): try: del btree[rid] except KeyError: LOG('Catalog', ERROR, ('uncatalogObject unsuccessfully ' 'attempted to delete rid %s ' 'from paths or data btree.' % rid)) try: self.__len__.change(-1) except AttributeError: pass # No managed length Or if we want to handle situations where the unindexs are unsuccessfull, we have to rewrite better the method with the use of transactions. That's all. Regards, Marco Nova Tera S.p.A. P.S. Zope Version Zope 2.3.1b2 (binary release, python 1.5.2, win32-x86) Python Version 1.5.2 (#0, Jul 30 1999, 09:52:18) [MSC 32 bit (Intel)] System Platform win32

3 2