Michael Radziej <[EMAIL PROTECTED]> writes:
> I've followed your discussion only in parts. But I usually handle
> everything that is outside of the scope of the normal generic views
> inside the manipulator, and I have patched some generic views so
> that they accept a manipulator instance as additional
> parameter. (see ticket 1563 for patch). I call the generic view from
> the view function.
I agree this change is useful, but it will not make my life much
easier.
The update_object view does, this:
new_data = request.POST.copy()
errors = manipulator.get_validation_errors(new_data)
manipulator.do_html2python(new_data)
if not errors:
object = manipulator.save(new_data)
The way I see it, new_data should be updated (with the values of
fields I want to preserve) before validation, so if I was to use your
patch I would have to overwrite get_validation_errors and update
new_data in there, before calling the "real" get_validation_errors,
right? Does not look too pretty to me.
> This makes a nice general pattern. You get very short view
> functions, the manipulator concentrates on the "real stuff", and the
> generic view handles all the GET/POST/validation logic, that tends
> to be the same for most views.
Still, with my change I can avoid writing views at all (other than
keeping my own version of update_object). At the same time the
functionality I need seems very generic. I'll try it and see what
happens :)
-mk
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
