[Product-Developers] New package posted - feedback sought

[Kevin Gill]

On 06/02/11 21:10, Martin Aspeli wrote:
> Hi,
>
> On 6 February 2011 19:44, Kevin Gill<kevin at movieextras.ie>  wrote:
>> Martin,
>>
>> First, thanks for your work on Dexterity. It seems like a great tool.
>> Thanks for the book also. It was a great introduction to Plone for me.
>>
>> I fixed the docs so they are valid RST.
> Great :)
>
>> With respect to the schema.Dict concept outlined below...
>>
>> I tried making a schema as you suggested below. However, it didn't work
>> out for me. Schema.Dict seems to be setup to contain elements which in
>> turn have a schema, rather than having the schema itself. I felt that I
>> was working against the framework extending schema.Dict for the row.
> Sure - you can just create a brand new field type, though, extending
> schema.Field.
>
>> I can still use a dict as the default implementation, but define it as
>> Object, but this is a bit confusing. The current (0.4) version has some
>> demo views which show both Object and Dict usage.
> It's not just confusing, it's violating the contract of schema.Object.
> Supporting list-of-objects is cool, but I think list-of-dicts will be
> more useful for most people. And we can't use a field that lies. For
> example, no dict would pass zope.schema.Object.validate()!
>
Yes, I take your point.

>> I am a bit fluffy bere, but my interpretation is that a schema.Object
>> defines a "MultiWidget".
> Correction: There's a widget (MultiWidget) that is defined as the
> default widget factory for schema.Object fields.
>
>> The MultiWidget can be implemented by an object
>> where attributes are accessed object.attr, or as a dict where attributes
>> are accessed as object[attr].
> Kind of. This is more about z3c.form's support for operating on dicts
> instead of objects, but it doesn't change the fact that the field
> you're storing (a list of dicts) isn't valid according to a the schema
> (which insista on a list of objects providing a particular interface).
>
>> The List, Dict and Set are instead
>> containers which contain rows.
> Yep.
>
>> So I could implement the Row() concept below using an Object. I tried
>> this, but the implementation confused me more than enlightened.
This is in line with what I tried. However, my Object code is settled 
down now, so this implementation my be less confusing now. I will 
implement this as soon as I get a chance.

> Maybe the way to do it is to have a subclass of schema.Object instead
> that has a _type of dict.
>
> Untested, but:
>
> from zope.schema.interfaces import IObject
>
> class IRow(IObject):
>      """A row. The schema defines dict keys.
>      """
>
> from zope.schema import Object, Field
> from zope.schema import getFields
>
> class DictRow(Object):
>      __doc__ = IRow.__doc__
>      implements(IRow)
>      _type = dict
>
>      def __init__(self, schema, **kw):
>          super(DictRow, self).__init__(schema, **kw)
>
>      def _validate(self, value):
>          super(DictRow, self)._validate(value)
>
>          # Validate the dict against the schema
>          for field in getFields(self.schema):
>              if field.__name__ not in value:
>                  raise WrongContainedType(errors, self.__name__)
>              field.validate(value)
>
>      def set(self, object, value):
>          # Override Object field logic
>          Field.set(self, object, value)
>
> You can then use this like:
>
> class IMyRow:
>      ...
>
> class IMyInterface:
>      my_dict = schema.List(value_type=DictRow(schema=IMyRow))
>
> Cheers,
> Martin
Thanks for all the input,

Kevin