I’m currently working on https://issues.openmrs.org/browse/MF-286 and have handled most of the configurations but for these two sizeMappings and elementRegexFormats. From the doc, it’s not clear if number of characters in size mapping is supposed to specify the size of the input field with something like
<input type="text" size={sizeMapping}/>
Or its just meant for validation in case someone tries to save a value longer than what’s specified in the sizeMapping configuration?
What does elementRegexFormats do? It’s not very clear from the doc and is there anyone currently using this configuration?. There is already an elementRegex which is self explanatory.
@ivange94 this means that both attributes describe backend-driven validations:
A RegEx pattern
A max length
Both will have to be handled by the micro frontend.
We need to be careful that, when an address hierarchy is enabled, those validations only apply to manually entered address fields, and not to the values provided by the address hierarchy.
@dkayiwa the sizeMappings is now handled. Now I’m a little confused as to how to treat the regex configurations. More specifically this elementRegex. Parsing the configuration itself is easy. I’m actually worried about the user experience here. The elementRegex doesn’t provide a message to display should an input not match the regex pattern. And when an input fails validation we need to show a helpful message with hints as to what they might be doing wrong. Regex may only be useful to developers so on validation failure we can’t just display the regex pattern to users. I thought of using elementRegexFormats to show as a message when a field fails the regex validation but in the docs its not stated that an elementRegexFormats must be provided whenever elementRegex is provided. So what happens if an input fails the regex pattern and no elementRegexFormats is provided. And also, elementRegexFormats only provides suggestions for valid values. It might not be as helpful as an actual message that says how the value should look like.
Would be better if the elementRegex looked like
<elementRegex class="properties">
<property name="address1" value="^[A-Z]+$" message="can only contain letters"/>
</elementRegex>
This way, if the input for address1 doesn’t match the pattern, I can easily show the message
`${name} can only contain letters`
Any suggestion on how to approach this? How does this work in the refapp UI?
That’s a great point @ivange94, and perhaps we will face the same exact challenge in other places where RegEx are involved as part of a validation configuration.
@ivange94 does it break anything to just add the new "message" attribute? I guess it will but who knows… I remember that the address template is unmarshalled here and there and I guess that this process might throw errors when there’s new unexpected stuff in the marshalled representation of the address template.
It doesn’t. So I tested and validation only works with top level children like the ones mentioend in the doc. If you had a new element under org.openmrs.layout.web.address.AddressTemplate that is not one of the expected child elements, it’s going to fail. But it seems thats as far as the validation goes. That is you can add a fictitious child to an element like nameMappings and it’s going to be accepted. Attributes are also not validated which means you can pass in formatMessage or message as an attribute even though it’s not part of the spec and it won’t fail. @dkayiwa is this by design?
There is no rule in the doc that says that when elementRegex is provided, a corresponding elementRegexFormat will be provided so we cannot rely on that. Plus elementRegexFormat will not return a very useful message as it only returns values.
Sure you can. But what happens when an implementation provides an elementRegex but doesn’t provide an elementRegexFormat. The backend allows this. So in this case I’ll end up with regex for validation but no useful message to display to the user.
@dkayiwa, it seems that this conflicts with the elementRegex. I mean a regular expression is capable or limiting the number of characters allowed. I am surprised that we would have a specific string size element, while the regex is here for that.
I rather suspect that this was initially designed to inform the UI of the length of a input text, basically saying for example: “postal code input box should be a smaller box than address1”.
And in fact I can confirm there is no back-end validation based on that sizeMappings value
