z3c.form: data manager for PersistentDict/PersistentMapping
Hello, z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one: 1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.) 2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?) Any suggestions? Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Michael
Betreff: [Zope-dev] z3c.form: data manager forPersistentDict/PersistentMapping
Hello,
z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one:
1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.)
I think this is the right solution because there are many places in zope which do not work if a PeristentDict or PeristentList is given instead of a simple dict or list type. I'm not sure but I guess not even the zope.schema validation implementation does this part correct for list or dict fields. class List(AbstractCollection): """A field representing a List.""" implements(IList) _type = list class Dict(MinMaxLen, Iterable): """A field representing a Dict.""" implements(IDict) _type = dict But remember, using a PersistentDict or PersitentList field is only needed if you like to add or remove single values from the list or dict. Normaly you should never use a widget for PersistentList or PeristentDict objects because the widget whould set an empty dict or list within the new selected items as value. Which means a PersistentDict or PersistentList whould get replaced by a simple python type. I'm pretty sure there are many apps out there where someone defined a PersitentList and the first time a sequence widget was used for set some data the PersistentList was replaced by a simple list typ. This should not be a problem till you will call pop or remove from this list without to marke the persistent class itself as changed. (_p_changed = True) As I remember, Adam Groszer suggested that we should change the widget implementation and support to reuse the previous class as value base if a PersistentDict or PeristentList is used.
2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?)
Also the dict or list do not provide zope interfaces. I think that's fine and we should not patch python at this level. Regards Roger Ineichen
Am 12.07.2009 um 01:46 schrieb Roger Ineichen:
Hi Michael
Betreff: [Zope-dev] z3c.form: data manager forPersistentDict/PersistentMapping
Hello,
z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one:
1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.)
I think this is the right solution
I think so, too, but I was not sure.
because there are many places in zope which do not work if a PeristentDict or PeristentList is given instead of a simple dict or list type.
I'm not sure but I guess not even the zope.schema validation implementation does this part correct for list or dict fields.
This is another problem. z3c.form.datamanager.DictionaryField sets the value directly on the dict, so I'd like to use a PersistentMapping instead of a dict to get the persistency stuff for free. I use the PersistentMapping to store the schema values, as I need to keep them in the session. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Am 11.07.2009 um 17:43 schrieb Michael Howitz:
Hello,
z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one:
1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.)
2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?)
Replying to myself, as I saw on the z3c.form trunk that DictionaryField already allows providers of zope.interface.common.mapping.IMapping additionally to dict instances as the storage object. The existing solution uses the second of my possibilities, but this is not the one which I'd like to prefer, as it does not work with PersistentMapping out of the box. The idea behind this change on the trunk seems to be: to allow SessionPkgData as storage. I currently do not use it directly but use a PersistentMapping inside SessionPkgData. But maybe this is a sufficient solution for now. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Saturday 11 July 2009, Michael Howitz wrote:
z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one:
1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.)
2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?)
I looked at this recently and the reason is that for containers we did not usually want the dictionary field data manager, because we usually want the regular instance based one. I am okay to add PersistentDict and PersistentMapping to the list. I am already feeling unsure about UserDict, because people might want the instance version instead. It is better to register the adapter for the specific cases of your application. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
Am 13.07.2009 um 16:49 schrieb Stephan Richter:
On Saturday 11 July 2009, Michael Howitz wrote:
z3c.form.datamanager.DictionaryField is a data manager which is registered for fields on a dict. In its __init__ it checks whether the data object is an instance of dict. So this data manager does neither work for UserDict nor PersistentDict/PersistentMapping. I'd like to change this but there are two possibilities and I'm not sure which is the best one:
1.) Add a subclasses of DictionaryField which is registered for UserDict and which checks whether the data object is an instance of UserDict. (PersistentDict and PersistentMapping are subclasses of UserDict.)
2.) Register DictionaryField for zope.interface.common.mapping.IMapping. This might have a problem as neither UserDict nor PersistentDict/PersistentMapping seem to provide this interface. (Why?)
I looked at this recently and the reason is that for containers we did not usually want the dictionary field data manager, because we usually want the regular instance based one.
I am okay to add PersistentDict and PersistentMapping to the list. I am already feeling unsure about UserDict, because people might want the instance version instead. It is better to register the adapter for the specific cases of your application.
I'm fine with that, so I'm going to allow PersistentDict and PersistentMapping in the constructor of DictionaryField and I'll add an note why the adapter is only registered for dict and not for the other possible data storages. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (3)
-
Michael Howitz -
Roger Ineichen -
Stephan Richter