The quickest solution would be to AOP around the sync save, check to see if its a personname, and update accordingly.
Ben On Wed, Aug 24, 2011 at 2:40 AM, Darius Jazayeri <[email protected]>wrote: > 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 > > > ------------------------------ > 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]
