Change app name feature about django-suit

[darklow]

Thanks, good idea, will implement.
As a temporary workaround you can use MENU_ORDER to set custom app name, but then you'll have to redefine all the app models: http://django-suit.readthedocs.org/en/latest/configuration.html#menu-order

[skndn60]

+1: That is such an omission from default Django that it's mind boggling that it's not a default feature...

[grillermo]

+1 my Only feature request for django-suit

[jonashaag]

Anyone already implementing this? I'm interested in hacking on django-suit. This might be a nice first project.

[darklow]

I'll get on this today evening

[darklow]

By expanding menu features, I am thinking of rewriting menu config to a new parameter instead of adding new APP_NAMES. I would like to make one config for menu, so that all menu is in one place and not separately (like icons, names and order). Also these nested tuples are quite hard to maintain and not quite readable.

Zen of Python :)

Beautiful is better than ugly.
Simple is better than complex.
Flat is better than nested.
Readability counts.

For backwards compatiblity i'll leave current menu config for a while
My proposal would be:

SUIT_CONFIG = {
    'MENU': (
        {'app': 'sites', 'icon': 'icon-leaf'},
        {'app': 'sites', 'label': 'Our sites'},
        {'label': 'Custom parent', 'url': '/admin/custom/', 'icon': 'icon-fire'},
        {'label': 'Custom parent2', 'url': 'admin:index', 'icon': 'icon-globe',
         'permissions': 'auth.add_group'},
        {'app': 'auth', 'icon': 'icon-lock',
         'models': (
             'user', 'cms.page',
             {
                 'label': 'Custom child',
                 'url': 'admin:custom_child',
                 'permissions': 'auth.add_user'
             } )
        }
    )
}

What do you think?

[grillermo]

I like it, from the zen of python, explicit is better than implicit is also achieved here. Thou at first sigh is not clear to me what does 'auth.group' does in this bit:

        {'app': 'auth', 'icon': 'icon-lock',
         'models': (
             'user', 'auth.group',
             {
                 'label': 'Custom child',
                 'url': 'admin:custom_child',
                 'permissions': 'auth.add_user'
             } )
        }

Everything else is self explanatory and i love that.

[darklow]

'auth.group' was example, how you can "cross-link" models - add models from different apps into current app menu, to do that you must specify also app_name prefix. Some other app prefix would be more clear for sample code, i changed it to cms.page in sample.

[jonashaag]

Two suggestions:

• Use classes instead of nested dictionaries. Like werkzeug does for routing: http://werkzeug.pocoo.org/docs/routing/#quickstart Quite as readable and a hundred times more flexible.
• Use lists for readability where things get nested, and things of length 1. This is probably only a matter of how you do it in documentation but it sets an example.
  • ['foo'] instead of ('foo',)
  • [('foo', 'bar'), ('spam', 'eggs')] instead of (('foo', 'bar'), ('spam', 'eggs'))

[darklow]

@jonashaag

1. Importing custom classes into settings modules is generally a bad idea
2. The problem wasn't so much in tuples as evolving menu needs better and more general config, rather that 3-4x different settings than control one thing. Some icons are set in MENU_ICONS, some are set in MENU_ORDER and so on. What i wanted is consistency.

What's wrong with new approach using dictionaries with human readable and self-explanatory keys?

[jonashaag]

Importing stuff in settings is bad. True.

I just expect the configuration format to change a few more times and that gets much easier if you don't have to "guess" what version of configuration is used. Plus you don't have to write a configuration parser if you use classes.

The tuple thing is completely independent of the other issue. Was just a remark.

[darklow]

Configuration format won't change in future, some additional keys may appear, but i see no reason why it must change again. Current MENU_ORDER and MENU_ICONS params will be deprecated and supported only for a while.

[jonashaag]

Maybe because some user asks for a new feature that can't be expressed with the current configuration format... :)

[grillermo]

I think classes would be overkill for the current need, and a case of premature optimization. I think the use of lists does help readability.

[darklow]

BTW I just started #django-suit channel on irc.freenode.net if anyone want to chat and discuss some features or anything related to Django Suit

[darklow]

@jonashaag could you please test latest develop branch version for all your reported issues on menu including:
named apps, named models, model links, separators
Docs: http://django-suit.readthedocs.org/en/develop/configuration.html#id1

[jonashaag]

Let's move discussion of the menu config to another thread. #52