- Zope - Zope lists

RE: [Zope] Searching for and displaying properties
by Sinang, Danny 26 Jun '06

26 Jun '06

> manage_addProperty does not trigger recataloguing of the object even if its a subclass of CatalogAwareness. You should ? > either call > obj.reindex_object() or at least obj.index_object(), if your class has the CatalogAwareness-Mixin or you use the catalog > API: > yourcatalog.catalog_object(obj,obj.absolute_url_path()) > After that, your metadata should show up nicely w/o indexing the whole object tree. Thanks Tino. I'd like to try your suggestion, but I don't know how to refer to the object that needs recataloguing. Can you help ? Again, here's my code that calls manage_addProperty. <code> wf = context.GeneralWorkflow instance_id = wf.addInstance( process_id=process, customer=jobname, comments=comment, title=subject, activation=1) wf.getInstance(instance_id).manage_addProperty('jobname', 'ABC12345', 'string') </code> - Danny

2 1

Re: [Zope] get non-acquired attributes of an instance
by thomas desvenain 26 Jun '06

26 Jun '06

aq_base(aq_inner(obj)).__dict__ ? hmm it doesn't works, i get metadata only, and with dir(aq_base(aq_inner(test.toto))) i get acquired methods too... 2006/6/26, Andreas Jung <lists(a)zopyx.com>: > > > --On 26. Juni 2006 10:30:50 +0200 thomas desvenain > <thomas.desvenain(a)gmail.com> wrote: > > > hello, > > > > is it possible to get the list of all an object's attributes, excepted > > the ones acquired from parents ? > > > > aq_base(aq_inner(obj)).__dict__ ? > > -aj > > -- Thomas Desvenain Junior Plone/Zope analyst-developer, Looking for a Job ! Now, trainee at Institut National de Recherche Agronomique Mathématiques, Informatique et Génôme laboratory 78350 Jouy en Josas +33 (0)1 34 65 29 43

2 1

[Ann] "AdvancedQuery 2.0" supports incremental ranking
by Dieter Maurer 25 Jun '06

25 Jun '06

"AdvancedQuery" is a search engine similar to Zope's "ZCatalog" that tries to remove many of "ZCatalog"s limitations and strives heavily for efficiency. "AdvancedQuery"s can be arbitrarily built from elementary index queries with "and", "or" and "not". This gives richer query expressiveness than "ZCatalog". "AdvancedQuery" supports incremental multi-level sorting. For highest efficiency, "AdvancedQuery" can (and probably should) be used with "ManagableIndex" and "IncrementalSearch2". New in version 2.0: support for incremental ranking. A rank determination rule can be specified by a sequence of weighted queries. The rank of a document is then either the sum or the maximum of the weights for queries that match the document. This kind of ranking is a sort specification and can be combined with other sort specifications in the usual way (leading to multi-level sorting). Ranking is performed incrementally. This way, ranking can be quite efficient when you only look at the first (few hundred) hits -- despite the fact that ranking is very expensive in general. More information and download: <http://www.dieter.handshake.de/pyprojects/zope> -- Dieter

1 0

Searching for and displaying properties
by Sinang, Danny 24 Jun '06

24 Jun '06

Dear All, I managed to add a property to an object by using the manage_addproperty () method. However, if I don't issue a manage.reindexIndex () for the new property, it won't come out in the catalog search results. So I issue reindexIndex (), but when I finally try to display the property, all I get is 'Missing Value'. But if I then issue the command refreshCatalog(clear=1), the property is now visible. Although refreshCatalog works, it would gobble up the server's CPU and memory resources everytime its run. My question is, is there another command I can use instead of refreshCatalog to make the property display ? Below is the code I'm talking about : wf = context.GeneralWorkflow instance_id = wf.addInstance( process_id=process, customer=jobname, comments=comment, title=subject, activation=1) wf.getInstance(instance_id).manage_addProperty('jobname', 'ABC12345', 'string') wf.Catalog.manage_reindexIndex(ids=['jobname'], REQUEST=None, RESPONSE=None, URL1=None) jobs = cat.searchResults({'jobname':'ABC12345'}) for j in jobs: print j.jobname Regards, Danny

3 2

RE: [Zope] Searching for and displaying properties
by Sinang, Danny 24 Jun '06

24 Jun '06

> This add a property to an object but it has nothing to do with adding > *metadata* to a ZCatalog instance. Please read the ZCatalog chapter of the Zope Book 2.7 edition. It carefully explains > what *metadata* in the ZCatalog context means. The short version: a Zcatalog search returns > *proxy* objects and the attrs of the proxy object contain only the values of the original object where you have > configured a metadata in the Zcatalog. Having read the Zope 2.7 ZCatalog chapter, I think I can say there's always been a metadata column called "jobname". So going back to my original question, is there a way for me not to have to mass-refresh my entire catalog just to be able to display my properties ? Regards, Danny

3 2

RE: [Zope] Searching for and displaying properties
by Sinang, Danny 24 Jun '06

24 Jun '06

> That's the official ZCatalog API. Otherwise find your objects through a catalog search and reindex them individually. I already did the reindexing just before the search and it didn't work. In any case, I may have found a workaround by using getObject(). According to http://www.plope.com/Books/2_7Edition/SearchingZCatalog.stx#2-10 : getObject() Returns the actual zope object from the result object. This is useful if you want to examine or show an attribute or method of the object that isn't in the metadata--once we have the actual object, we can get any normal attribute or method of it. However, be careful not to use this instead of defining metadata. Metadata, being stored in the catalog, is pre-calculated and quickly accessed; getting the same type of information by using getObject().attribute_name requires actually pulling your real object from the ZODB and may be a good deal slower. On the other hand, stuffing everything you might ever need into metadata will slow down all querying of your catalog, so you'll want to strike a balance. A good idea is to list in metadata those things that would normally appear on a tabular search results form; other things that might be needed less commonly (and for fewer result objects at a time) can be retried with getObject. I tried it and it works. My code now looks like this : <code> wf = context.GeneralWorkflow cat = wf.Catalog jobs = cat.searchResults({'jobname':'ABC12345'}) for j in jobs: print j.getObject().jobname return printed </code> My only question now is ... How much slower is this solution than using the jobname metadata (assuming it worked). - Danny

