...
There are several shared requirements for these various custom datatypes:
- An abstracted " handler " interface
- Validation
- Choices
- When applicable, the handler must provide a list of possible values.
- When applicable, the handler should be able to return a list of possible values, given a search (query) string.
- Return value with basic views (e.g., raw, uri)
- A UI extension of handler interface
- Rending of data
- User interface widget
- A string "reference" (may or may not contain the value) to be persisted by the API The API should provide a String reference and optional String display property for handler to persist the value
- For datatypes with large payloads (e.g., an image, video, document, etc.), the handler may provide a "key" to the value within an external data store.
- For simple datatypes, the handler may embed the value within the reference.
- The API should provide a String configuration property that the handler can use to manage configurations
- The handler should be able to expose configuration settings
- Initially this can be presented as a textarea to the user when setting the handler and the value will be passed to the handler when setting it up.
- Eventually, this can evolve into a map of properties or even into handlers being able to provide custom configuration pages.
Design Considerations
- For complex observations, we adopted a convention of displayable string + delimiter + reference key to ensure that a displayable version would be available even when values are retrieved in bulk and it's not feasible to call the handler to render every value. If we treat absence of the delimiter as displayable == reference key and include a mechanism to escape the delimiter, then this approach could be used across all custom datatypes.
- We'd like to maintain our separation of data & web layers, meaning that the handler interface may need to be separated into Handler and WebHandler interfaces (as Darius has done with visit attributes). In the future, the majority of OpenMRS instances may not be using the web application, so we should strive to maintain as much non-web-dependent functionality within the API layer as possible.
- To what extent can we use or learn from the earlier fieldGen work.
...