#14976: Add is_html flag to contrib.messages
-----------------------------------+----------------------------------------
Reporter: tedtieken | Owner: nobody
Status: new | Milestone:
Component: Contrib apps | Version: 1.2
Resolution: | Keywords: safe, messages, html
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-----------------------------------+----------------------------------------
Comment (by tedtieken):
Took a look at the session backend last night.
So long as is_html is an optional parameter on __init__ we shouldn't run
into any trouble unpickling legacy messages.
However, depending on implementation there is a chance we would end up
with a heterogeneous set of message objects: some with .is_html set, some
without a .is_html property. In tests last night with pickling, just
adding is_html=False in the method declaration was not sufficient to get
an is_html property on unpickled legacy messages.
Option 1: use a class variable to ensure there is always a value for
is_html
{{{
class Message(StrAndUnicode):
is_html = False #NEW, could be deprecated
in a future release
def __init__(self, level, message, extra_tags=None, is_html=False):
#Modified
self.level = int(level)
self.message = message
self.extra_tags = extra_tags
self.is_html = is_html #NEW
}}}
Because there is the class level is_html, even though the instance may not
have the attribute any attempt to access my_message.is_html will first
check the instance then not finding it fall back to the class.
Option 2: Omit the class level variable and live with heterogeneous
messages. The primary use case for is_html is {% if message.is_html %} in
the template. The template handles a missing attribute as False, so
heterogeneity doesn't cause any issues there. I struggle to come up with
a scenario where someone would be interacting with the messages in python
code, perhaps some kind of check to see if a message is already queued and
to add it if not.
Even though I struggle to find a way Option2 would cause trouble, it has
the potential to do so, so I'm in favor of option 1.
--
Ticket URL: <http://code.djangoproject.com/ticket/14976#comment:4>
Django <http://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-upda...@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.
