Page History

...

See the below interfaces; Processor modules can register handlers for specific content types during module startup (or whenever deemed appropriate by the module). The content handlers need to provide functionality to save and retrieve content. Interface handlers can simply then retrieve a registered instance based on the content type of the data they need to handle. There can only be a single handler registered for a specific content type. In the event that there are no handlers registered for a specific type, the module can use a handler registered for the application/* type, and will only throw an exception if this fall-back doesn't exist either. The module follows the prototype pattern for content handler instantiation. When registering a handler, a Processor module provides an instance of a handler. Then whenever the getContentHandler method is called, the Content Handler module will clone an instance of the handler for use by the caller.

In the event that there are no handlers registered for a specific type, the module will store the payload as an unstructured "blob" in the OpenMRS database. Blobs will be saved as observations linked to a single encounter for the specified patient (the Unstructured Storage module provides appropriate obs handlers). Any document-type data such as PDFs or image data can be stored this way.

Interfaces

public interface ContentHandlerService extends OpenMRSService {
 
	/** To be called by interface modules */
	ContentHandler getContentHandler(String contentType) throws NoHandlerForContentTypeException;
 
	/** To be called by processor modules on startup */
	void RegisterContentHandler(String contentType, ContentHandler prototype) throws AlreadyRegisteredException;
	/** To be called by processor modules on shutdown */
	void DeregisterContentHandler(String contentType);
}

...