#6138: newforms: when accessing directly form.errors, error_class is not used
-----------------------------------+----------------------------------------
          Reporter:  Michal Moroz  |         Owner:  peter2108
            Status:  new           |     Milestone:           
         Component:  Forms         |       Version:  SVN      
        Resolution:                |      Keywords:           
             Stage:  Accepted      |     Has_patch:  1        
        Needs_docs:  0             |   Needs_tests:  0        
Needs_better_patch:  0             |  
-----------------------------------+----------------------------------------
Changes (by peter2108):

  * owner:  nobody => peter2108
  * needs_better_patch:  1 => 0
  * status:  reopened => new
  * needs_tests:  1 => 0

Comment:

 Forms have an optional parameter 'error_class' which defaults to
 !ErrorList.
 !ErrorList subclasses 'list'. It holds a list of Form errors and has
 methods to
 present its errors in various formats, typically an HTML <ul>. A custom
 error_class might change the HTML display of Form errors. Forms add errors
 by trapping a !ValidationError

 !ValidationError.messages is an !ErrorList instance. Present code just
 adds
 this !ErrorList to the Form's errors. Instead we initialise an error_class
 instance with !ErrorList.messages and add this instance to Form's errors.

 error_class is an optional parameter for !BaseForm, !BaseFormset and
 !BaseModelForm.
 Changes are only needed for the first two.

 !ValidationError is trapped at:
 {{{
 1. forms/fields.py:805
 2. forms/forms.py:245
 3. forms/forms.py:252
 4. forms/formsets.py:254
 }}}

 Changes are made for 2-4. Any issues there might be with 1. are not
 addressed.

 I have included a group of tests. To run these using the constant
 'NON_FIELD_ERRORS' instead of its present value I needed to change the _
 _all_ _
 list of Forms module.

 The changes proposed here are those of !AzMoo 12/14/08 except for the
 change to
 _html_output which does not appear to be necessary.

 Finally if documentation is added for 'error_class' it would probably be
 worth
 warning error_messages for fields are not strings. I included some tests
 to illustrate this

 The changes are in error_class2.diff, test for the patch in
 error_class2_test.py

-- 
Ticket URL: <http://code.djangoproject.com/ticket/6138#comment:16>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to