make ItemModelBase._storeData easier to override

Bug #697719 reported by Forrest Aldridge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Methanal
New
Undecided
Unassigned

Bug Description

Even though ItemModelBase._storeData is designate a private method (perhaps something that change), in my experience in often needs to be overridden instead of its related method, ItemModelBase.storeData in order to maintain the correct SQL transaction behavior.

Overriding this method is unnecessarily quirky, however, because ItemModelBase.storeData passes its data as an actual Python dictionary as opposed to unpacked keyword arguments a la standard Python convention.

It is very helpful in the common (at least for me) case of slightly tweaking the behavior of ItemModelBase._storeData to be able to "peel off" some of the keyword arguments passed in from the form invocation and manipulate them as needed before issuing a cooperative super() call on _storeData.

Related branches

Revision history for this message
Forrest Aldridge (forrest-aldridge) wrote :
Revision history for this message
Forrest Aldridge (forrest-aldridge) wrote :

wow, sorry for all the typos. Should have read back over that. ;-P

Revision history for this message
Tristan Seligmann (mithrandi) wrote :

Based on what Jonathan and I were able to reconstruct from memory about the IRC discussion around this issue, the actual use case here is a form that has multiple inputs, which map to a single Item attribute, a reference to another Item which has the values of those inputs set on it. Unfortunately the original bug description doesn't cover this at all; I've often found it very useful to be more specific about the concrete use case that motivates a more general change, even if the benefits are "obvious".

Anyhow, I think this is the wrong way of going about things. A single item attribute should be associated with a single model parameter, which in turn should be associated with a single form input. In this particular case, there is already a (very poorly named) form input that does something like this: GroupInput. I'm not even sure if it still works, and if we're going to "resurrect" it now that somebody has a use case for it (the original code in Fusion has since been removed), perhaps it should be rewritten, but essentially what GroupInput is is a form wrapped up into an input; when the "parent" form is submitted, the "child" form is also submitted, and the result of submitting the "child" form becomes the value of the GroupInput in the "parent" form.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.