I learned, forgot about, and got bit again today by an issue that makes me think I don't understand the desired behavior for Manipulators.

I was subclassing AddManipulator to do a more complex function across several objects, and ran into a few fields that wouldn't set themselves, even though I'd post-populated that data into place. In the end, I realized that it was because I had them set to "editable=False" so they wouldn't be editable in the Admin interface, and that directly matched the behaviour I was seeing from the AddManipulator. These all also had default values - but even those didn't get set through the subclassed Manipulator.

The particular object has only two fields the user puts in, but several that are calculated based on the user's current context (ip address, current variables associated with the user object, etc) and shoved into place.

Is the "right" way to create the object manually, using the custom manipulator simply to get the benefits of the form validation? Or was I just not getting the right sequence of "what I should do in subclassing an AddManipulator"?

Any one have some suggestions on the "correct" way to go? I've been trying very hard to match Django convention, but I'm afraid I'm just missing the boat on this one.

I saw in a different thread that Manipulators were heading out the door to be handled differently and more cleanly.

-joe

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to