Hi Andrei Andrei Belitski writes:

... manage_addProperties(id='tok', type='tokens', value=[1,2,3,4]) ... ... &dtml-tok; yields ['[1,', '2,', '3,', '4]'] ...

I now understand what happens: You interpret "type='tokens'" in a way, that the property value is a list. And indeed, when you access such a property, you will get a list. However, "manage_addProperty" expects the value for a property with "type='tokens'" to be a *STRING*, more precisely, a string of whitespace separated tokens. It splits this string at whitespace to obtain the list (this will be a list of *STRING*, never integers). You do not meet this expectation. What "manage_addProperty" does is to convert your list into a string (this gives '[1, 2, 3, 4]') and then splits this string at whitespace. This might be considered a bug, as it is inconsistent with "PropertyManager._updateProperty" which only converts, if the value has type string. I am not sure, however. If "manage_addProperty" would behave in the same way as "_updateProperty", then you could store your list of integers. However, the first time that you change *ANY* property of this object (through the management interface), your property would be converted to "tokens" for presentation and converted into a list of *STRING*s during "manage_editProperties". Nevertheless, I do not see a reason for "manage_addProperty" and "_updateProperty" to behave differently. What you can do? Difficult to say! Currently, you can not safely use lists of integers as property values. They can very easily be converted into lists of strings. Can you live with lists of strings? Dieter