Django

Code

Ticket #2248 (closed: wontfix)

Opened 3 years ago

Last modified 1 year ago

[patch] inline_models, replacement for edit_inline and core=True

Reported by: joaoma@gmail.com Assigned to: nobody
Milestone: Component: django.contrib.admin
Version: SVN Keywords: edit_inline
Cc: tyson@fallingbullets.com, jkocherhans@gmail.com, gary.wilson@gmail.com, karsten@rohrbach.de, ruckc@yahoo.com Triage Stage: Design decision needed
Has patch: 1 Needs documentation: 0
Needs tests: 1 Patch needs improvement: 0

Description

I always found the edit_inline syntax quite strange. So, I decided to try something different: let the inline models be configured in the model itself, not in the children models. I came up with the given patch, which basically allows the use of inline models the following way:

class Person(models.Model):
    name = models.CharField(maxlength=20)
    
    class Admin:
        inline_models = (
            {'model':'Child',
             'type':models.TABULAR,
             'min_num_in_admin':3,
             'max_num_in_admin':20,
             'num_extra_on_change':3,
             'fields':('name','age',) 
            },
            {'model':'Job',
             'type':models.STACKED,
             'min_num_in_admin':1,
             'max_num_in_admin':3,
             'fields':('company','salary',) 
            }
        )

class Child(models.Model):
    parent = models.ForeignKey(Person)
    name = models.CharField(maxlength=100)
    age = models.IntegerField()
    hair_color = models.CharField(maxlength=20,blank=True,null=True)

class Job(models.Model):
    person = models.ForeignKey(Person)
    company = models.CharField(maxlength=100)
    salary = models.IntegerField()
    section = models.CharField(maxlength=50)

Attachments

inline_models_in_Admin.diff (5.6 kB) - added by joaoma@gmail.com on 06/27/06 12:51:36.
patch for the new inline_models syntax
inline_models_in_Admin.2.diff (5.0 kB) - added by JoaoJoao on 06/27/06 14:16:01.
[patch] a *much* better patch for inline_models
inline_models_in_Admin.3.diff (5.0 kB) - added by JoaoJoao on 06/27/06 15:38:24.
Third patch, 'fields' isn't a good name for the core fields list, updated to 'core_fields'

Change History

06/27/06 12:51:36 changed by joaoma@gmail.com

  • attachment inline_models_in_Admin.diff added.

patch for the new inline_models syntax

06/27/06 12:54:55 changed by adrian

Oooooh! I haven't looked at the patch, but the idea is fantastic.

06/27/06 13:06:12 changed by anonymous

  • summary changed from Replacement for edit_inline and core=True to [patch] inline_models, replacement for edit_inline and core=True.

06/27/06 13:37:33 changed by JoaoJoao

I'm trying a decent patch, the one I attached is ugly.

06/27/06 14:16:01 changed by JoaoJoao

  • attachment inline_models_in_Admin.2.diff added.

[patch] a *much* better patch for inline_models

06/27/06 15:38:24 changed by JoaoJoao

  • attachment inline_models_in_Admin.3.diff added.

Third patch, 'fields' isn't a good name for the core fields list, updated to 'core_fields'

06/27/06 15:43:51 changed by Tyson Tate <tyson@fallingbullets.com>

  • cc set to tyson@fallingbullets.com.

I second this. I'd really like to see this implemented.

07/03/06 15:35:16 changed by anonymous

  • cc changed from tyson@fallingbullets.com to tyson@fallingbullets.com, jkocherhans@gmail.com.

09/07/06 15:21:40 changed by treborhudson@gmail.com

Is it possible to add something related to the the ordering of multiple inline related tables? Using vanilla 0.95 I have 3 tables related to one model currently and there doesn't seem to be a reasoning to how they're pulled in (not alphabetical by table name or not the same as the order in the models.py file). Maybe simply the order you list them in the inline_models list would be enough to satisfy this.

I like this patch. I think it consolidates the features of the admin and cleans up the model code.

11/16/06 19:46:33 changed by Gary Wilson <gary.wilson@gmail.com>

  • cc changed from tyson@fallingbullets.com, jkocherhans@gmail.com to tyson@fallingbullets.com, jkocherhans@gmail.com, gary.wilson@gmail.com.

11/23/06 02:57:26 changed by Karsten W. Rohrbach <karsten@rohrbach.de>

  • cc changed from tyson@fallingbullets.com, jkocherhans@gmail.com, gary.wilson@gmail.com to tyson@fallingbullets.com, jkocherhans@gmail.com, gary.wilson@gmail.com, karsten@rohrbach.de.

01/01/07 16:57:20 changed by ruckc@yahoo.com

  • cc changed from tyson@fallingbullets.com, jkocherhans@gmail.com, gary.wilson@gmail.com, karsten@rohrbach.de to tyson@fallingbullets.com, jkocherhans@gmail.com, gary.wilson@gmail.com, karsten@rohrbach.de, ruckc@yahoo.com.

01/17/07 16:12:17 changed by

  • milestone deleted.

Milestone Version 1.0 deleted

02/03/07 00:06:36 changed by Gary Wilson <gary.wilson@gmail.com>

  • needs_tests set to 1.
  • stage changed from Unreviewed to Design decision needed.

Adrian has an alternative suggestion here: http://groups.google.com/group/django-developers/browse_thread/thread/704546f4b30d5c86/a4ead31d11b8a79a

that uses objects:

from django.contrib.admin import TabularInline, StackedInline

    # ...

    class Admin:
        inlines = (
            TabularInline('Child', min=3, max=20, extra=3,
                fields=('name', 'age')),
            StackedInline('Job', min=1, max=3,
                fields=('company', 'salary')),
        ) 

02/03/07 03:24:01 changed by sansmojo@gmail.com

I'm not sure if this is the best place for this, but another things that would be nice about inlines is to have an option to require at least one to be created. For example:

class Admin:

inline_models = (

{'model':'Child',

'type':models.TABULAR, 'min_num_in_admin':3, 'max_num_in_admin':20, 'num_extra_on_change':3, 'num_required': 1, 'fields':('name','age',)

}, {'model':'Job',

'type':models.STACKED, 'min_num_in_admin':1, 'max_num_in_admin':3, 'fields':('company','salary',)

}

)

would require at least one Child to be created.

02/07/07 10:32:42 changed by joaoma@gmail.com

Adrian's idea is definitely better than mine, as it's cleaner and more extensible. The original idea is much easier to implement, though.

04/05/07 04:56:17 changed by philippe.raoult@gmail.com

I've been looking at the problem you're trying to solve and I must say that while your patch would really solve it.

On the other hand, it feels like a hack. From the OO point of view, it means defining how the base class is going to be used in each child class inside the base class itself! I think all the options should be in the child class. I'm not familiar with Django's internals but it would be much more natural to have all this machinery defined in the foreign key. Someone (sorry, don't have a ref) suggested adding an "edit_inline_here" keyword in the foreign key, which would do the same thing.

While this might sound like nitpicking for the current example, it means to worlds when you're trying to design a modular app. If you have a Person class somewhere in your app and you want to extend it you should be able to do so without modifying the base class.

09/16/07 07:55:20 changed by ubernostrum

  • status changed from new to closed.
  • resolution set to wontfix.

This implementation was discarded in favor of the TabularInline and related classes in newforms-admin.

11/22/07 11:51:47 changed by Antonis Christofides <anthony@itia.ntua.gr>

  • keywords set to edit_inline.

Add/Change #2248 ([patch] inline_models, replacement for edit_inline and core=True)




Change Properties
Action