Unknown fields in Django Model

I am hoping to to build a model for a single table that houses different types of "articles" (for argument's sake).

Each article will have MOSTLY common fields (e.g. title, date etc.) but there are cases where some article types (outside of my control) have slightly different field requirements and respective validation rules . No field will ever hold a particularly large amount of data (~100 char max).

At the moment I'm considering a model that defines all common fields and then has a text field for any unusual fields which can be detailed in XML/JSON:

class Article(models.Model):
    owner = models.ForeignKey('User')
    title = models.CharField(max_length=20)
    published = models.BooleanField()
    extra = model.TextField() # XML/JSON here for any unusual fields
    created = models.DateField(auto_now_add=True)
    modified = models.DateTimeField(auto_now=True,开发者_如何学JAVA auto_now_add=True)
    # ... etc.

I would create django form classes to handle validation as new article types are added but I'm trying to avoid having different tables for different article types.

Is there a commonly accepted way to handle a situation like this or is it largely subjective? Obviously the XML/JSON adds a bit of unfortunate overhead.

Thanks.

---

It's... a pretty awful way to do it. Normally you would put that data into a separate table and relate to it, but... whatever.

django-picklefield

---

Wouldn't you be able to do this with GenericForeignKeys ?

http://www.djangoproject.com/documentation/models/generic_relations/

You would add a:

extra_type = models.ForeignKey(ExtraType)
extra = generic.GenericForeignKey()

to your model. Seems better than including json.

---

What I do is create a model that inherits from the Article model.
If you want to create a table for each model just flag abstract = True in your metaclass.
If you want to create a One-To-One relationship with the base Article just make sure abstract = False in your meta class.
Use south to migrate your new models into the database and done.

See this article and this document for more details about model inheritance.

Is there a special reason you need such flexability of fields?
Might they change from within the backoffice?