Ya this is much more needed for me on ForeignKey's, but that's like adding magical models (which I like!).
You'd have to add left order, and right order fields, on the model referenced in the ForeignKey, to have an OrderedForeignKey field. This, without migrations, would not be fun with DB maintenance :) On Nov 12, 7:23 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I'd just like to point out that this isn't something to solve just for > many to many's, it's also for ForeignKeys. > > On Nov 12, 6:58 pm, Jonas Pfeil <[EMAIL PROTECTED]> wrote: > > > The idea of an ordered many-to-many field is very old [1] and has been > > proposed a lot over the years (e.g. [2], [3]). So the general > > consensus seems to be that we want such a thing. I’d like to share > > some thoughts on how to approach the whole ordering problem on the API > > side (leaving aside the JavaScript implementation issues for a > > moment). > > > I can think of three things we would want an ordering UI for in the > > admin: > > > * A yet to be devised OrderedManyToMany field > > * A ManyToMany field with an intermediary model > > * Ordinary models (in the change list) > > > OrderedManyToMany > > ================= > > > We could either subclass ManyToMany or introduce another option (like > > ordered=True). I think subclassing is better, because of the extra > > functions we could add to manipulate the many-to-many set. Like: > > > * move_up/down(item) – Moves the item one slot up or down in the list > > * swap(a, b) – Swaps the places of item a and b > > * insert(item, position) – Puts the item at the stated position, > > pushing the other items down (or we just add a position argument to add > > () and create()) > > * push/pop() – Or just add/create() without position argument and > > remove() with no arguments at all > > > Of course the existing functions like all(), assignment of a list to > > the field and so on should all respect the order too. > > > Many-to-many fields with intermediary models should also return the > > correct order when reading the set, even if they do not support create > > (), add() and assignment of a list. > > > Ordinary models and ManyToMany fields with an intermediary model > > ================================================== > > > These two use cases share the need to define the field which should be > > used for ordering. I found it difficult to come up with a name that > > can’t be confused with 'ordering' too easily. How about this: > > > class Membership(models.Model): > > order = models.IntegerField() > > > class Meta: > > order_control_field = ‘order’ > > > On a side note: When the change list in the admin is ordered on > > something else than the order_control_field, an ordering UI stops > > making sense (see description on [4]). A solution would be to just > > switch off ordering on other fields if order_control_field is set. For > > inlines this problem is nonexistent as the admin currently doesn’t > > reorder the inlined items when you click the column header. > > > Ok, these are my ideas on how ordering could work for the user. What > > do people think? > > > Cheers, > > > Jonas > > > [1]http://code.djangoproject.com/ticket/13 > > [2]http://code.djangoproject.com/ticket/6118 > > [3]http://groups.google.am/group/django-developers/browse_thread/thread/... > > [4]http://www.djangosnippets.org/snippets/998/ --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
