31 | | There is a lot more code to this, as FormWrapper and FormFieldWrapper and some other pieces have been rewritten. Here is the rub, though: |
| 31 | == Benefits == |
| 32 | The benefits of this system include: |
| 33 | * Custom form views become very simple, and intuitive. |
| 34 | * Validation aware models are harnessed in this system. |
| 35 | * Custom Manipulators could be defined in the model itself, which hightens the sense of everything in one place. Likewise, it can be seperated out if it's too much code in one spot. |
| 36 | * Defining Custom Manipulators allows one greater control of how the Admin deals with objects. Having a field automatically update with the author's User object would be a snap. Also, some options could move from the {{{class Admin:}}} into the Custom Manipulator, which would tighten things up a great deal. |
| 37 | * Making your own Admin app now becomes a lot easier. People often want to be able to simply plop a form down, and this gives them that ability. |
| 38 | * Because the form is raised, like an exception, it allows the writer to assume the data is correct the whole way through. But when there is a validation error, it is handled easily. |
| 39 | |
| 40 | == Compatibility == |
| 41 | There would be many changes needed in some other django code for all of this to work out right: |
| 42 | * The '''FormWrapper''' class would be destroyed, and would be supplanted by the easier '''Form'''. |
| 43 | * Form fields would be altered, both cosmetically "html2python" -> "to_python", and functionally for optimization / simplicity |
| 44 | * Models would have to gain the validation awareness that we've been talking about. |
| 45 | * The Model metaclass would need to create default Create and Edit manipulators if they weren't supplied (this would be very easily done). |
| 46 | |
| 47 | == Code == |
| 48 | There is a lot more code to this, as FormWrapper and FormFieldWrapper and some other pieces have been rewritten. Here is the most of it, though: |
315 | | |
316 | | == Benefits == |
317 | | The benefits of this system include: |
318 | | * Custom form views become very simple, and intuitive. |
319 | | * Validation aware models are harnessed in this system. |
320 | | * Custom Manipulators could be defined in the model itself, which hightens the sense of everything in one place. Likewise, it can be seperated out if it's too much code in one spot. |
321 | | * Defining Custom Manipulators allows one greater control of how the Admin deals with objects. Having a field automatically update with the author's User object would be a snap. Also, some options could move from the {{{class Admin:}}} into the Custom Manipulator, which would tighten things up a great deal. |
322 | | * Making your own Admin app now becomes a lot easier. People often want to be able to simply plop a form down, and this gives them that ability. |
323 | | * Because the form is raised, like an exception, it allows the writer to assume the data is correct the whole way through. But when there is a validation error, it is handled easily. |
324 | | |
325 | | == Compatibility == |
326 | | There would be many changes needed in some other django code for all of this to work out right: |
327 | | * The '''FormWrapper''' class would be destroyed, and would be supplanted by the easier '''Form'''. |
328 | | * Form fields would be altered, both cosmetically "html2python" -> "to_python", and functionally for optimization / simplicity |
329 | | * Models would have to gain the validation awareness that we've been talking about. |
330 | | * The Model metaclass would need to create default Create and Edit manipulators if they weren't supplied (this would be very easily done). |