[Zope-dev] Ordering of fields with schema interface subclassing

Christian Theune ct at gocept.com
Tue Jul 22 03:37:32 EDT 2008


On Sun, 2008-07-20 at 18:22 +0100, Martin Aspeli wrote:
> Hi,
> 
> Suppose I have an interface IDerived that's derived from an interface 
> IBase, overriding a field from it.
> 
>  >>> from zope.interface import Interface
>  >>> from zope.schema import TextLine
> 
>  >>> class IBase(Interface):
> ...     a = TextLine(title=u"a")
> ...     b = TextLine(title=u"b")
> ...     c = TextLine(title=u"c")
> 
>  >>> class IDerived(IBase):
> ...     b = TextLine(title=u"b", default=u"B")
> 
> In this case, the field ordering of zope.schema means that I'll get 
> something like this:
> 
>  >>> from zope.schema import getFieldNamesInOrder
>  >>> getFieldNamesInOrder(IDerived)
> ['a', 'c', 'b']
> 
> I had rather expected the order to be ['a', 'b', 'c']. That is, I would 
> expect a field that overrides a field from a base interface, to retain 
> the base interface's order.
> 
> One way to fix this is to do:
> 
>  >>> IDerived['b'].order = IBase['b'].order
> 
> Now both will have the same order, of course.
> 
> So, I'm wondering:
> 
>   - Is it harmful to have two fields with the same order like this when 
> they share a name?

"Sharing" a name sounds weird. The attribute get's overriden and the
field from the base class isn't considered anymore.

>   - Should this be the default behavior when deriving interfaces from 
> one another like this?

I'm not sure about that. IIRC the general issue here is that there's a
*global* counter involved when determining the order of fields.

> If the latter is desirable, I'd be willing to help find a way to 
> implement it. The field order is just an ever-increasing int that's set 
> in Field.__init__(), so we'd probably need some after-the-fact fixing up 
> of fields.

Ah. Sounds like my memories are right.

> One way to do that would be to fire an event at the end of 
> InterfaceClass.__init__() and have an event handler to fix the order, 
> though that'd make zope.interface dependent on zope.event which is 
> probably not desirable.
> 
> We could simulate the event handler in another way, of course, e.g. by 
> having the interface initialiser loop over its attributes and see if 
> they support e.g. an IOrderAware interface and call a method on it, and 
> have Field implement this.

Another way to to that would be to derive the `order` attribute of a
using the MRO (is that the mechanism relevant here?) of the class it
belongs to find inheritance ancestors and use their `order` attribute
instead. That behaviour could also easily be controlled using a flag of
the field.

Christian

-- 
Christian Theune · ct at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080722/7bdde443/attachment.bin


More information about the Zope-Dev mailing list