Refactor admin code to clean it up

[robert@…]

Following the mail thread ​http://groups.google.com/group/django-developers/browse_thread/thread/0e0ee390664ba078/65e6dffff7699a22#65e6dffff7699a22

I have started to refactor the admin code to
a) Make it easier to work on
b) Make it clearer what the deficiencies in the meta system are for interfaces like the admin

I will attach patches here.
The patches do include some additional changes, eg ones I have applied from other tickets.

[robert@…]

1st cut of the change and add views refactored to templates

[anonymous]

The first cut patch includes the following changes:

• I have duplicated the add and change stages, so they can be compared with the old ones, rather than replacing them. Just add /new/ on to the end of a url to see the new pages. They should look very similar.

• The template concatenation part of these stages has been replaced by a combination of templates, template tags, and helper objects. As the helper objects evolve, it should expose where it would be useful to push methods or whole classes into the meta system.

• I am currently trying to preserve the output that is produced by the old views. Nevertheless, there are sure to be bits I have changed. One particular point is whitespace : templates preserve a lot of whitespace, which is duplicated (eg in for loops). This is maybe something to tackle in the template system at some point. I will eventually start to make modifications to the output ( which imo is a lot easier with the new scheme).

This is all at a very early stage, so take it as a given that the code is in a lot of flux.

[robert@…]

I can't work out how to have this assigned to me. Boo hoo.

[Jacob]

Heh -- neither can I :)

Go ahead and leave this as "new"; we'll know it's assigned to you.

[robert@…]

updated patch

[robert@…]

patch that refactors data flattening

[robert@…]

I am having to call the patch different names, and thereby take up space, as trac gives an error when I upload with the same name.

This version of the patch (3), among other things, refactors the data flattening. I just need to a few more things to make it easy to do edit_inline type stuff from any random view. ( Sort out form field wrapper, and add a few new methods to the manipulators.)

Again, sure to be bugs in here - I know there is something wrong with 0 value integer fields in edit_inline for example. Also, I have not tested every option. One thing that I plan to make is an example model that tries out as many options as possible, so it is easy to spot regressions.

[robert@…]

Makes inline editing a piece of cake outside the admin

[robert@…]

The latest patch makes inline editing work with no hacking about in view functions.
Will post to django-devel about this.

[robert@…]

Clean up templates a bit, allow overriding edit_inline behaviour with custom templates.

[anonymous]

So this latest patch lets you do stuff like

class Set(meta.Model):

workout = meta.ForeignKey(Workout, edit_inline='edit_inline_horizontal')

This means that the template 'edit_inline_horizontal' is loaded to handle the inline stuff in the admin.

Also fixes rezrovs issues with selects. But I'm not yet convinced in the right way...
And makes the many-to-many funky js stuff work again.

[robert@…]

this thing needs cookies or something. Or give out accounts.

[robert@…]

Updated patch

[robert@…]

Fixes select fields, adding with inline related objects, sorting descending on a 'select' keyword arg. The last one is a bug fix which would work on its own.

[rjwittams]

This patch is now on the new-admin branch.

[pylorca]

when I edit the saved data (ChangeManipulator), it only shows the values for the parent table, and empty values for the child tables, but the data exists

[Adrian Holovaty]

Fixed in [1434].