| | 191 | |
| | 192 | === Formset improvements === |
| | 193 | * "Complexity:" Easy |
| | 194 | |
| | 195 | One of the big problems in web programming is making a request object available everywhere that it might be needed. Some frameworks tackle this problem by using a threadlocal. A threadlocal is essentially a global variable that allows you to access stateful information, such as the currently active request. |
| | 196 | |
| | 197 | Django takes a more structured approach, and encourages you to use function arguments and class attributes to pass around stateful information. This requires more discipline on the developer, but ultimately leads to more robust, less error-prone code that is easier to test. |
| | 198 | |
| | 199 | The counterargument to Django's approach is that passing the request around everywhere that it might be needed is difficult. Formsets are one example given in support of this - Django's formsets are a classic example where you might want to pass a request down to an internal form - but this is surprisingly difficult to do with Django's FormSet infrastructure. |
| | 200 | |
| | 201 | The problem isn't just about requests, either - there's a general problem in Django's FormSet and ModelFormSet objects that makes it difficult to pass in arguments to the Forms that are on them, or otherwise control the save process. This could be a request, the user that is making a particular change, or some other "ownership" related information. |
| | 202 | |
| | 203 | While it is *possible* to work around this problem, it *should* be a well documented, easy to use capability. |