Design goals - outline needed. about django-admin2

[audreyfeldroy]

My UI goal and theming docs addition is only a tiny piece of this. @pydanny, maybe write up your thoughts when you have time later?

[pydanny]

First off, I finally got a chance to sit and think about this issue and wrote up https://django-admin2.readthedocs.org/en/latest/design.html. Thank you for submitting it!

As for your bullets

• How do the admin views interact with the admin instance? Do they have access to an Admin2 instance? Do the views use the Admin2 instance for common tasks like getting a queryset?

See issue #99

• How are related models handled with the desired registration scheme - are they still set up independently and added to the "main" Admin2 instance (inlines = [ ... ])?

I like this pattern as it's very intuitive so we'll stick with it for now. Once we get a version of it working, we can explore other API methods.

• Is the goal to closely follow the "old" admin with respect to configuration (admin.list_display_fields, ...)? Or would it be preferable to reduce the amount of configuration on the Admin2 class and push more of it onto the CBVs?

I like the idea of being able to define it in the Admin2 class and then allow individual CBVs the capability to override it as needed. This would allow projects the capability for a lot more control. However, I'm not sure how we would define this API yet. Once we get basic functionality we'll prototype this out.

• Is there a high level menu abstraction (like a get_menu_entries that returns all Entries for an Admin2 instance)?

You mean something like a Admin2.get_model_instances() or a Admin2.get_menu_items().

[RaphaelKimmig]

@pydanny

Regarding menu abstraction I was talking about something like get_menu_items() (see #27).

[pydanny]

@RaphaelKimmig I think https://django-admin2.readthedocs.org/en/latest/design.html addresses your original request. As new design discussions emerge, please open new issues! 👍