Allow .warning and .error classes on more attributes in base.py

[Daniele Procida]

In ​https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display there's an example:

class Person(models.Model):
    ...
    def colored_name(self):
        return '<span style="color: #%s;">%s %s</span>' % (self.color_code, self.first_name, self.last_name)
    colored_name.allow_tags = True

class PersonAdmin(admin.ModelAdmin):
    list_display = ('first_name', 'last_name', 'colored_name')

This sort of thing could be really useful for reporting potential problems in the admin, both in list views and with readonly_fields, if it were possible to use classes that already exist in base.css for errors and warnings: ​https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/base.css#L524 for some other HTML attributes as well (<span> for example).

At present the Django admin does very well at informing the user of errors when something is saved in the admin. With a bit of effort it's quite easy to provide warnings too.

Being able to make use of classes for warnings and errors would make it easier to give information to the user about problematic conditions that already exist through the standard Django admin.

Does this seem like a good idea?

[Łukasz Rekucki]

I'm not sure what is actually requested here. Django's Admin can provide error styles only for standard UI components (which it does now). Building a generic '.error' and '.warning' classes that could be reused without tweaks for some other markup would be most likely impossible.

[Daniele Procida]

In the documentation example I gave: ​https://docs.djangoproject.com/en/1.4/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display there's a suggested use:

    def colored_name(self):
        return '<span style="color: #%s;">%s %s</span>' % (self.color_code, self.first_name, self.last_name)
    colored_name.allow_tags = True

So here we are making it very easy for the Django developer to put some styled HTML into the admin. The HTML and the styling in this example are being computed.

The most obvious use I can think of for such computation is to advise or warn the user about some potential problem.

So, it would be even nicer if we made available some CSS classes that the developer could make use of in situations like this, so instead of a messy style attribute in the HTML, a simple class="warning" (for example) could be used.

[Preston Holmes]

Replying to EvilDMP:

So, it would be even nicer if we made available some CSS classes that the developer could make use of in situations like this, so instead of a messy style attribute in the HTML, a simple class="warning" (for example) could be used.

Are you saying providing some bootstrap like, publicly documented, admin compatible styling classes? Still not clear on what the request is.

[Daniele Procida]

Yes, exactly that: publicly documented, admin compatible styling classes - sorry if that wasn't clearer.

There are already some at ​https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/base.css#L507

So for example, we could add something like:

.warningnote {
    font-size: 12px !important;
    display: block;
    padding: 4px 5px 4px 25px;
    margin: 0 0 3px 0;
    border: 1px solid orange;
    color: orange;
    background: #ffc url(../img/icon_warning.gif) 5px .3em no-repeat;
}

to match the existing errornote style (this would require the creation of an icon_warning.gif too). And perhaps an alertnote style too.

I can see a case for:

• .alertnote: to alert the user about a condition they should be aware of
• .warningnote: to warn about a condition that might be a problem
• .problemnote: to inform the user about a condition that is a problem
• .errornote (which already exists): to inform the user that something is wrong

If this doesn't all seem wrong-headed I can create a pull request for it.

[Preston Holmes]

Thanks for the clarification. While not wrong headed in intent, it won't work for a couple reasons. After checking with Julien who is far more familiar with the admin than I, it was decided that the admin CSS is both in a state where it should not be documented, and also not be added to to support anything outside of its own current core needs.

Given that there are easy enough ways to add custom CSS - going to leave this issue as closed.