Ordered ManyToMany

[OliverMarchand]

Dear Django Developers,

I think Django is really wonderful, but I am puzzled that it contains
so few "ordering features". We often have the case that a user wants
to select from a list of possible choices (normal select) *plus* wants
to specify an ordering. Typically in applications this is done using
up/down arrows next to the box displaying the selected values.

Now I see two areas where ordering features could be useful:

=== Form Field/Widget ===

The normal ChoiceField has no ordering. I am no Javascript expert, but
I think it is very simple to write a widget where the selected choices
can also be ordered. Assuming that the chosen parameters appear in the
specified order in the GET or POST prtocol, the order can be retrieved
from the server.

=== ManyToMany Fields ===

The above would be very useful for values stored in the database as
well. It would be nice to have an OrderedManyToMany Field. That would
assume that the intermediate table for a a many-to-many relationship
would also have a column for storing the order. One could use the id
column of the intermediate table. Do you agree that it could be very
simple to write an OrderedManyToMany Field, but simply adding the up/
down feature to the widget?

2 questions:
* How do you usually handle ordering?
* Has anything been done in the direction I indicated?

thanks,
Oliver

[Patryk Zawadzki]

On Thu, Jun 26, 2008 at 3:41 PM, OliverMarchand
<oliver....@gmail.com> wrote:
> === Form Field/Widget ===
>
> The normal ChoiceField has no ordering. I am no Javascript expert, but
> I think it is very simple to write a widget where the selected choices
> can also be ordered. Assuming that the chosen parameters appear in the
> specified order in the GET or POST prtocol, the order can be retrieved
> from the server.

This requires JS and is pretty tied to *your* toolkit of choice. As
most sites already rely on one of the toolkits, Django can't depend on
any of them (at least outside of default admin templates) and
providing lengthy DOM-based widgets is a waste of time (as the site
will likely have to replace them with themed and toolkit-powered
ones). This falls outside of Django's scope.

If you need ordered lists, create models that include a sorting field.

> === ManyToMany Fields ===
>
> The above would be very useful for values stored in the database as
> well. It would be nice to have an OrderedManyToMany Field. That would
> assume that the intermediate table for a a many-to-many relationship
> would also have a column for storing the order. One could use the id
> column of the intermediate table. Do you agree that it could be very
> simple to write an OrderedManyToMany Field, but simply adding the up/
> down feature to the widget?

See above, use an explicit connecting model for many-to-many relations
and add tour sorting fields there.

--
Patryk Zawadzki
PLD Linux Distribution

[Mike Scott]

Could this not be further discussed?

I understand the need to be toolkit agnostic, but could we not take a
similar approach as the Ext js framework, where by you can use one of
many existing frameworks as your base. Then the django community can
build connectors as demanded.

I understand there are some complexities involved, but essentially its
just creating a uniform javascript API to use - not unlike the may we
have a uniform database api.

--
Jonathan Swift - "May you live every day of your life."

[Tom Tobin]

On Thu, Jun 26, 2008 at 9:05 AM, Mike Scott <mic...@gmail.com> wrote:
> I understand there are some complexities involved, but essentially its
> just creating a uniform javascript API to use - not unlike the may we
> have a uniform database api.

That's a gross understatement. :-)

The various Javascript toolkits vary wildly in their implementations;
any API attempting to unify them would necessarily become a
toolkit-onto-itself, which is *way* out of Django's scope. Many of us
probably wish that our favorite toolkit would simply be blessed for
the admin and whatnot (yay jQuery!), but that would likely become the
largest flamewar in Django history. :p

[Patryk Zawadzki]

On Thu, Jun 26, 2008 at 7:36 PM, Tom Tobin <kor...@korpios.com> wrote:
> The various Javascript toolkits vary wildly in their implementations;
> any API attempting to unify them would necessarily become a
> toolkit-onto-itself, which is *way* out of Django's scope.

Totally agreed.

> Many of us
> probably wish that our favorite toolkit would simply be blessed for
> the admin and whatnot (yay jQuery!), but that would likely become the
> largest flamewar in Django history. :p

I don't think so. As long as I'm not the author of django admin, I
don't really care what JS is uses as long as it works and the JS not
intrusive (like date and time pickers attach themselves upon page load
and are not part of the widget).

[Jonas Pfeil]

> I think Django is really wonderful, but I am puzzled that it contains
> so few "ordering features". We often have the case that a user wants
> to select from a list of possible choices (normal select) *plus* wants
> to specify an ordering. Typically in applications this is done using
> up/down arrows next to the box displaying the selected values.

This is indeed a very common use case and has been requested many
times (e.g. here [1]). The good news is that Django has scheduled the
1.0 release early September. This means it’s very probably not going
to be addressed right now. But once 1.0 is out the door the ancient
ticket #13 [2] will be (hopefully) revisited :) It has a mock-up of
the admin interface proposed [3] but no patch yet.

On the JS-lib/flamewar issue. If I recall correctly the admin is not
considered to belong to the core of Django (even though it’s _the_
killer feature for many). It's merely an application. As such it has
to use the techniques necessary. Unless someone volunteers to rewrite
a JS for Django from scratch this includes using a lib. I don't think
that's that much of an issue though. Let's just come up witch a
sensible list and have people with commit privileges vote on it :)

But post 1.0 ;)

Cheers,

Jonas

[1] http://code.djangoproject.com/ticket/6118
[2] http://code.djangoproject.com/ticket/13
[3] http://media.wilsonminer.com/images/django/related-objects-mock.gif

[OliverMarchand]

Thanks for your answer all!
I really appreciate it!

In the meantime, I have thought of the following ugly but simple
solution. A comma (or whatever character) seperated list of primary
keys in a CharField can hold the values in the order needed. Now the
only thing I need is a widget that generates this list.
Somewhat similar to: http://www.nuff-respec.com/external/javascriptgui.html
(Except that he above demo does not select, it just orders)
I would then need to write my own accessor functions for the related
model objects.

Any comment on that?
Oliver

[Mathieu Richardoz]

Hi all,

I'm a complete Django noob, but I've reached the same conclusions,
namely:
1. Django is really wonderful!
2. I need an ordered ManyToMany relationship :-)

(long story short: my project involves photos and galleries; the
photos can belong to multiple galleries with a potentially different
order in each gallery...).

Adding an explicit connecting model like Patryk Zawadzki suggests
sounds OK technically, but I think it won't be very user-friendly, at
least for the non-geeky end user.
I believe you're right Oliver, the most elegant way to do so would
probably be to create something like an OrderedManyToManyField model,
which would inherit the core ManyToManyField one.

So, good luck to the Django team for 1.0, and here's hoping this
feature gets a fair priority afterwards :-)

Regards,
Math

On 4 juil, 00:14, OliverMarchand <oliver.march...@gmail.com> wrote:
> Thanks for your answer all!
> I really appreciate it!
>
> In the meantime, I have thought of the following ugly but simple
> solution. A comma (or whatever character) seperated list of primary

> keys in a CharField can hold the values in theorderneeded. Now the

[alex....@gmail.com]

It sounds like what you are looking for is an intermediary model, this
is ticket #6905 I believe, and is currently considered a django beta
maybe-feature, which is to say if it's ready by beta, it's in 1.0 else
it will be afterwords.