I agree that this seems like something that's more appropriate to calculate
on the child after importing a name.
The problem is that we do our post-service-call actions using AOP rather
than having a proper event-notification mechanism. (Dave, I assume that
namephonetics does AOP-after savePerson, savePersonName, etc.)
Ideally sync would be able to call a core method like this:
save(importedObject); // uses something internal to sync.
publishEvent(importedObject, "saved");
Another solution (also requiring core changes) would be if there was a
generic save method would would delegate to the appropriate service method.
So that sync doesn't have to do its own hibernateSession.save(object) which
bypasses the service layer.
I know that Rafal implemented something like this in the Metadata Sharing
Module--it actually scans everything that implements OpenmrsService on the
classpath, and finds save(OpenmrsObject) methods.
-Darius
On Mon, Aug 22, 2011 at 12:41 AM, Ben Wolfe <[email protected]> wrote:
> Am I remembering right that NamePhonetics has a table listing out the
> manipulations of the names? That it doesn't do that calculation on the
> fly? It does sound a lot like conceptword in that you don't need to send
> those back an forth, instead have them re-calculated on the receiving
> server.
>
> We do have the @Handler annotation in trunk. But its usually used as an
> @Handler(supports=NamePhonetics.class) PLUS extended a special class. This
> class would have to be in the sync module. Its possible that you extend a
> class from sync and then use the aware_of_module tag in config.xml. This is
> a loose module requirement that Daniel did
> https://tickets.openmrs.org/browse/TRUNK-1587 (but its 1.9+ :-/)
>
> The generic Handler class you're proposing would just have a handle(T)
> method? What happens when there are two or more classes defined as:
> @Handler(supports=NamePhonetics.class)
> public class NamePhoneticsHandler extends Handler
> ?
>
> How is sync supposed to know which one to use? Or which one is for sync
> and which one is for some other handler?
>
> Answering my own question after pondering for a few minutes:
> add another method called "whoAmIIntendedToBeUsedBy()" that returns a
> String key that the sync module can use to distinguish different handler
> classes. (Obviously the name of the method needs some work...)
>
> Ben
>
>
> On Sat, Aug 20, 2011 at 12:10 PM, Dave Thomas <[email protected]> wrote:
>
>> Hi. At PIH, we have a few implementations using both sync and
>> namephonetics. Right now, namephonetics objects aren't propagating
>> through sync which is something we want to fix.
>>
>> Option 1 is to have NamePhonetics extend OpenmrsObject, and let sync
>> propogate these. The downsides are 1) extra stuff in the payloads,
>> and 2) I have a feeling there would need to be explicit handling of
>> NamePhonetics objects during ingest, because PersonName objects are
>> explicitly marked as getting processed last (because of the famous
>> TreeSet re-ordering bug). This, i think, would mean that there would
>> have to be a new category of 'things to process last' in the ingest
>> routine, which in sync we could maybe define safely as anything
>> associated with a module (org.openmrs.module*)? Not sure about this
>> though. It is definitely true that we don't want to build any module
>> dependencies between Sync and NamePhonetics.
>>
>> Option 2 is to treat NamePhonetics like ConceptWords in that they're
>> calculated locally. NamePhonetics currently AOPs around savePerson to
>> do this on a local system, but the saving of PersonNames during sync
>> ingest uses the SyncService.saveOrUpdate method. Here's what I was
>> thinking -- what if SyncService had a postInterceptor modeled on
>> RequiredDataAdvice? This postInterceptor class would check for
>> registered handlers for incoming sync items. The only architectural
>> piece that would be needed to do this and avoid building in module
>> dependencies between Sync and NamePhonetics would be a truly default
>> Handler interface in OpenMRS core. NamePhonetics would then register
>> a PersonName handler. Sync ingest would then look for a handler in
>> the saveOrUpdate postProcessor, and if found, apply it. If not found
>> (for sync implementations not using namephonetics), no problem.
>>
>> Option 2 seems like overkill, maybe, although i like the idea of
>> keeping sync packages as simple and small as possible... thoughts on
>> this would be appreciated.
>>
>> Also, generally, would it be useful to have a truly generic handler
>> interface in core (or actually, maybe generic pre-processor and
>> post-processor handler interfaces)? This would be kind of a cool way
>> for modules to register handlers against each other, without building
>> in module dependencies.
>>
>> d
>>
>> _________________________________________
>>
>> 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]
>>
>
> ------------------------------
> 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]
