I’d like to use the patient object in a fragment controller.
But I’ve seen many different ways to do throughout the code and still don’t know which one is the good one.
Sometimes I’ve seen the @RequestParameter annotation (or even the @FragementParam annotation) to retrieve the Patient from the URL parameter ‘patientId’ (or ‘patient’ in more recent pieces of code).
Somewhere else, I’ve seen the @InjectBeans annotation to inject the PatientDomainWrapper
And (the one I like best) I’ve seen the config.getAttribute(“patient”) to retrieve the Patient or PatientDomainWrapper when the inclusion of the fragment provides the ‘config’ object.
Q: What’s the good way to do ?
Q: And should we use Patient or PatientDomainWrapper ?
I’ve seen pieces of code that even check the class of object ‘patient’ (instance of Patient or PatientDomainWrapper) and act accordingly. Is there any general guidance here ?
I understand that this is something that tends to disappear anyway (with the use of AngularJS with REST APIs), but the app is still largely using GSP/Java Controller pair, so I’d like to know the good way to do.
Originally we were using Patient, but realized that it was helpful to have
PatientDomainWrapper to have a common place to do higher-level things than
the raw data model (e.g. primary identifier vs extra identifiers). So, you
should prefer PatientDomainWrapper (although the mechanism for constructing
this is a bit unwieldy).
a page controller should use @RequestParam and then put a
PatientDomainWrapper in the PageModel
a fragment controller that expects to be be used on a patient page for a
single patient (i.e. most patient-focused fragments) can just fetch the PDW
from the page model
if it wants to be safe for compatibility with older code, it could
construct a PWD based on a patient if necessary)
a fragment controller that wants to be usable on pages that aren’t just
for a single patient should get a PDW from the FragmentConfig (and the
patient needs to be passed in as part of the ui.includeFragment call).
for example we were thinking that there might eventually be a screen
that shows the patient header for multiple patients, so I think that
fragment is probably written in this way
A fragment shouldn’t be looking directly at a @RequestParam(“patient”) in
its controller method (though it might in a fragment action method).
Since the goal/vision of the API is to be more than a raw data model, it would be nice to look for ways for things like this (wrappers in the application or changes made in the web service layer) to inform evolution of the API to make them less necessary over time.