I haven't looked too much at the patch, so I can't comment much on the implementation yet, but reading your description and the ticket, I'd to offer some thoughts, based on some of my own thoughts I've had on this in the past.
First, I don't think you actually addressed the question mentioned in the ticket regarding the 3 fields. It seems the question was whether there should be three attributes on the Python model instance, regardless of how many columns are stored in the database. On this note, though, I do have a thought: specify the markup type as an argument to the MarkupField. You already do this with a default_markup_type, but I don't see much use in having users specify their markup type at the time they enter the text. Essentially, it comes down to the developer choosing a markup type during development, rather than a user choosing it in a form. Like it or not, fewer choices generally makes for a better user experience, especially since offering just one choice means you can supply some help text alongside it. Trying to supply useful information for all the various markup options, while also helping the user decide which one is best for the (usually brief) text they want to enter ... well, it just doesn't seem it would scale well. Besides, specifying the markup type as an attribute of the model means that you can do away with one of the three database fields. Plus, it means you can specify any markup type, simply by supplying a callable instead of a string. We make this same type of differentiation when specifying the upload_to argument of FileFields. The implementation becomes both simpler and more powerful, all in one swift stroke. As for the issue Alex really did bring up in the ticket, I think there's a question as to whether the different field types can be contained by a single complex object, rather than individual attributes on the model. Basically, if you had a model like this: class InfoModel(models.Model): title = models.CharField(max_length=255) description = markup.MarkupField(formatter='markdown') I would personally rather see something like this, when it comes time to access that field's content: >>> info = InfoModel.objects.get(id=4) >>> info.title u'Django' >>> info.description <Markup: *The* web framework for perfectioni...> >>> info.description.raw u'*The* web framework for perfectionists with deadlines' >>>info.description.formatted u'<p><em>The</em> web framework for perfectionists with deadlines</p>' >>> unicode(info.description) u'<p><em>The</em> web framework for perfectionists with deadlines</p>' So essentially, one attribute contains both types of content, with the default Unicode representation being the formatted output. Since templates call __unicode__() by default, all you'd have to do is use {{ info.description }} in a template to get it right. But you could still use {{ info.description.raw }} to get the original content if necessary. Or, optionally, you can pass that through a different processor at display time if you wanted to, using {{ info.description.raw|textile }} That's just one man's opinion, but hopefully that helps the discussion a bit anyway. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---