OpenEMR GUI - Sencha's ExtJS Framework

OpenEMR Development
1

hrivera787 wrote on Thursday, August 26, 2010:

Hi everyone;

For a couple of weeks I have been working on the Sencha’s ExtJS GUI Framework integration on OpenEMR, so far so good. Because the integration and changes are too radical to keep with the original code. I had decided to add a extra letters to the files that I had touched for example, if the original filename is “main_screen.php”, the new filename with the ExtJS code  is “main_screen.ejs.php”, this to maintain the original code and work with the integration without problems and confusions.

Later on, I will post a link to a video so you can appraise the benefits of this integration. The code will be arranged as follows:
- The PHP code will be on the top, in other words on the firsts lines of the file. (LOGIC)
- The ExtJS code will be on the bottom, in other words the GUI itself. (GUI)
- AJAX, ExtJS will handle the AJAX requests, no need of jQuery.

Why the radical change?
The original application uses frames to handle different windows and screens in ExtJS, frames can be handled, but are not convenient, this because when a dialog is called it remains inside the frame, and not on top of the entire application. Meaning, if I need to call a dialog on a MODAL basis, it will only be modal on the frame.

Where you can get it, to try it out?
Right now the code, is hosted on GitHub, as a forked repo of the original branch. Is not yet fully functional. I will keep you posted for future releases.

2

bradymiller wrote on Thursday, August 26, 2010:

hey,

Glad to hear your still plugging away at this. Note that using new files names makes it much harder for us to clearly see your modifications (although if this breaks current code, I suppose can’t help it), becausewe can’t quickly see the diff of all your changes. Have you been able to get internationalization to work with your code?

-brady

3

hrivera787 wrote on Thursday, August 26, 2010:

As you said, “can’t help it”. The changes are too radical to do a DIFF.
if you run a DIFF over the (ejs.php) files, it will say the complete file has changed.

In other words, I’m re-writing almost all the code.

The only things that are in place are (but on top):
*  the SQL Statements
* All the if…then conditions
* while loops (moved into an array for later use by ExtJS)
* for loops (moved into an array for later use by ExtJS)

The removed code are:
* jQuery AJAX Code (Replaced by ExtJS)
* inline html code
* echo html code
* JavaScript code (Replaced by ExtJS)

Additional things added to the code:
* A lot of comments

The benefits of this change, is that I don’t have to struggle with JavaScript, and making custom buttons, custom JavaScript for sorting grids, moving dialogs, hide panels, ect. All this is already done by ExtJS.

4

hrivera787 wrote on Thursday, August 26, 2010:

Ohhh, I forgot the internationalization code, I’m using x1 function, this is the function right?

5

sunsetsystems wrote on Thursday, August 26, 2010:

“Re-writing almost all the code” is not going to work.  It’s a recipe for failure.  There are other developers (like me) working on significant portions of the code also, how on earth are you going to reconcile their work with yours?

Please take some time out to consider how you can avoid changing code that is not directly related to your changes, and how you are eventually going to produce a patch that does not destroy the work of others.

Rod
www.sunsetsystems.com

6

sunsetsystems wrote on Friday, August 27, 2010:

To expand on the above with a suggestion… when you’re changing a lot of code that has to work together in a lot of different scripts, you can make it conditional and use a global switch to turn it on or off.  That way you can change modules one at a time, get them reviewed as appropriate, and check them in as you go without breaking things.  Then when it’s all done you can flip the switch and enjoy the fireworks.

This was sort of how I handled the transition from SQL-Ledger to internal A/R.  Eventually the old SQL-Ledger stuff can be removed painlessly.

Another thing you may be doing is “re-writing” code because you can’t stand the indenting or other cosmetic issues.  Make that a separate step if you must.  I.e. for a given module fix just the cosmetics, check it in, and then go on to whatever is next.  That way your later *functional* changes will be clearly identifiable and your patches, when reviewed, will actually mean something.

Rod
www.sunsetsystems.com

7

hrivera787 wrote on Friday, August 27, 2010:

Thanks Rod, I think you hit the JackPot, maybe a dropdown menu in the login screen, to let the user choose either ExtJS Framework or default UI, what do you think?

This way, the user can post BUGS.

Please Rod, next time be a little more positive on your comments. Remember I’m trying to improve the code and the application NOT breaking it.

8

sunsetsystems wrote on Friday, August 27, 2010:

Sorry about the tone of my first response.  I was reminded of some annoying prior experiences with others.

I was thinking in terms of a flag in globals.  There is already a switch there to select the layout style and you could add to that, or just create something temporary and simple.

Thanks,

Rod
www.sunsetsystems.com

9

hrivera787 wrote on Sunday, August 29, 2010:

Hi everyone;

The Patient Notes Screen, will be changed anytime soon or the version of that file, is final?
I’m planning on change it, to ExtJS.

10

bradymiller wrote on Sunday, August 29, 2010:

hey,

Can you clean up your github branch a bit, so we can test it. It’s not working because I think you have your instance specific library/sqlconf.php file in there (with your database settings). Also, would be good to rebase it to the master so we’re testing it on the most updated codebase.

