On 24/03/15 11:56, Riccardo Magliocchetti wrote:
Please don't throw out the baby with the bath water :) It's quite cool
to just register a model in the admin to have a crud interface.
Exactly, this is super cool. I meant hard to extend to add other
"widgets" to the home that are not models. Or even to add different
views to a ModelAdmin.
> Editing the code is required for every, even aesthetical,
customization. I
> think it would be better to allow managers (i.e. non-coders) to
customize the
> appearence of the admin pages as much as possible without touching
the code.
> This could be accomplished by storing part of the ModelAdmin options
in the
> database.
I don't agree with "even aeasthetical" bits, there are themes
available that does not touch any django code. Still there's quite a
lot of annoyances, often reported in the ticketing system.
With these sentences I was thinking about customizing the properties of
the ModelAdmin without editing the code. For example controlling what
fields are shown in the changelist view or even controlling what models
are visible in the admin interface.
> It is not responsive.
That is a problem indeed, i'd suggest to just opt for a grid instead
of going for a full ui framework (or least a very minimal one). Am
Maintaining a bootstrap based theme and it always end up with tons of
bootstrap specific classes on every tag thus making difficult to reuse
upstream templates.
Better to coordinate with the recent css cleanup by Elky too.
Thanks for the hint, I was planning to use flexbox which seems supported
by almost all browsers ( http://caniuse.com/#feat=flexbox )
A final thought is about AdminWidget, whatever you end up with please
think of something different pattern than the Form's Media class as
makes it impossible to override css / js without touching python code.
This is one big problem to be honest and I don't think I would have the
time to solve it. There could also be some other student working on it,
so I am not sure about what is the best thing to do. My plan was to
ignore the problem and provide by default widgets that use only simple
js or do not use js at all, and let the user that wants to customize the
admin choose how to handle the problem, for example by using something
like django-sekizai.
I have still not mentioned that I also plan to rewrite contrib.admin
using class
based views.
You should well be aware of these projects, a reference of them in
your proposal would ne nice since you can possibly reuse a lot of code:
https://github.com/pydanny/django-admin2
https://github.com/AndrewIngram/django-extra-views
I am well aware of django-admin2 I also did a small patch for them, but
they use a lot of dependencies (i.e. restframework) and this makes it
almost impossible to be used as a base for contrib.admin I think.
... Unless someone decides that contrib.admin should not be included in
django anymore and have its own package (Thing that I would not
necessarily disagree with, as it would allow it to have external deps).
BTW there was a recent discussion about the admin where people
suggested they are just creating a thin rest api over models and
reimplementing the ui from scratch. A use case you may want keep into
account.
Umh, this seems to mean "throw away the admin" and start over, I would
like instead to provide also some backward-compatibility if possible. I
am going to search on the ML for this discussion anyway, thanks!
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/55114C66.40007%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