2 1

RE: [Zope] Searching for and displaying properties
by Sinang, Danny 24 Jun '06

24 Jun '06

> Click on "update catalog" in the Advanced tab or use the refreshCatalog() > method of the ZCatalog (described in its interfaces.py file). refreshCatalog() is exactly what I was forced to use in the first place. I was wondering if there exists an alternative function / method that won't require refreshing / reindexing the entire Catalog. Regards, Danny

2 1

RE: [Zope] Searching for and displaying properties
by Sinang, Danny 24 Jun '06

24 Jun '06

> 'jobname' is added as *metadata* to your catalog? Not sure if using manage_addProperty () to add jobname is equivalent to adding it as *metadata* . <code> manage_addProperty('jobname', 'ABC12345', 'string') </code>

2 1

Issue 1896: manage_changeProperties() vs manage_addProperty()
by Berthold Stöger 23 Jun '06

23 Jun '06

Hello, in Issue #1896 (http://www.zope.org/Collectors/Zope/1896) I describe a difference in the behaviour of manage_changeProperties() and of manage_addProperty(): An array of ints is converted to an array of strings with manage_addProperty(), but not with manage_changeProperties(). You closed the bug with the following comment: > Type converters only deal with the outer type but not with the types of > contained elements. This should be handled on the application level. Well, first of all this isn't true as my script shows (note: the report has a buggy test script, correct one attached): When using manage_addProperty(), the contents of the array *are* converted from integers to strings. Or maybe I'm reading you wrong? Furthermore, this still doesn't explain why the two functions behave differently. Digging a bit deeper, I found out that the culprit is in lib/python/OFS/PropertyManager.py: In manage_addProperty() the type_converter is always called, but in _updateProperty() the type_converter is only called if the value is a string. Similar code can be found in lib/python/OFS/PropertySheets.py Maybe there is some reason for this behaviour, but I can't think of one. Either of the following diffs (of course not both!) fixes the problem for me: --- lib/python/OFS/PropertyManager.py.old 2006-06-18 09:56:13.000000000 +0200 +++ lib/python/OFS/PropertyManager.py 2006-06-18 09:57:01.000000000 +0200 @@ -202,16 +202,13 @@ self._setPropValue(id, value) def _updateProperty(self, id, value): - # Update the value of an existing property. If value - # is a string, an attempt will be made to convert - # the value to the type of the existing property. + # Update the value of an existing property. self._wrapperCheck(value) if not self.hasProperty(id): raise BadRequest, 'The property %s does not exist' % escape(id) - if type(value)==type(''): - proptype=self.getPropertyType(id) or 'string' - if type_converters.has_key(proptype): - value=type_converters[proptype](value) + proptype=self.getPropertyType(id) or 'string' + if type_converters.has_key(proptype): + value=type_converters[proptype](value) self._setPropValue(id, value) def _delProperty(self, id): --- lib/python/OFS/PropertyManager.py.old 2006-06-18 09:56:13.000000000 +0200 +++ lib/python/OFS/PropertyManager.py 2006-06-20 12:31:56.000000000 +0200 @@ -265,14 +265,14 @@ # Web interface - def manage_addProperty(self, id, value, type, REQUEST=None): + def manage_addProperty(self, id, value, proptype, REQUEST=None): """Add a new property via the web. Sets a new property with the given id, type, and value. """ - if type_converters.has_key(type): - value=type_converters[type](value) - self._setProperty(id.strip(), value, type) + if type(value)==type('') and type_converters.has_key(proptype): + value=type_converters[proptype](value) + self._setProperty(id.strip(), value, proptype) if REQUEST is not None: return self.manage_propertiesForm(self, REQUEST) This is the working version of my test script: ## Script (Python) "test" ##bind container=container ##bind context=context ##bind namespace= ##bind script=script ##bind subpath=traverse_subpath ##parameters= ##title= ## def is_int(i): try: i + 1 return "is int" except: return "isn't int" obj = script try: obj.manage_delProperties(ids=('testproperty',)) except: pass print "Add property..." obj.manage_addProperty('testproperty', [1,2,3], 'lines') for i in obj.testproperty: print is_int(i) print "Change property..." obj.manage_changeProperties(testproperty=[1,2,3]) for i in obj.testproperty: print is_int(i) return printed Thank you. PS: I know this doesn't seem important, but it gave me a hard to debug problem once.

2 1

Basic Authentication SSL Redirector
by Josef Meile 23 Jun '06

23 Jun '06

Hi, After having started the thread about securing CookieCrumbler[1], I figured out that it was better to secure Basic Authentication instead. So, I just created a new Product, called JMSSLBasicAuth[2], which is based on the CookieCrumbler Transversal Hook. Instead of Cookie Authentication, I will redirect insecure Basic Authentication requests to ssl. I have tested it and it seems to work. I'm planning to use it in production websites, so, I would really appreciate if you could give me some constructive feedback about the product (See reference [2]), ie: what can I improve, change, or add? Thanks in advanced Josef [1] SSL Redirect for CookieCrumbler http://mail.zope.org/pipermail/zope/2006-June/166784.html [2] JMSSLBasicAuth - Secure Basic Authentication Redirector http://www.zope.org/Members/jmeile/JMSSLBasicAuth

2 5