In my Django app, I have a model (lets call it Foo) with a field called "type". I'd like to use Foo.type to indicate what type the specific instance of Foo is (possible choices are "Number", "Date", "Single Line of Text", "Multiple Lines of Text", and a few others).

There are two things I'd like the "type" field to end up affecting; the way a value is converted from its normal type to text (for example, in "Date", it may be str(the_date.isoformat())), and the way a value is converted from text to the specified type (in "Date", it may be datetime.date.fromtimestamp(the_text)).

To me, this seems like the Strategy pattern (I may be completely wrong, and feel free to correct me if I am). My question is, what's the proper way to code this in a web MVC framework?

In a client-side app, I'd create a Type class with abstract methods "serialize()" and "unserialize()", override those methods in subclasses of Type (such as NumberType and DateType), and dynamically set the "type" field of a newly-instantiated Foo to the appropriate Type subclass at runtime.

In a web framework, it's not quite as straightforward for me. Right now, the way that makes the most sense is to define Foo.type as a Small Integer field and define a limited set of choices (0 = "Number", 1 = "Date", 2 = "Single Line of Text", etc.) in the code. Then, when a Foo object is instantiated, use a Factory method to look at the value of the instance's "type" field and plug in the correct Type subclass (as described in the paragraph above). Foo would also have serialize() and unserialize() methods, which would delegate directly to the plugged-in Type subclass.

How does this design sound? I've never run into this issue before, so I'd really like to know if other people have, and how they've solved it.