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 -~----------~----~----~----~------~----~------~--~---
