Malcolm, thanks for taking the time to clarify the concept for me. I can see now that Django's approach is valid if one takes a form as a specification of what "has to be there" (hence the exclude mechanism in ModelForms) and not, as I did, of what "could be submitted". I still have a vague feeling that in the case of Django's conceptualization, *every* missing field should trigger a validation error (even if not required) but I'm not so keen (and, as of now, not competent enough) on elaborating this discussion further right now...
For my use case, where I want a separate form for every field showing up in the HTML purely for interface design / presentation layer reasons, my approach works fine for me although I would classify it as a hack now. But I do not want to generate individual forms in the controller in this case since it is really a matter of the presentation layer to do this splitting up and I also would need a mechanism to differentiate between the different types of forms in the backend once the request is received - which would require two pieces of code in the backend for a presentation layer issue. If I find some time to spend on this issue, I would rather look into creating a custom template tag (which I never did before) to extract individual fields of a model and render an AJAX-capable form to update them. I will let you all know if I ever find the time ;) All the best, Flo --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
