| | 9 | |
| | 10 | == Justification == |
| | 11 | |
| | 12 | Reasons why an alternative to the existing functionality ([http://docs.djangoproject.com/en/dev/topics/auth/#messages user.message_set.create]) is needed: |
| | 13 | |
| | 14 | * It's not possible to create messages for anonymous users |
| | 15 | * If the same Django user is logged in twice on different computers simultaneously, they see each others' messages |
| | 16 | * User messages may get wiped even if they're not actually displayed to the user |
| | 17 | * High-load sites want to avoid the unneeded database or cache usage |
| | 18 | |
| | 19 | Reasons why a standard needs to be endorsed by Django and a 3rd party app will not suffice: |
| | 20 | |
| | 21 | * The built-in implementation is broken for a large set of use cases (above); the fact that Django actively encourages this method of messaging is a bad thing |
| | 22 | * Reusable apps don't know what 3rd party system to use and hence cannot rely on providing session feedback |
| | 23 | |
| | 24 | == Existing 3rd Party Apps == |
| | 25 | There are a number of good, pre-existing applications out there that support more robust functionality, so there is no need to re-implement a solution from scratch for inclusion in Django. The existing solutions can be combined or modified to meet Django's needs. This section is meant to evaluate some of the different session/cookie message/notification engines out there for potential inclusion in Django as a contrib app. It is a work in progress so please contribute (your notification engine here) or other changes as you see fit. |