Changes between Version 32 and Version 33 of SessionMessages


Ignore:
Timestamp:
Oct 16, 2009, 12:46:29 PM (15 years ago)
Author:
Tobias McNulty
Comment:

potential API updates

Legend:

Unmodified
Added
Removed
Modified

  • SessionMessages

    v32 v33  
    6363 * Avoid [http://docs.python.org/library/pickle.html pickling] because of the obvious security concerns
    6464 * Provide a standard, intuitive interface so that reusable apps can provide feedback related to the current session
    65  * Support different "classes" (e.g., info, warning, error, etc.) of messages, with the ability to specify custom classes as needed
     65 * Support different "levels" (e.g., info, warning, error, etc.) of messages, with the ability to specify custom levels as needed
    6666
    6767Community criteria necessary for inclusion in the core:
    … …  
    7171=== Available Options ===
    7272
    73 ||'''Name and Link'''||'''Anonymous user support'''||'''Session Fallback'''||'''Lazy loads messages'''||'''Signed cookies'''||'''Avoids pickling'''||'''Standard interface'''||'''Classed Messages'''||
     73||'''Name and Link'''||'''Anonymous user support'''||'''Session Fallback'''||'''Lazy loads messages'''||'''Signed cookies'''||'''Avoids pickling'''||'''Standard interface'''||'''Message Levels'''||
    7474||[http://code.google.com/p/django-notify/ django-notify]||yes||yes||yes||yes||yes||yes||yes (via "tags")||
    7575||[http://github.com/danielfm/django-flash django-flash]||yes||no||no||yes||no||no||yes (but not in a standard way)||
    … …  
    8686== Potential App Names ==
    8787
    88 A number of different names have been suggested on the developers thread and elsewhere.  There is a desire not to conflict with the existing '{{messages}}' variable in templates.  Some ideas:
     88A number of different names have been suggested on the developers thread and elsewhere.  Since (a) messages seem to be a commonly understood name for this project, and (b) there's a good chance we'll use the {{ messages }} template variable as the "turning point" between the two APIs, '''the app should most likely be called 'messages' as well.'''  Here are some of the other ideas that have been discussed:
    8989
    9090 * notifications
    … …  
    9595== Potential API ==
    9696
    97 The API is under heavy discussion on the [http://groups.google.com/group/django-developers/browse_thread/thread/eba93088c649022b django-developers list].  The names of variables will be changes to reflect the app name, when one is chosen.  Following are a few different iterations of what it might look like:
     97The API is under heavy discussion on the [http://groups.google.com/group/django-developers/browse_thread/thread/eba93088c649022b django-developers list].  Following is a representation of what it might look like:
    9898
    9999{{{
    … …  
    105105}}}
    106106
    107 Using messages in your template:
     107Using messages in your template
    108108
    109109{{{
    110 {% if request.messages %}
    111 <ul class="messages">
    112         {% for message in request.messages %}
    113         <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message }}</li>
    114         {% endfor %}
     110{% if messages %}
     111<ul>
     112    {% for message in messages %}
     113    <li{% if message.level %} class="{{ message.level }}"{% endif %}>{{ message }}</li>
     114    {% endfor %}
    115115</ul>
    116116{% endif %}
    117117}}}
    118118
    119 === Pre-configured Message Classes/Levels ===
     119Notice that this is exactly the same as the existing API, with the optional addition of message.level in the LI's class attribute.
     120 
     121=== Pre-configured Message Levels ===
    120122
    121 Custom message classes may be easily configured for any type of message that does not fit into the pre-set classes, or where more granularity is needed.  Consistency is needed regarding what a given class of message means, because multiple, independent Django apps may be combined to form a single project, and consistency is desired in the display of user feedback.  It is recommended that reusable apps do not use custom message classes.
     123Custom message levels may be easily configured for any type of message that does not fit into the pre-set levels, or where more granularity is needed.  Consistency is needed regarding what a given level of message means, because multiple, independent Django apps may be combined to form a single project, and consistency is desired in the display of user feedback.  It is recommended that reusable apps do not use custom message levels, if possible.
    122124
    123125 * DEBUG: Development-related messages that will be removed before a production deployment
Back to Top