I’m using ui-common module in my GSoC project and I noticed that we are using 1.9.4 version of datatable. A newer version of datatable is released which have more features. I think we should upgrade to newer version but we also have to do it such a way so that existing features don’t break.
I have also created an issue in jira (https://issues.openmrs.org/browse/UICM-76) . Please suggest how can we do it.
You could try to upgrade locally and then test to see if existing features break.
@dkayiwa, actually I’m already using newer version of datatable and using that I’m implementing a new feature. I was actually concerned about the other modules which are using ui-common module, some of their feature might break.
Do some random testing of the reference application’s features. If all is well, and no one has objected on this thread, go head and commit. We can always revert if we encounter problems.
Is the newer version of the datatable you plan to use meant to be backwards-compatible? I don’t recall 100%, but I have in my head that there was a major rewrite at one point?
I don’t think the newer version of datatable is backward-compatible, we have to take of this if we are going to update to newer version.
If it’s not meant to be backwards-compatible, I think we need to find a way to have both of this available in parallel then or this is a no-go…
Mark
@mogoodrich is right.
@shivtej, if you need the newer version of datatables, then just include it in the data integrity module’s OWA. There’s no specific need to add it to uicommons, if it’s going to break compatibility for existing modules.
sure. I will close the issue also.
@darius, @mogoodrich , you may want to look into this: https://datatables.net/upgrade/1.10 . Somehow I missed it.
I read this over quickly… it looks like generally 1.10 is backwards compatible with 1.9, with a few gotchas?
Generally I think we should be able to go ahead upgrade a minor version number, I’d just be more hesitant to upgrade a major version (ie a 2.x), especially if they specifically weren’t supporting backwards compatibility.
So, in summary, sounds like they are supporting backwards compatibility in 1.10 with a few caveats, so if you want I’d support trying to upgrade to 1.10, if you were willing to take care of some basic testing and letting people know on Talk.
Take care, Mark
@mogoodrich, I’m willing to work on it but I don’t have much experience with testing and other stuff related to it. If you or somebody can guide me through it, then I’m ready to take it.
The main thing to do would be to make sure you can start up an instance of the reference application, and then identify where datatables are used within the reference application (I’m not 100% sure myself, but I’d take a look at the coreapps module).
Then, update datatables in your local version of uicommons, and see if things start to break.
Take care, Mark
@dkayiwa, @mogoodrich . Submitted a PR here: https://github.com/openmrs/openmrs-module-uicommons/pull/37 . I tested the updated version on my local servers, it is working. In my knowledge, we are using it most of time for filtering only. While testing it turns out many modules are using their own datatable file, like openmrs-module-ows and openmrs-module-coreapps .
Of course, I have tested this PR with my limited knowledge about datatables and OpenMRS module, so I want you also test this out.
Thanks @shivtej for following this up. I have merged it earlier than latter such that we also get feedback from others who are using the snapshot version of the module.
Here’s some quick feedback… Dave, who is sitting next to me doing some testing, just noticed that tt seems to be breaking the main patient search (somewhat), at least in our implementation. 
Is there a Ref App staging server running the latest UI Commons?
Take care, Mark
fyi @ddesimone @cioan
@mogoodrich qa-refapp.openmrs.org is running the latest commit.
Cool, I can reproduce there, just commented on the ticket.