Opened 14 years ago

Closed 12 years ago

Last modified 12 years ago

#1049 closed defect (fixed)

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

Reported by: wojtek@… Owned by: Adrian Holovaty
Component: Documentation Version:
Severity: normal Keywords: MESSAGE
Cc: london Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Custom manipulators don't have the flatten_data method which is used in generic views - should it be in the formfields.Manipulator object or how to define it (or is it not needed?)

Change History (8)

comment:1 Changed 12 years ago by Gary Wilson <gary.wilson@…>

Resolution: wontfix
Status: newclosed

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

comment:2 Changed 12 years ago by Gary Wilson <gary.wilson@…>

Resolution: wontfix
Status: closedreopened
Triage Stage: UnreviewedAccepted

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.

comment:3 Changed 12 years ago by Michael Radziej <mir@…>

Component: MetasystemDocumentation

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 =,
            hardware_id = obj.hardware_id,
            ip = obj.ip and obj.ip.ipaddr_display(),

comment:4 in reply to:  3 Changed 12 years ago by Gary Wilson <gary.wilson@…>

Replying to Michael Radziej <>:

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.

comment:5 Changed 12 years ago by Malcolm Tredinnick

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.

comment:6 Changed 12 years ago by Malcolm Tredinnick

Resolution: fixed
Status: reopenedclosed

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

comment:7 Changed 12 years ago by Malcolm Tredinnick

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.

comment:8 Changed 12 years ago by hiutopor

Cc: london added
Keywords: MESSAGE added

Hi all!

Very interesting information! Thanks!


Note: See TracTickets for help on using tickets.
Back to Top