...
- 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.
Rendering Values
Part of the job of the handler is to handle rendering. The intent was that an application (OpenMRS, module, etc.) would call the API asking for the value rendered for a specific "view" (where the view could things like raw, thumbnail, link, html, json, etc.). View names would be somewhat standardized (e.g., some provided by core like raw, thumbnail, link, html but others invented by modules like flash, foobar, ...) and handlers would be able to report which views they supported. So, the API sends the view and value reference to the handler and the handler takes care of rendering the result and returning it. This model allows the API to support views without having to bind itself to web-based views and leaves the rendering to the handler.
For web support of rendering, it would be nice to have a web-aware extension of handlers – e.g., a method for providing supporting JavaScript (i.e., if a handler is being used it could inject some javascript on the page once even if there are 30 of its thumbnails being rendered on the page).