#1049 closed defect (fixed)
custom manipulators don't work with generic views due to lack of flatten_data
Reported by: | 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 , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 18 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Triage Stage: | Unreviewed → 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.
follow-up: 4 comment:3 by , 18 years ago
Component: | Metasystem → 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 by , 18 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 , 18 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 , 18 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:7 by , 18 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 , 17 years ago
Cc: | added |
---|---|
Keywords: | MESSAGE added |
Hi all!
Very interesting information! Thanks!
G'night
newforms obsoletes manipulators, so this is probably not going to be worth fixing.