The only class that uses "getForPatient" is the SmartDemographicsHandler. No id is needed because the data is actually off of the patient object.
The only other way this could work is if the getForPatient returns the most recent data. Eg. the most recent medications or the most recent allergies. However I see that actually as being a very small use-case. The better solution is to do the separation that Darius suggested so that patient-centric SMART objects could implement that just return their one piece of data. Ben On Thu, Aug 18, 2011 at 11:00 PM, Darius Jazayeri <[email protected]>wrote: > The point is that SmartProblemHandler should not implement getForPatient, > because that method is only meaningful for single-item-per-patient data > items. > > So, I think the right solution is to split into two interfaces (they can > have a common parent interface), e.g.: > interface SmartHandler { > // empty > } > > interface OnePerPatientSmartHandler<T> extends SmartHandler { > T getForPatient(patient/patientId) > } > > interface MultiplePerPatientSmartHandler<T> extends SmartHandler { > List<T> getAllForPatient(patient/patientId) > } > > -Darius > > > On Thu, Aug 18, 2011 at 12:35 PM, Wyclif Luyima <[email protected]>wrote: > >> Currently implementations of this method return null, and i guess the >> reason is because there is no way to uniquely look up a smart object being >> requested for and this is why i suggested adding an id argument, so >> that SmartDataService.getForPatient(Patient, Integer id) would return the >> object of the actual type defined by the implementing class that matches the >> specified id. e.g SmartProblemHandler.getForPatient(Patient, Integer id) >> would return a patient problem matching the passed in Id. >> >> Wyclif >> >> >> On Thu, Aug 18, 2011 at 3:10 PM, Darius Jazayeri <[email protected] >> > wrote: >> >>> Hi Wyclif, >>> >>> I'm not sure what that code looks like now, but IIRC the point is that >>> the getForPatient method gets an object that's unique (possibly aggregated) >>> for the patient. So the idea is that you'd say >>> DemographicService.getForPatient(patient) and it gives you back a single >>> SmartDemographics. >>> >>> (In the code review I proposed breaking up SmartDataService into two >>> different interfaces, one for the one-per-patient, and one for the >>> multipl-per-patient.) >>> >>> -Darius >>> >>> On Thu, Aug 18, 2011 at 11:20 AM, Wyclif Luyima <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> I think we need to add an extra argument >>>> to SmartDataService.getForPatient which will be the unique database id for >>>> the Smart object to fetch otherwise it seems useless for now. >>>> >>>> Wyclif >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
