Should InterfaceObjectIO respect IField.order when updating from external object?

[cutz]

When IntefaceObjectIO updates from an external representation should it respect the order of the field? If dependent fields exist, for example a Choice field whose vocabulary is an IContextSourceBinder whose implementation depends on another field value, properly updating the object becomes order dependent. For example something like this pseudo code setup:

STATES = SimpleVocabulary(
    [SimpleTerm(u'TX'),
     SimpleTerm(u'OK')])

TX_CITIES = SimpleVocabulary(
    [SimpleTerm(u'Dallas'),
     SimpleTerm(u'Austin')])

OK_CITIES = SimpleVocabulary(
    [SimpleTerm(u'Norman'),
     SimpleTerm(u'Tulsa')])

def city_vocab_finder(home_location):
    if home_location.state == 'TX':
        return TX_CITIES
    elif home_location.state == 'OK':
        return OK_CITIES
    return SimpleVocabulary()
interface.alsoProvides(city_vocab_finder, IContextSourceBinder)
    

class IHomeLocation(interface.Interface):

    state = Choice(title=u'The state you are from',
                   vocabulary=STATES,
                   required=True)

    city = Choice(title=u'The city you are from',
                  vocabulary=city_vocab_finder,
                  required=True)

zope.schema.interfaces.IField defines an order property. That is respected by createFieldProperties and createDirectFieldProperties. Can an argument be made that internalization should also respect it? If not by default should there be a way to enable respecting it?

Should this use case be solved in another way entirely?

[jamadden]

That’s a great question. I find myself really conflicted. On the one hand, I can see the practical benefits in examples like yours. On the other hand, it seems like such state-dependent, uhh, state, really isn’t a great thing (consider functional programming ). On the gripping hand, transitional states are a thing and even SQL triggers allow for that.

So let’s consider this, especially in terms of best practices. Other “form” libraries like deform and colander may provide some insight. (It is important to consider that many of them are designed for building UI, in which order has a different importance. )

[cutz]

I feel similar. On the one hand order dependence feels dirty, on the other hand when these objects map to UI constructs/forms (user profiles for example) it seems like it makes sense to handle that at this layer.

I guess a work around is to handle this in custom externalizers that know about dependent fields and updates them in the correct order. I'll have to look in to what if anything colander and deform do about this.