Code

Changes between Version 32 and Version 33 of SessionMessages


Ignore:
Timestamp:
10/16/09 10:46:29 (5 years ago)
Author:
tobias
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