Address Hierarchy: Support for i18n?

address-hierarchy
Tags: #<Tag:0x00007f23d47ed2c8>

(Mike Seaton) #26

@mksd, great - glad it is working for you. For me, just having you try to use this and validate it for your use case gives me enough confidence to merge it in, since it is pretty self-contained from what I recall. If it doesn’t work, that only affects new users of this feature, not existing users, so assuming there are not design disagreements, feel free to push this ahead. Thanks!

Mike


(Stephen Senkomago Musoke) #27

@mseaton @mksd How do I ensure that my address hierarchy is not reloaded at each restart. Your comments seem to indicate that is possible but I do not see how.


(Dimitri R) #28

You can set the addresshierarchy.initializeAddressHierarchyCacheOnStartup global property to false to prevent caching at startup.

But it depends what you mean by “loading”?


(Dimitri R) #29

Hi @mseaton,

So I made some changes, added unit tests, was ready to go… and of course I got errors at runtime. Hopefully only this one blocker:

java.lang.NoClassDefFoundError: org/openmrs/layout/web/address/AddressTemplate

This happens I believe because in Core 2.x this class was moved to org/openmrs/layout/address, hence the definition of the class is indeed not being found at runtime against Core 2.x.

I would like your opinion on this: is there a simple workaround that does not involve introducing compatibility classes?


(Stephen Senkomago Musoke) #30

@mksd The address cache is setup at runtime, however my address entries are always loaded from the csv file at startup which adds about a minute each time. The loading from the csv into the database is what I am referring to


(Dimitri R) #31

That is really strange, did you see this thread: ‘Preloading address template and address hierarchy’?

The behavior that you describe is not implemented yet as part of Address Hierarchy, so if there is an automatic loading of the entries CSV file, it must be performed by another module.


(Dimitri R) #32

… unless you were trying out the configuration branch of course, is that what you meant?


(Mike Seaton) #33

@mksd, is the runtime issue you were hitting with AddressTemplate still an issue? I thought I saw some classes in your latest pull request for @dkayiwa that dealt with this. Happy to talk through it if helpful - find me on IRC.

Mike


(Dimitri R) #34

Yes, still an issue. So I did go for a compatibility class (AddressTemplateCompatibility), but now we are hitting a Spring bean problem at runtime.

@dkayiwa is still looking into it.

P.S. I just created ADDR-109 btw.


(Mike Seaton) #35

@mksd, from quickly re-looking at the code, the main purpose is to be able to install the AddressTemplate configuration that the system requires. This is stored as a global property (not sure if it still is in 2.0, but assuming it is), as a serialized string. So, it’s not technically necessary to use the AddressTemplate class from core at all, as long as you can construct the serialized xml that core can read back in.

So, if you are referring to a compatibility class as one that you introduce to be able to hold the address template data, and that will serialize down to the appropriate format in either pre-2.0 and post-2.0, then this is probably the best course of action.

Mike


(Dimitri R) #36

Yes sure. At first I thought it would be better to just stick to your code that leverages Xstream since everything was in place. Of course now after the fact, I’m left thinking that generating the XML string was a better deal. If there is not an obvious solution to the Spring error happening at runtime I will have to go down that route.


(Dimitri R) #37

I used reflection as suggested @dkayiwa using just this. In that very instance about AddressTemplate, reflection has provided to be a far better solution than dealing with compatibility classes.

Unless we hit yet another unexpected issue at runtime, this is good to go.


(Dimitri R) #38

@mogoodrich and @mseaton,
I could finally go ahead with my (fairly big) PR, now that a first release 1.0.0 of Ext I18N is out. See PR #20.

Happy to demonstrate the results through a design forum (cc @burke @darius @dkayiwa ).


(Daniel Kayiwa) #39

Copying in @jthomas :slight_smile:


(Mark Goodrich) #40

Thanks @mksd, we will take a look!


(Jamie Thomas) #41

Hi @mksd. Always happy to assist with the logistics of design forums. To schedule a design forum please post to the Talk post below to propose your design topics so we can get more information on your topic. This gives us more background on your topic to help get it on the schedule and it gives more visibility for other community members who may have interest in the same topic.

As of right now we have some openings over the next few weeks. Please post your request to the Talk post below and let us know if you would prefer a certain day.


(Dimitri R) #42

Thanks @jthomas, will do!


(Dimitri R) #43

Thanks @mogoodrich for merging this in. Amazing that I18N support will be part of AH 2.11! FYI we will probably be willing to release 2.11 soon then.


(Mark Goodrich) #44

Sure, we can release whenever!

I just updated our build to use the latest snapshot, so I can do some manual testing of the searching on our staging servers to make sure things are still working… will let you know if anything goes wrong…

Take care, Mark


(Dimitri R) #45

Ah great, thanks so much Mark. Yes please of course let me know if you find any issue and I’ll get back to it asap.