[Zope3-checkins] CVS: Zope3/src/zope/schema/tests - test_datetime.py:1.3 test_floatfield.py:1.3 test_intfield.py:1.3 test_strfield.py:1.3

[Martijn Faassen]

Fred L. Drake, Jr. wrote:

[Martijn]
>  >                                           It makes it harder to switch from
>  > a field where value entry is restricted to one where it is unrestricted.
>  > 'allowed_values' can certainly be seen as a constraint on a field instead of
>  > as an entirely new field type. I'd like to get a bit more detail about what
>  > motivated this change.
> 
> Yes, allowed_values is a constraint on a field value.  Lots of things
> are, including the basic type information.
> 
> I'm not sure what you mean "makes it harder".  In terms of the number
> of actions required to make the edit, it means changing the schema
> involves 1) removing an allowed_values argument to the field
> constructor, and 2) changing the name of the field type.  Yes, there's
> a little more than removing/commenting out the allowed_values
> argument, so it could be seen as "harder".

Harder in the sense of a future UI. The UI would presumably show a form
for the schema of the field. Adding or removing constraints is easy
then. If instead you have to swap out a different field altogether, this
means either the UI will need to become more complicated to accomodate 
for things like this (tricky in the general case, messy in the special case),
or the user will have to do a few more actions. There's also the issue of
ordering that needs to remain the same, so just a 'remove field'/'add field'
sequence may disrupt the original ordering.

The goal of this UI would be to allow people to define simple content objects
with a schema in a through the web way.

> As I'm sure you understand, the biggest aspect of schema change is
> proper support for the new schema in the application, and when
> expanding the set of allowed values for a field, the hardest part is
> ensuring the code has been tested thoroughly and that edge cases are
> properly located and checked.  There's far more than making a couple
> of edits to spelling of the schema.

It depends a lot on the application whether this is the case. For many
simple content objects it may not be the case (add a country to a list
of countries, for instance). Also schema support a dynamic fetching
allowed_values from the 'context', whatever that may be. Some applications
are written to be robust in the face of such allowed_values contractions
and expansions.

> You don't state whether you're interested in changing schema for
> projects during they're initial development or during maintenance of a
> production application.  I can only guess which is your primary
> concern, but my take on this is that the real difficulties surrounding
> schema evolution involve testing application support and migrating
> data that may need to change in some way.

Those are difficulties too in many cases. That doesn't mean that we 
should be making the UI story harder, though, unless there is significant
payoff.
 
> There's a lot more to say about schema evolution, but it really isn't
> Zope-specific, and on re-reading your comments, doesn't really pertain
> to your specific concerns (relaxing constraints, rather than
> tightening them).

My specific concerns were about switching back and forth. Of course this
use case may not be so important, but you seem to have been introducing
a multiplication of field types which *does* concern me.

We can agree schema evolution is complicated, but I don't see how 
this change helps us any either.

In fact, I still haven't heard any actual motivation from you for this
change; did I miss you describing it? Perhaps in another mail?
What are the advantages of the new situation?

> My checkin comment:
>  > Rename IValueSet to IEnumerated, and ValueSet to Enumerated.
>  > Treat these more like mixins than like directly useful things.
> 
> Martijn Faassen wrote:
>  > Why do you consider the word 'Enumerated' better here? 'Enumerated'
>  > to me implies giving each entry in some list a unique (increasing) 
>  > number. 'ValueSet' is not incredibly better, but at least 'Value' doesn't
>  > imply (integer) numbers as much as 'Enumerated' does.
> 
> I'll start by noting that "Enumerated" doesn't make me think of the
> assignment of small integers; "enum" would, but I didn't use that on
> purpose.  "Enumerated" really tells me that the value must come from a
> pre-defined list of allowed values, which is exactly what we mean.

Okay, I see in various dictionaries that to mention one by one, to
name over, is a meaning of 'enumerate' so I'll withdraw this objection,
though in programmer's terms it does frequently imply actually assigning
numbers, so we should be prepared for a few confused questions in the
future. But probably not worse than ValueSet.

[snip]

Regards,

Martijn