Also, I’m a bit confused for your reasoning on “Why the radical change?” in your first message above . Your project is gonna take a huge number of developer hours to complete. It actually depends on what your trying to accomplish. If your goal is to improve OpenEMR for the community in the most efficient manner, then should have a better rationale. However, if your doing it simply because you enjoy it and hope it will also contribute it to the project, then the rationale is fine.

My main concerns at this point:
1) Internationalization
2) Increased code complexity for the new developers whom have already spent a lot of their time learning the current codebase
3) Potential loss of customizability (generally is a side effect whenever working on top of a framework)

The best way for us to evaluate if these are really even issues is to be able to test your code.

thanks,
-brady

11

hrivera787 wrote on Tuesday, August 31, 2010:

Sorry to the late response;
Weather issues here in Puerto Rico.

The radical change is due to drastic changes, I had to make to the original code. If you look into my code, you will notice that there is NO:

* HTML code
* All the JavaScript code the developers made are gone.
* Some minor changes on the SQL Statements, like the “ORDER BY”, this order is done by the ExtJS Framework (on the client side)

On time to complete the integration of ExtJS Framework into OpenEMR, probably it will take some months to complete this task. I enjoy doing this, and definitely this change will attract more people to the project.

The learning curve of the Sencha’s framework is low, the framework has it’s documentation and is very complete, also has a very supportive community behind it. The documentation is available online and offline. Browsing the documentation is very easy.

About you concerns;
* Internationalization: I’m using the x1 function to do the task. But, as usual are some new text that I had to introduce to the code. I will point the new text, to it can be translated.

* Increased code complexity: The new code is easy to read and understand, is very straight forward. With this change the developers will only work with two types of languages , NO HTML, NO jQuery, NO “echo” HTML, ect.
On their web site, they have many examples to follow, in FACT, I had used their examples to make the main gui of OpenEMR.

* Potential loss of customizability: I will give you some examples on how Sencha’s framework improved well know companies to improve their existing applications. Even, I had seen IM (Instant Messaging) done with the framework. Sencha has a spotlight blog, they post companies that had used this framework to improve their products, here is the link:
http://www.sencha.com/blog/category/spotlight/

More about customizability:
This other link, shows how easy is to make your own theme, modifying only some files, and presto! a new GUI.
Here is the link: http://www.sencha.com/products/js/themes.php

12

sunsetsystems wrote on Wednesday, September 01, 2010:

Interesting stuff.  Again, suggest you consider now the future and the need to synchronize with other developers, and that a global variable to serve as a GUI selection switch may be in order.

Also suggest strategic selection of some small part of the GUI to use as a proof-of-concept and to get others interested in your ideas, and to evaluate trouble spots.  If it truly looks promising then we can accommodate you in the main code base.  I’d hate to see you put in months of work and then end up with something that is pretty but obsolete in terms of features.

Rod
www.sunsetsystems.com

13

hrivera787 wrote on Wednesday, September 01, 2010:

Agreed Rod;

As Brady suggested, in the first place, finish the immunization screen, and submit the code. And you guys decide what to do, what path to choose. But, I think the main issue here is get certified, in the mean time I will keep the integration work.

14

bradymiller wrote on Wednesday, September 01, 2010:

hi,
Sounds like a good plan. Let us know when you want us to test/review it.
thanks,
-brady

15

hrivera787 wrote on Thursday, September 02, 2010:

Hi everyone;

I had made a release of the immunization.ejs.php file.
Please review the code.

It should work, out of the box.

Try it, and let me know.

16

hrivera787 wrote on Thursday, September 02, 2010:

Sencha’s just posted the link to download the TOUCH version of the Framework.
If someday we want to develop a module for Android, iPhone & iPad we could use it.

Here are the link to view some demos:
http://www.sencha.com/products/touch/demos.php

17

hrivera787 wrote on Thursday, September 02, 2010:

Ohh I almost forgot;

When the new immunization.ejs.php is running, and you try to add a new immunization or edit, a dialog appears, if your computer resolution is low, the complete dialog will not appear, this because the immunization.ejs.php is running on a frame. This should be fixed when the complete integration is finished.

Brady:
I’m still learning Git, but I manage to use the .gitignore to ignore files like sqlconf.php, and some other tricks.

18

sunsetsystems wrote on Friday, September 03, 2010:

I guess you mean this?

http://github.com/hrivera787/openemr/blob/OpenEMR-EXTJS/interface/patient_file/summary/immunizations.ejs.php

What else needs to be installed, and where does one get that from?

Rod
www.sunsetsystems.com

19

hrivera787 wrote on Friday, September 03, 2010:

Hi Rod:

The only things that immunizations.ejs.php requires is:

- library/extjs-3.2.1/*
- ui_icons/*

And that’s all.

The ejs.php is made because I need the original code, so I can convert the code to ExtJS side by side.
If you download the complete code from the branch, it will run. I had to modify some other file like the interface/patient_file/summary/stats.php to call the immunizations.ejs.php file.

The only issue is that, when adding a new immunization, it will pop-up a dialog, but from the same frame, not another instance of the browser. This dialog will remain inside the frame, not on-top of the web-app as it should be.

I have a solution for this, but it will add more complexity to the current code, and I don’t want that.

20

hrivera787 wrote on Thursday, September 09, 2010:

Brady or Rod;

Did you guys tested the immunization.ejs.php yet?