custom manipulators don't work with generic views due to lack of flatten_data

newforms obsoletes manipulators, so this is probably not going to be worth fixing.

Actually, I'm going to re-open this in case someone would like to fix it since I believe it is a bug. It can be closed once newforms is actually getting used for the generic views. It seems possible that a flatten_data() could be added to the Manipulator class, but it could not just be the version from the AutomaticManipulator class since that accesses attributes only available for AutomaticManipulator instances. Perhaps it just needs to call flatten_data on each field.

If you would like to see this, then please submit a patch and tests.

I have added this as a Manipulator ticket to track on the FeatureGrouping page.

I don't see the issue. You simply define your flatten_data method for your custom manipulator. Perhaps this should be documented (but it's a bit late). Here's a simple example:

    def flatten_data(self):
        obj = self.original_object
        return dict(
            name = obj.name,
            hardware_id = obj.hardware_id,
            ip = obj.ip and obj.ip.ipaddr_display(),
            ...
            )

Replying to Michael Radziej <mir@noris.de>:

You simply define your flatten_data method for your custom manipulator.

Yes, you could do that too, but it could also be done more generally. Something like calling field.flatten_data() for each field in the manipulator maybe.

We should not be adding any more code to manipulators at this point in time. I will commit a docs patch describing how to do write a flatten_data function as Michael describes.

(In [4711]) Fixed #1049 -- Documented the need to implement flatten_data() in some cases for custom ChangeManipulator? replacements. Thanks, Michael Radziej.

Aah .. only after the fact do I realise that Gary's comment #4 could be interpreted not as a code change but an alternative, also valid, approach to the problem.

Not to worry too much, since this is advanced and not overly common usage (if you're using custom manipulators in conjunction with generic views, you presumably have enough programming experience to realise there are alternatives) for a feature with limited life expectancy. What we've got now should work.

Hi all! Very interesting information! Thanks! G'night