Code

Opened 8 years ago

Closed 7 years ago

Last modified 7 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
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: UI/UX:

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?)

Attachments (0)

Change History (8)

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

  • Resolution set to wontfix
  • Status changed from new to closed

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

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

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Unreviewed to Accepted

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 follow-up: Changed 7 years ago by Michael Radziej <mir@…>

  • Component changed from Metasystem to Documentation

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(),
            ...
            )

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

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 Changed 7 years ago by mtredinnick

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 7 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:7 Changed 7 years ago by mtredinnick

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

  • Cc london added
  • Keywords MESSAGE added

Hi all!

Very interesting information! Thanks!

G'night

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.