treat None values as empty string (instead of 'None')

[tomster]

in our application the backend (sqlalchemy) returns None values, which by default are rendered as 'None' strings in the form. We had to manually convert them to empty strings when (de-) serializing. instead of either a) creating our own String type or b) manually converting them in all our views, we tried adding this treatment directly to colander.

the question is: does serializing the None value to the string 'None' ever make sense in the context colander is used? (it makes perfect sense for pythons unicode(None) to return 'None', of course).

what do you think? does the change we made make sense?

[mcdonc]

It's a good question. I'm wondering though, aside from your immediate problem of wanting None to represent the empty string during sqalchemy serialization, why would colander.String be a special case here? Should None represent the integer 0 if the node is the colander.Int type? The "today" datetime if None is passed to the serialize method of a colander.DateTime? It's currently pretty easy to explain that "colander.null represents the null value for any type and the null value is serialized by the widget as it sees fit", it's harder to start to make documentation exceptions for specific types.

[tomster]

well, the intention is to better capture the None value ''semantically''. IOW if None is to mean 'nothing' semantically, how to best represent that in a form? the empty string seems suited best for this. so the None representation of an Integer would also be the empty string IMO. so i don't see the need to make special cases.

in any case, rendering the None value as a 'None' string really never would make sense in this context.

[dnouri]

This is bugging me in my project too. I agree with Tom that rendering "None" as '' in a string widget is probably the most practical thing.

Not sure, but maybe "None" should be represented by the node's "missing" or "default"? (I have yet to figure out what the difference between the two is...)

[mcdonc]

I think I agree. I just need to decide how to deal with None in the non-String widgets too to make this change make sense in a larger context.

missing= the deserialization default
default= the serialization default

[tomster]

i think an empty string is appropriate for all text-input based widgets, regardless of their schema (i.e. integer, custom price, date etc.) it's just a representation of nothing.

[mcdonc]

One thing that might make sense here is to do this in things like String, Date, Datetime, and any other scalar value where "falseness" means null, rather than the current:

def serialize(self, node, appstruct):
    if appstruct is colander.null:
        return colander.null
    ...

We could instead interpret nullness more widely:

def serialize(self, node, appstruct):
    if not appstruct:
        return colander.null
    ...

This would mean that if you defined a schema, you could give it a default serialization value, which would get returned when the type returned null from serialize:

name = colander.SchemaNode(String(), default='')

This would be the lowest-impact change possible, I think, and it's probably right regardless of whether we decide later to return non-null values from the default types during serialization of a logically null value.

[dnouri]

Can't say I understand the implications but it sure sounds like a good way to do it.

[dnouri]

I just had to change DateTime.serialize to look like your second example to be able to move forward with my deform datetime widget that wants to support empty values.

This is how I define my schema node:

end = colander.SchemaNode(colander.DateTime(), missing=None)

Does this look right?

+1 for the change.

[tomster]

On 29.03.2011, at 22:35, dnouri wrote:

Can't say I understand the implications but it sure sounds like a good way to do it.

same here :)

Reply to this email directly or view it on GitHub:
#1 (comment)

[dnouri]

Fixed with #45.