Code

Changes between Version 5 and Version 6 of NewManipulators


Ignore:
Timestamp:
08/21/06 15:38:54 (8 years ago)
Author:
brantley
Comment:

cosmetic

Legend:

Unmodified
Added
Removed
Modified
  • NewManipulators

    v5 v6  
    2929As you can see, our form is now more of an exception.  And our manipulation process is very simple, most of it takes place in {{{process()}}}, and if at any point a form is raised, it is presented.  Otherwise the manipulator calls and returns {{{save()}}}.  In this case it creates and returns a new poll object. It will also raise a form if the model validation returns an error.  If no form is raised, we are done and return our Response. 
    3030 
    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 == 
     32The 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 == 
     41There 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 == 
     48There 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: 
    3249 
    3350{{{ 
     
    313330 
    314331}}} 
    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).