Opened 18 years ago

Closed 17 years ago

Last modified 17 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

Description

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 by Gary Wilson <gary.wilson@…>, 17 years ago

Resolution: wontfix
Status: newclosed

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

comment:2 by Gary Wilson <gary.wilson@…>, 17 years ago

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 by Michael Radziej <mir@…>, 17 years ago

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

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

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.

comment:5 by Malcolm Tredinnick, 17 years ago

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 by Malcolm Tredinnick, 17 years ago

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 by Malcolm Tredinnick, 17 years ago

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 by hiutopor, 17 years ago

Cc: london added
Keywords: MESSAGE added

Hi all!

Very interesting information! Thanks!

G'night

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