On Sun, Feb 22, 2009 at 8:40 PM, James Turk <james.p.t...@gmail.com> 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
-~----------~----~----~----~------~----~------~--~---
