I've updated my patch with a way to pass extra options to markdown/ docutils/textile that should handle any of the common cases. I've also moved render_markup into the class so that it is possible to override on an inherited class.
> 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. I'm fairly attached to the idea of the type being tied to an instance and not to the field itself as to me this feels much more flexible (examples of where I'm using this behavior on live projects are on a multi-user blogging app we use at my office where I tend to write my posts in ReST, some coworkers prefer raw HTML, and some also use Markdown). I agree with you about passing this complexity on to an end user, comments for instance should support one and only one format, but by setting a default this is possible (yes it is storing an extra integer per record in the database but this seems forgivable). Perhaps I'm the only one for which this matters but it seems like the current implementation makes it easy to satisfy both cases so I'm not entirely sure I see the downside as long as the markup_type field isn't exposed to the average user. > 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: ... I do like this idea a lot and played with an implementation of it already, my original concern was that the underlying fields will still exist on the model and it seemed strange to have two places to access the same data. Unless I'm mistaken in my understanding though, adding a descriptor doesn't mean that there still aren't three (two if markup_type ends up going away) attributes. post.body_markup_type == post.body.markup_type post.body_rendered == post.body.formatted adding the descriptor still seems like a good idea, even if only to get the unicode() behavior that you showed in your example --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
