edx/XBlock — pull request #27 by cahrens (2013-06-10 15:40:35+00:00)
Title: Unify "Stringy" versions of Integer, Boolean, and Float with the xblock ...

This is part of my Hackathon change to move the functionality of StringBoolean, StringyInteger, and StringyFloat down into xblock. I also added serialize/deserialize methods so I could remove the hard-coded list of Booleans in xml_module.py.

There are 2 risky things about this change.

1) If people were using Boolean, Integer, or Float, storing the values as strings, and then COMPARING/USING them as strings, that code would break. If there were converting them to their type when using/comparing them, that will continue to work (although it will be unnecessary, as they will already be the native type).

2) Previously, we serialized the fields as Strings (whatever was stored internally, which normally is JSON). The exception was Booleans, where we could handle either the Python bool, or a string value. My change is to serialize the JSON.dumps version, and then deserialize that (if possible). For backwards compatibility, I have to handle values as they were written out before. This why I have the except clause here:

+ try:
+ return json.loads(value)
+ except:
+ return value

The potential problem is if we have courses written out with field values that will parse as a JSON serialized string, but that was not the intention of the field. For example, a string "3.4" would deserialize as a Float, but if that value was stored in a String field, it would cause a failure. In this case, it should remain the String value "3.4".

I could add some type checking, where I see if the value returned by json.loads(value) is a bool or number. If so, I could just use the value (the String) if the field was not of the appropriate type. Thoughts about this?