instance destination doesn't do anything

[getodk-bot]

Issue by mitchellsundt
Thursday Jul 09, 2015 at 18:08 GMT
Originally opened as getodk/getodk#288 (1 comment(s))

---

Originally reported on Google Code with ID 287

instance destination seems to bind to the prompt of whatever thing you type there. if
that thing doesn't exist, it doesn't create it. this usually results in a broken form.

more broadly, it'd be great to understand what it's supposed to do.

Reported by yanokwa on 2011-08-03 22:26:52

[getodk-bot]

Comment by mitchellsundt
Thursday Jul 09, 2015 at 18:08 GMT

---

Reported by yanokwa on 2012-05-25 20:10:52

[issa-tseng]

Yeah, instance destination should probably create the requested custom destination node in the instance tag rather than the default. Someone looking to fix this would do well to search for instance.children.push within public/javascripts/data.js.

[issa-tseng]

My test case file

[yanokwa]

I know I filled this issue, but I have no idea what someone would use instance destination for. I think this might have been used as a hack to rename the data name? Any ideas why we had this in the first place, @clint-tseng?

[issa-tseng]

shrug. Seemed like elementary XForms functionality, so this feature has existed, albeit somewhat broken, since the very first imagining of this application. If you'd rather just strip it out, I can take a look at existing forms to see if we can safely deprecate.

[yanokwa]

I legit can't think of why we had it as a thing in the first place. Summoning @MartijnR in case he knows.

Either way, I agree that a good next step is to see how existing forms use it.

[MartijnR]

I don't know what it is either. A form control without a corresponding primary instance node would crash a form in Enketo.

[issa-tseng]

@MartijnR I think the question is whether there is a strong case for being able to customize the exact instance destination node path; eg you want to build your own XML structure, vs rely on the automagic one we infer.

[yanokwa]

I can't think of a strong case for being able to customize the exact instance destination node. Or rather, in my many years of form design, it has never crossed my mind to want that feature and I haven't seen someone ask for it on the mailing list. For those reasons, I'm voting for a deprecation, but I think it'd be prudent to wait for the review of the existing forms.

[MartijnR]

Oooh. Totally misunderstood the feature. Sorry about that. I haven't really come across this need either.

…

On Sun, May 21, 2017 at 7:30 PM, Yaw Anokwa ***@***.***> wrote: I can't think of a strong case for being able to customize the exact instance destination node. Or rather, in my many years of form design, it has never crossed my mind to want that feature and I haven't seen someone ask for it on the mailing list. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmSloeRrFUCylzd_FwVslNV9ozwkQ9Zks5r8OUngaJpZM4LXCUB> .

-- -- *Revolutionizing data collection since 2012.* Enketo <https://enketo.org/> | LinkedIn <http://www.linkedin.com/company/enketo-llc> | GitHub <https://github.com/enketo> | Twitter <https://twitter.com/enketo> | Blog <http://blog.enketo.org/>

[issa-tseng]

Okay. For now, I will remove this feature from the 0.3.1 release slate, and we'll look at deprecation possibilities instead for a future release.

[issa-tseng]

Putting this in the 0.3.3 milestone to investigate whether anyone is using this feature and make a final decision on merging the fix or cutting the feature entirely.

[issa-tseng]

I performed a review of this feature's usage. Only ~0.4% of forms attempt to use instance destination, and of those that do the vast majority don't know what they're doing with it. There are a lot of filesystem paths, URLs, and email addresses, along with relevance/calculation expressions, names with spaces, repeated values that would overwrite the same path repeatedly, and other sundry.

Having reviewed every instance of this feature's use, it seems deprecation would disappoint roughly 3 people, who were probably already disappointed when their careful use of the feature failed to work without PR #139.

Deprecating.

[issa-tseng]

Resolved by deletion (#167).