Aja, what objects in the smart api will return BOTH one and and a list depending on how its requested? So far everything that is implemented is either one or the other. (And the only one returning just one is the demographics object)
Ben On Fri, Aug 19, 2011 at 4:09 AM, bala ajanthan <[email protected]>wrote: > Hi, > I did not split the interface SmartDataHandler into two as said in code > review.Because i thought the current SmartDataService does not allow to > select particular SmartObject based on the some id[0].My idea is to > implement services for each Smart data and expose it as separate services > through Context.getService(class).So the SmartDataHandler interface should > have two methods, > > One for mapping a SmartData > SmartData getSingle(BaseOpenmrsData single); > One for mapping list of Smartdata > List<SmartData> getAll(List<BaseOpenmrsData> list) > > Each services can use above two methods to get single data or multiple data > based on the supplied arguments. > Thank you. > [0] > http://wiki.chip.org/smart-project/index.php/Developers_Documentation:_REST_API > > > On Fri, Aug 19, 2011 at 2:42 AM, Ben Wolfe <[email protected]> wrote: > >> 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 >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > > > -- > Balachandiran Ajanthan > Phone:+94775581497 > Blog : http://ajanthan87.blogspot.com > Twitter: ajanthan87 > skype :bala.ajanthan > gtalk :balaajanthan > ------------------------------ > 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]
