Resurrecting this one as I’m working on https://issues.openmrs.org/browse/HTML-788 to bring this long-needed support of using a form path with Obs elements on HTML Forms.
I ran into a bit an issue when handling form paths with obs groups. I believe we came up with the following approach:
However, trying to set this path results in a Core exception because the “^” is not allowed because it is the separator between the form namespace and the path.
Digging deeper, it does seem like the correct pattern should actually be:
would signify that ‘diastolic’ is in fact a first level obs group member inside the blood pressure encompassing group. My question would be to figure out if we need/want that, or if it is enough to just have unique field coordinates for a given piece of data? In which case this would suffice:
In other terms we would just defer to the implementer to figure out unique field paths, full stop.
If we want that then sure we need to find a mechanism to describe nested fields, such as more and more forward slashes that describe that we dive in a nested structure deeper and deeper. But I’m fearing this is overcomplicating things and will make the interpretation of the field path complex and sometimes ambiguous.
@mksd I started re-reading the thread to remind myself how things work. Isn’t Mark’s proposal essentially equivalent to what Bahmni already does, e.g. using parentFormFieldPath (if any) to define form id.
In terms of Mark’s examples, I think this looks something like this:
I was going to say in response to @mksd that maybe I was making things overly complicated and we don’t need nested support for now (it would make the coding easier, at least), but if Bahmni already supports nesting, I’d be inclined to support it (following the same format as Bahmni).
I’ve been including the nested work in HTML-788, so definitely fine to include it. Though, for what it’s worth, I had to put that ticket on hold for a bit but hope to get back to it in the coming few weeks.
Maybe out of context , this reminded me that some work needs to be done on WS/REST module to support those fields ie. formFieldNamespace and formFieldPath.
Such a payload would fail with an NPE, this is because the WS module tries to dynamically load getters and setters for those props using reflection yet support was added by an interface and not a pure POJO
I think the problem is quite a bit simpler than that: there are no setters for formFieldNamespace and formFieldPath, instead there is a setter for formField that takes both arguments. Interestingly, you’re pointing to the bug as arising from using an Obs where the same methods were added in 1.11, so apparently this bug has existed for a while?
We should definitely fix that. Is anyone aware of how we’ve handled similar cases (if any) previously?
We use the formfield path to store the path of the control in a form.
Note, Bahmni’s forms can have “add-more” (the same control can be used multiple times in a form) and the path stores the details. Also the path can store even the parent container details.
I think thats done only in case of a container control (section, table, obsgroup) - that can have multiple entries for the same concept/group. @binduak can you elaborate on this?