#3591: add support for custom app_label and verbose_name
-------------------------------------+-------------------------------------
Reporter: | Owner: adrian
jkocherhans | Status: reopened
Type: New | Component: Core (Other)
feature | Severity: Normal
Milestone: 1.4 | Keywords:
Version: SVN | Has patch: 1
Resolution: | Needs tests: 0
Triage Stage: Fixed on | Easy pickings: 0
a branch |
Needs documentation: 0 |
Patch needs improvement: 0 |
UI/UX: 1 |
-------------------------------------+-------------------------------------
Comment (by jezdez):
Replying to [comment:109 bendavis78]:
> Thanks. For clarity's sake, I'm attaching a patch based on jezdez's
app-loading branch that applies cleanly against r16630 (current svn
trunk). I also have this on my github fork here:
https://github.com/savidworks/django/tree/app-loading.
Actually that wasn't really worth the hassle, you merged it wrong (left
some code from old commits in `admin/options.py`). I attached a correct
patch.
> For further customization, one may also specify how an ```App``` class
is initialized by providing kwargs in the ```INSTALLED_APPS``` setting:
> {{{#!python
> INSTALLED_APPS = (
> # ...
> ('myapp.apps.MyApp', {'verbose_name':'Something else','foo':'bar'}),
> )
> }}}
FWIW, I like the following notation better:
{{{#!python
INSTALLED_APPS = (
# ...
('myapp.apps.MyApp', {
'verbose_name': 'Something else',
'foo': 'bar',
}),
)
}}}
> My only question at this point is regarding the design decision to use
an options class (ie, ```MyApp.Meta```). The code suggests that other
properties may be set on your custom App class, but how might one use
custom properties on an App class? I'm sure there's a reason for not
putting verbose_name, db_prefix, and models_path in the class's main
properties, I'm just curious what the thinking is on that.
It's simple, `Meta` is used internally by Django during startup, so it
needs to be handled with care, reducing the chance to break a rather
fundamental part. In other words, it's internal API when it comes to app
loading and is configured depending on the (Python) meta class `AppBase`.
Using it in app-specific implementation details like looking for a
specific module in all apps (say for implementing the discovery pattern)
is fine though. If you want to override/set a specific option of an app
class we need to differ between those internal (via `_meta`) and the
"usual" class or instance attributes.
> On another note, I was thinking it would also be useful to allow app
authors to define how apps should be displayed to the end user.
Specifically, I think it would be nice to be able to group and order
models in a way that would be more meaningful or helpful to admin users.
Perhaps that's one thing that could be done on within a custom App class.
Although, that might be a discussion for another time.
That's certainly a good idea but not really part of this ticket. In other
words, this can be added at a later time on top of the new app classes.
--
Ticket URL: <https://code.djangoproject.com/ticket/3591#comment:110>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
