Well i found a solution finally... http://kfarr.com/2008/04/04/making-a-complex-customized-django-form-template-remember-to-include-errorsnon_field_errors/
If anyone else has this kind of problem.... then you could go ahead and check this example too : http://opensource.washingtontimes.com/blog/post/jsoares/2009/01/im-lazier-then-django-forms/ Alan. On Jun 10, 10:31 pm, zayatzz <alan.kesselm...@gmail.com> wrote: > Nice... it worked... > > If i use form.as_p it gives me output of all form errors before the > form, just as i want, but form as paragraph does not look very nice > and i rather use my own template for it which looks like this: > > {% for field in form %} > <tr><td class="label">{{ field.label_tag > }}</td><td class="field"> > {{ field }}</td></tr> > {% endfor %} > > But which tag is the one that gives me this nice list of errors in > case of form.as_p ? > > {{ form.errors }} > > gives me output like : > <ul class="errorlist"> > <li> > __all__ > <ul class="errorlist"> > <li>Password has to be longer than 6 characters</li> > </ul> > </li> > </ul> > <ul> </ul> > > and that just sucks.. 2 errorlist uls and one empty ul? and whats up > with that __all__ ? > > do i have to iterate through that form.errors? how then because > > {% for error in form.errors %} > {{ error }} > {% endfor %} > > Gives me just this : > __all__ > <ul> </ul> > > Alan. > > On Jun 9, 3:00 pm, zayatzz <alan.kesselm...@gmail.com> wrote: > > > Aha! > > > I will try that when i get back home. > > > Thanks! > > > Alan > > > On Jun 9, 2:50 pm, Karen Tracey <kmtra...@gmail.com> wrote: > > > > On Tue, Jun 9, 2009 at 2:19 AM, zayatzz <alan.kesselm...@gmail.com> wrote: > > > > > Well thats what i was complaining about in the beginning that i could > > > > use good example of how to do it. Its quite confusing how form > > > > validation is on one page, errors on the others and views on third and > > > > there is not single full example. > > > > > How should the else part be? > > > > > else: > > > > message = "form was not valid" > > > > accform = form > > > > ... > > > > return render_to_response...... > > > > > something like that perhaps? > > > > No, you don't want to be creating another form instance in the case where > > > the existing one is not valid. The existing instance that failed > > > validation > > > is already annotated with specific errors describing what's wrong with it. > > > Really, this example, mentioned earlier, is complete: > > > >http://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-... > > > > There doesn't need to be an else block for the is_valid(). The case where > > > there are errors in the POSTed data which make the form invalid is > > > described > > > by the 3rd numbered note below the example. All that has to happen for > > > that > > > case is that you pass the existing bound (and invalid, therefore > > > containing > > > errors that will display with the form) back in the context for display. > > > The form gets re-displayed with error annotations and is ready for > > > correction/re-submission by the user. > > > > Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
