Re: MarkupField
On Sun, Feb 22, 2009 at 4:46 PM, James Turk wrote: > > > What about other types of markup? > Some have suggested supporting more types of markup but to me this > seems outside the scope of contrib.markup which currently only > supports ReST, markdown, and textile. Should this field not meet some > peoples needs the can add their own custom markup field and base it on > this design. > Well, at the vary least, you could make it easier for one to add their own type of markup. Perhaps make the render-markup function such that one could provide their own render function without needing to subclass the field. Personally, I would use this every time as I will never use the default markdown. I will always be adding in some of the available extensions[1]. Currently, the only way to do that is to write my own render method. It would be nice to just pass that in on declaring the field without creating my own subclass etc. [1]: http://www.freewisdom.org/projects/python-markdown/Available_Extensions -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
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 >>> info.description.raw u'*The* web framework for perfectionists with deadlines' >>>info.description.formatted u'The web framework for perfectionists with deadlines' >>> unicode(info.description) u'The web framework for perfectionists with deadlines' 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 -~--~~~~--~~--~--~---
Re: MarkupField
I'll admit I'm not a markdown user generally and so I had neglected these extensions with the intent to do something similar to what the markdown filter does to handle this case but forgot before posting this patch. I'll update the patch mirror the way that the template tag works and provide a markdown_options parameter on the field. As far as an additional parameter to override the rendering function, I'm thinking that perhaps the best option is to provide render_markup as a method on the class and allow for it to be overridden. -james On Feb 22, 5:16 pm, Waylan Limberg wrote: > On Sun, Feb 22, 2009 at 4:46 PM, James Turk wrote: > > > What about other types of markup? > > Some have suggested supporting more types of markup but to me this > > seems outside the scope of contrib.markup which currently only > > supports ReST, markdown, and textile. Should this field not meet some > > peoples needs the can add their own custom markup field and base it on > > this design. > > Well, at the vary least, you could make it easier for one to add their > own type of markup. Perhaps make the render-markup function such that > one could provide their own render function without needing to > subclass the field. > > Personally, I would use this every time as I will never use the > default markdown. I will always be adding in some of the available > extensions[1]. Currently, the only way to do that is to write my own > render method. It would be nice to just pass that in on declaring the > field without creating my own subclass etc. > > [1]:http://www.freewisdom.org/projects/python-markdown/Available_Extensions > > -- > > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
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 -~--~~~~--~~--~--~---
Re: MarkupField
On Sun, Feb 22, 2009 at 8:40 PM, James Turk wrote: > >> 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). > Actually, I think there's room for a few different behaviors. Not sure that all of them should go in contrib.markup, but I see 4 possible scenarios: 1. James current implementation where each instance has the formatter set for that specific instance. 2. Marty's suggestion where the formatter is hard-coded into the model definition. 3. And a ForeignKey dependent option. Imagine a User or Project specific setting. Perhaps something like: class Project(models.Model): name = models.CharField(max_length=50) formatter = models.IntegerField(choices=MARKUP_CHOICES) class Page(models.Model): project = models.ForeignKey(Project) body = markup.MarkupField(formatter='project.formatter') I would imagine the above would work like Option 2, in that whatever formatter is set for the 'Project' is assumed for all 'Pages' in that project. No need to store the formatter_type separately in the 'Page' model. 4. However, in some situations, I could see Option 3 used in conjunction with option 1. The User sets her default choice in her User Profile. Then, whenever she creates a new instance, the formatter defaults to her preferred formatter. However, this particular instance may use a different type of formatter, so she selects a different formatter on that instance - which needs to be saved specific to that instance. Hmm, guess I'm kind of proposing two different things here aren't I? 1. Per instance formatter or not. I have a couple thoughts about how to differentiate this one. The obvious way would to have two different Fields, one for each behavior. However, what about this crazy idea: only offer one Field, but have to keywords options: "default_formatter" & "formatter" (or whatever color you choose). If "default_formatter" is set, then use that as the default, but give the end user the option of selecting a different formatter per instance. However, if "formatter" is set instead, then set that formatter for all instances with no option for the user to change it. Obviously, it would need to be worked out how to handle having both set (ignore one, generate error, or something else), which could get ugly, but I thought I'd throw it out there. 2. ForeignKey dependent default or not. Again, the obvious way would be with different fields. But what about checking to see if the string passed in matches an existing foreignkey on the model, and using that if it does - falling back to the current behavior if not. Again, this may be a bad idea. Just throwing it out to generate some thinking on it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
I think you are trying to do too many things in one place. Better concern on storing and retrieving formatted data but not on loading and configuring markup functions. Accept markup_func as argument and call it when saving. User will load markup function that he wants, and will configure it as he wants. You can provide already factored functions for contrib.markup if you want. But current implementation of render_markup with hardcoded types, sanitize and extra_args is ugly and totally unpythonic. Also, we do not subclass FileField if we want to change upload_to path. We just provide callable function. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
To me there are a few big problems with the markup_func proposal as I see it: * it removes the ability to provide multiple markup_types on a given field * what is unpythonic about taking in two extra parameters to customize the field? My goal here isn't to provide a generic "accepts-any-markup" field as providing something that generic would best be done by overloading save_as on a TextField. Sometimes in attempting to make something generic one can remove ease of use and limit useful features. I think there is a sound argument that supporting all of the markup types that contrib.markup supports is what makes the most sense. It seems like the argument that this field isn't generic enough is akin to suggesting that django.contrib.markup's templatetags aren't valuable because there are cases where one needs to support a different type of markup. -James On Mon, Feb 23, 2009 at 4:50 PM, dc wrote: > > I think you are trying to do too many things in one place. Better > concern on storing and retrieving formatted data but not on loading > and configuring markup functions. Accept markup_func as argument and > call it when saving. User will load markup function that he wants, and > will configure it as he wants. You can provide already factored > functions for contrib.markup if you want. But current implementation > of render_markup with hardcoded types, sanitize and extra_args is ugly > and totally unpythonic. > > Also, we do not subclass FileField if we want to change upload_to > path. We just provide callable function. > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
Le 23 févr. 09 à 23:27, James Turk a écrit : > To me there are a few big problems with the markup_func proposal as > I see it: > > * it removes the ability to provide multiple markup_types on a given > field > * what is unpythonic about taking in two extra parameters to > customize the field? Isn't it possible to define your choices+functions in settings? Like: MARKUP_CHOICES = { 'markdown': markdown.markdown, 'textile': textile.textile, and so on } This way you can generate your choice field iterating through keys and render appropriate markup given values. My 2c, David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
> * it removes the ability to provide multiple markup_types on a given field No if properly implemented. Again, see FileField upload_to for example. > * what is unpythonic about taking in two extra parameters to customize the > field? All markup functions take different arguments. Also different versions of one markup take different arguments. The nonsense of your way is already there in current render_markup: REST doesn't use self.sanitize and TEXTILE doesn't use self.extra_options. Even if you provide default behaviour for contrib.markup why not accept callable for markup_type as Marty suggested? > It seems like the argument that this field isn't generic enough is > akin to suggesting that django.contrib.markup's templatetags aren't valuable > because there are cases where one needs to support a different type of > markup. The argument is that this field can became more generic, extendible and better designed with very few and easy changes. But you just don't want accept it. Very strange point of view. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
On Mon, Feb 23, 2009 at 7:09 PM, dc wrote: > >> * it removes the ability to provide multiple markup_types on a given field > > No if properly implemented. Again, see FileField upload_to for > example. Or see the django-template-utils app [1]. It provides a nice wrapper so that all the formatters use the same API. You probably don't need to do exactly that, but something similar with a dict to map names to functions. Then pass that dict in as an argument. [1]: http://code.google.com/p/django-template-utils/source/browse/trunk/template_utils/markup.py -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
I certainly wasn't trying to come off as against any suggested improvements and apologize if I seemed so. I originally thought that the suggestion was to drop the option of selecting a markup type in favor of a callable or perhaps just saw the two as incompatible for some reason. I wonder if perhaps some consensus could be reached by providing a markup_choices dict as per David's suggestion which could default to a dict defined as such: DEFAULT_MARKUP_CHOICES = { 'markdown': markdown.markdown, 'restructuredtext': curry(publish_parts, writer_name='html4css1'), 'textile': curry(textile.textile, encoding='utf-8', output='utf-8') } MarkupField then takes an optional markup_choices dict and default_markup_type. This seems to provide extensibility both in adding new markup types and also in making passing additional options by simply passing in your own markup_choices dict. dc - do you have a suggestion in mind on how you'd implement a default as a callable or does this satisfy what you're looking for? i suppose that the default_markup_type could easily be a callable instead of a string if people don't find this confusing. this certainly does feel a bit more extensible, thanks for knocking me around a little on that point. i do think it'd be nice if it was easier to provide parameters to markdown/restructuredtext without having to define a custom dictionary but this isn't the worst trade off (and perhaps someone has a suggestion of cleaner behavior) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
OK, so, time to step back a bit and think big-picture. How to specify the markup type == Yes, you and your co-workers like having an internal app where everybody chooses their own markup format every time they post something. But if something's going to go into Django it's got to aim, first and foremost, for the common case, for the 80% people, and throwing choices in front of users when all they're trying to do is post a comment on your blog just ain't gonna cut it. So the first thing I'd recommend is that the per-instance choice of format go out the window. If you'd like to maintain something which does that in a third-party library, you should of course feel free, but the overwhelmingly common use case is not going to need that (and, in fact, will have its usability hurt by that -- don't make users think). The common case (and hence the one to optimize for) is going to be a developer deciding "I like Textile, this site's going to use Textile" (or similar, according to the developer's markup whims). This means that the choice of markup format *also* shouldn't be an argument to the field: if I hard-code ``format="textile"`` into a field in my app, and you want to use my app but want Markdown instead, well, you're up a creek. Also, there's no real point to trying to store that information on the model object: once you've rendered some input into HTML, you don't need to know or care what formatter was used to do that, because you've got the HTML. Which brings us to... a setting, which is probably the best way to handle the choice of markup formats. It's simple, it's easy, it gets the behavior right for most people (most sites are going to use One And Only One markup format throughout) right there out of the box. When I wrote template_utils way back once upon a time, I basically went through the above discussion in my head, and came to the same conclusion: template_utils uses a setting called ``MARKUP_FILTER`` to tell it what to do. In template_utils I opted for the setting to be a 2-tuple: a (string) name of a formatter, and a dictionary of keyword arguments to be passed in (the formatter name was resolved at runtime by a class with which one could register different formatting functions). That can work here as well, though it might make more sense to: 1. Have the setting itself be a dict, with keys ``formatter`` and ``kwargs``. This is mostly because people seem to have trouble with tuples, don't ask me why. 2. Have the formatter function actually be a dotted path of a formatter function, which will be pulled in at runtime (this avoids circular-import problems if you decide to use some bit of Django in writing your formatter function, since that would need settings, but settings need to import your function...). So, say, something like this:: MARKUP_FILTER = { 'formatter': 'markdown.markdown', 'kwargs': { 'safe_mode': True }, } Et voila: now any MarkupField for this install will, by default, Markdown-ify its text in safe mode on save. This is, incidentally, basically what I do with my own personal stuff, although I just use the formatter object out of template_utils. It works pretty well. The only problem is that somewhere, eventually, somebody is going to really need the ability to do multiple types of markup on the same site. This is where the API needs to get creative: wasting a whole extra DB column just to handle this is, well, wasteful. But I'll get to a better solution in a moment. What the field actually stores and returns == Marty's suggestion above of having some sort of custom object returned by the field, with both "raw" and processed text available (and a sensible ``__unicode__()`` so that templates Just Work) pretty much hits it on the nose, I think. This means you will need two columns in the DB, but you were going to need that anyway: once I've saved my blog entry written in Markdown, I'm gonna be pretty pissed if you throw rendered HTML back at me on the edit screen. So for this part, just do what Marty recommends. How to handle markup override = That is, also, the solution to the problem of how to do a one-off (or more-than-one-but-still-off) override of the default markup type: let the ``Markup`` object (or whatever it ends up being called, though that's a good name) expose methods for forcibly saving with a formatting option of your choice, in much the same way file fields already let you hand over some file contents and do manual saving trickery. So, suppose I write a blog entry:: >>> e = Entry.objects.create(title="Foo", body="Lorem ipsum dolor sit *amet*") where ``body`` is a ``MarkupField``. Now, let's say the default on this site is Markdown, but I really want Textile instead for this entry:: >>> e.body.save_markup(formatter='textile.textile') Or some similar API (maybe let it just get the Python callable pa
Re: MarkupField
James, you nailed it. This is exactly what we need. Well, with one minor oversight: On Tue, Feb 24, 2009 at 2:33 AM, James Bennett wrote: > [snip] > How to handle markup override > = > > That is, also, the solution to the problem of how to do a one-off (or > more-than-one-but-still-off) override of the default markup type: let > the ``Markup`` object (or whatever it ends up being called, though > that's a good name) expose methods for forcibly saving with a > formatting option of your choice, in much the same way file fields > already let you hand over some file contents and do manual saving > trickery. > > So, suppose I write a blog entry:: > > >>> e = Entry.objects.create(title="Foo", body="Lorem ipsum dolor > sit *amet*") > > where ``body`` is a ``MarkupField``. Now, let's say the default on > this site is Markdown, but I really want Textile instead for this > entry:: > > >>> e.body.save_markup(formatter='textile.textile') > [snip] This needs to accept kwargs as well. Lets take the use case were Markdown it the default. And most of the site is used by trusted users so Markdown is not in safe_mode (we allow raw html). But now, we have one field (perhaps comments) which is accessable to the general untrusted public. In that one case, I still want to use Markdown, but with ``safe_mode = True``. The only way that will work is to accept kwargs. So, using the above example: >>> e.body.save_markup(formatter='markdown.markdown', kwargs={'safe_mode': True}) -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
> This needs to accept kwargs as well. Lets take the use case were > Markdown it the default. And most of the site is used by trusted users > so Markdown is not in safe_mode (we allow raw html). But now, we have > one field (perhaps comments) which is accessable to the general > untrusted public. In that one case, I still want to use Markdown, but > with ``safe_mode = True``. The only way that will work is to accept > kwargs. So, using the above example: > > >>> e.body.save_markup(formatter='markdown.markdown', > kwargs={'safe_mode': True}) Actually I think I'd just write the method like this:: def save_markup(self, formatter, **kwargs): markup = formatter(self.raw_text, **kwargs) # ...etc... The **kwargs syntax means we don't need to pass an actual dictionary there. Also, a nice advantage of this is that you could mess around with particular models, or in particular situations, just by writing a function which calls the save_markup() method, and hooking it up to a post_save signal or similar (assuming, of course, that save_markup() does not itself trigger save()...). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MarkupField
Thanks James Bennett for the thoughtful reply, it sounds like the general consensus is that the choices feature truly is something that the majority of users wouldn't want (and I'm inclined to defer to the wisdom of Marty and James B. -- if you guys think it is mostly useless I'll accept that particular need is outside the 80%). I've got an implementation that works almost exactly to James B's last spec although I have a few general questions: It still seems a little strange to me not being able to override the markup_type on a per-field basis but only on a per-instance one.. I understand the justification that in general most models should not set a default markup type (allowing users to set a site-wide default), but if you are overriding particular instances via the save_markup(formatter) method is it not reasonable to still have an optional formatter parameter to MarkupField that does the same thing? In order for my implementation of Markup.save_markup to alter the fields directly it stores a reference to the instance/field_name/rendered_field_name.. is this the preferred method or are there suggestions on a better implementation of Markup? class Markup(object): def __init__(self, instance, field_name, rendered_field_name): self.instance = instance self.field_name = field_name self.rendered_field_name = rendered_field_name def _get_raw(self): return self.instance.__dict__[self.field_name] def _set_raw(self, val): setattr(self.instance, self.field_name, val) raw = property(_get_raw, _set_raw) def _get_rendered(self): return getattr(self.instance, self.rendered_field_name) rendered = property(_get_rendered) def save_markup(self, formatter, **kwargs): if not callable(formatter): formatter = load_renderer(formatter) setattr(self.instance, self.rendered_field_name, formatter(self.raw)) -James On Tue, Feb 24, 2009 at 9:01 AM, Waylan Limberg wrote: > > James, you nailed it. This is exactly what we need. Well, with one > minor oversight: > > On Tue, Feb 24, 2009 at 2:33 AM, James Bennett > wrote: > > > [snip] > > How to handle markup override > > = > > > > That is, also, the solution to the problem of how to do a one-off (or > > more-than-one-but-still-off) override of the default markup type: let > > the ``Markup`` object (or whatever it ends up being called, though > > that's a good name) expose methods for forcibly saving with a > > formatting option of your choice, in much the same way file fields > > already let you hand over some file contents and do manual saving > > trickery. > > > > So, suppose I write a blog entry:: > > > >>>> e = Entry.objects.create(title="Foo", body="Lorem ipsum dolor > > sit *amet*") > > > > where ``body`` is a ``MarkupField``. Now, let's say the default on > > this site is Markdown, but I really want Textile instead for this > > entry:: > > > >>>> e.body.save_markup(formatter='textile.textile') > > > [snip] > > This needs to accept kwargs as well. Lets take the use case were > Markdown it the default. And most of the site is used by trusted users > so Markdown is not in safe_mode (we allow raw html). But now, we have > one field (perhaps comments) which is accessable to the general > untrusted public. In that one case, I still want to use Markdown, but > with ``safe_mode = True``. The only way that will work is to accept > kwargs. So, using the above example: > >>>> e.body.save_markup(formatter='markdown.markdown', > kwargs={'safe_mode': True}) > > > -- > > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---