admin.site.register decorator

[Mateusz Harasymczuk]

Recently, I had to make more than one admin class in admin.py file.
I have never had a situation like this before.
I keept my admin classes in separate files in admin module.

It came to me that after each class definition you have to make
admin.site.register(Class, AdminClass)

Hence:

- Where is the best place to put this call?
after a AdminClass definition?

Try it, it looks ugly

- At the end of file with other registers?

it is similar to signals connect and template_tag registering.

Therefore it should be similarly decorated by decorator.

@register_admin(class=ModelName)
class ModelAdmin:
    pass


what do you think?


BTW:
This one is even more ugly than previous one!

How about changing:

  model_method.allow_tags = True
  model_method.short_description = _( 'Model Method' )

into:

  @options(allow_tags=True, short_description=_('Model Method'))

or:

  @allow_tags
  @short_desctiption(_('Model Method'))

?

[Russell Keith-Magee]

On Saturday, May 28, 2011, Mateusz Harasymczuk <ma...@harasymczuk.pl> wrote:
> Recently, I had to make more than one admin class in admin.py file.
> I have never had a situation like this before.
> I keept my admin classes in separate files in admin module.
>
> It came to me that after each class definition you have to make
> admin.site.register(Class, AdminClass)
>
> Hence:
>
> - Where is the best place to put this call?
> after a AdminClass definition?
>
> Try it, it looks ugly

Says you. Given that admin registration has always been like this,
that means I've been "trying it" for about 4 years, and I don't find
it ugly at all.

> - At the end of file with other registers?
>
> it is similar to signals connect and template_tag registering.
>
> Therefore it should be similarly decorated by decorator.
>
> @register_admin(class=ModelName)
> class ModelAdmin:
>     pass
>
>
> what do you think?

I think this misses several important points.

Firstly, class decorators are a relatively recent addition on Python.
They were only added in Python 2.6. Django needs to support Python
2.5.

Secondly, a class decorator must be used at the same time as the class
is declared. The statement-based registration based approach means you
can define a class in one module, and then register it in a different
module.

Thirdly, statement-based registration you can also include business
logic as part of the registration process; e.g., make a programmatic
decision as to which admin registration to use at runtime. This sort
of conditional behavior isn't an option with class decorators.

> BTW:
> This one is even more ugly than previous one!
>
> How about changing:
>
>   model_method.allow_tags = True
>   model_method.short_description = _( 'Model Method' )
>
> into:
>
>   @options(allow_tags=True, short_description=_('Model Method'))
>
> or:
>
>   @allow_tags
>   @short_desctiption(_('Model Method'))
>
> ?

I'm more sympathetic to this idea. This seems like a case where
decorators would be a good match - in fact, it could be a slight
improvement, because misspelling a function annotation won't raise an
error, but a misspelled decorator will. i.e.,

def myfunc():
...
myfunc.short_descriptionnnnn = "xxx"

isn't an error, but

@short_descriptionnn("xxx")
def myfunc():
...

Is, because the decorator named short_descriptionnn doesn't exist.

Yours,
Russ Magee %-)