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