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

[Martin Aspeli]

Hi Christian,


>> 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.

Right, that's what I meant. Except that if you access IBase['b'].order 
it will be equal to IDerived['b'].order, though I don't think this is 
necessarily a problem.

>>   - 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.

Right, but I think the end result is counter-intuitive in the case I'm 
describing. I don't know if the global (non-thread-safe) was just the 
easiest implementation or a deliberate choice.

>> 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.

Yes, this could be an option. So, 'order' becomes a property and looks 
up (any maybe caches) the order from its base interfaces - loop through 
base interface in MRO, look for field with same name, if so, return its 
'raw' order, otherwise, return self's 'raw' order.

I'd be willing to implement this (if I can find the time) if people 
agree that it's a good idea.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book