Code

Changes between Version 31 and Version 32 of SessionMessages


Ignore:
Timestamp:
10/16/09 10:38:31 (5 years ago)
Author:
tobias
Comment:

update transition plan

Legend:

Unmodified
Added
Removed
Modified
  • SessionMessages

    v31 v32  
    2222 * Reusable apps don't know what 3rd party system to use and hence cannot rely on providing session feedback  
    2323 
    24 == Integrating with the Existing API == 
     24== The Existing API == 
    2525 
    26 It is not possible nor desirable to integrate with the existing API because it is tied directly to a related manager on the user model and cannot be extended to support the additional functionality in this proposal (without some ugly hacks).  There are several possible solutions to this conflict (we don't really need or want two messaging APIs in the core); feel free to add more: 
     26It seems to be the consensus on the mailing list that we have no desire to maintain two messaging APIs in the core and the proposed app will adequately replace all current uses of the [http://docs.djangoproject.com/en/dev/topics/auth/#messages existing message API].  It has been noted by several people, therefore, that we need a deprecation plan for removing the old API that makes the transition easy for any apps currently using it. 
    2727 
    28  * In the documentation, cast the user messaging API in a vary narrow use; e.g., for administrator messages to specific users 
    29  * Phase out user messages entirely 
     28There are several parts to the user message API, each with different options for transition: 
    3029 
    31 === Deprecation Plan === 
     30 * '''models.User.message_set.create(message)''': because this is a just a related manager on a model, and we don't have access to the request (or much else) inside the create() method, it's not possible to override this method with one that stores messages in the new session or cookie backend.  It is, however, completely feasible to retrieve and display any messages set in the user Message model from the new app (see below). 
    3231 
    33 The thread on the mailing list seems to be leaning towards deprecating the old API rather than keeping it around in parallel with the new one.  If deprecating is the right answer, what follows is a rough plan of how that might play out.  Many details are still missing and the plan needs to be fleshed out further in the coming days/weeks. 
     32 * '''{{ messages }}''': Since this is set in a context processor, we can replace this variable in the template context with one that will lazily wrap messages stored in the user Message model and messages stored in the newer session and cookie backends. 
     33 
     34 * '''models.User.get_and_delete_messages()''': As with message_set.create, it is not possible to override this method with one that can retrieve messages from the proposed session and cookie backends.  In the transition API, however, it will continue to retrieve (and delete) messages stored in the user Message model via message_set.create (as it has in the past). 
     35 
     36=== Transition Plan === 
     37 
     38What follows is a rough plan of how to introduce the new API and deprecate the existing one.  Some details are still missing and the plan needs to be fleshed out further in the coming days/weeks. 
    3439 
    3540 * '''Django 1.2''' 
    3641    * Introduce the proposed messaging app 
    37     * Deprecate the existing API and mark it as such in the documentation.  Retain the same functionality. 
    38     * contrib apps in Django still use the old API 
     42    * Replace {{ messages }} with lazily loaded messages from both the old (user message) and new (session/cookie) storages 
     43    * Deprecate the existing API and mark it as such in the documentation.  Retain the same functionality.  Raise a PendingDeprecationWarning when used. 
     44    * Update contrib apps (auth and admin) and generic views (create_object, update_object, and delete_object) in Django to use the new API 
    3945 * '''Django 1.3''' 
    40     * Update all contrib apps in Django to use the new API 
    41     * Retain the same functionality in the old API, but raise a deprecation warning when it is used 
     46    * Retain the same functionality in the old API, but raise a DeprecationWarning when it is used 
    4247 * '''Django 1.4''' 
    4348    * Remove the old API.  This includes the Message model and any methods in contrib.auth that use it (such as get_and_delete_messages).