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
>
_________________________________________
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]
