Need a global javascript function to handle tab vs frame #383

Open
mdsupport opened this Issue Dec 11, 2016 · 3 comments

Projects

None yet

4 participants

@mdsupport
Contributor

Instead of handling individual situations, it may be better to provide a common javascript. Hopefully we will start practice of loading javascripts at the end unlike this project's practice of loading with the header.

Here is a code fragment in single_order_results.inc.php that breaks when using tabs:

// Called to show patient notes related to this order in the "other" frame.
// This works even if we are in a separate window.
function showpnotes(orderid) {
// Find the top or bottom frame that contains or opened this page; return if none.
var w = window.opener ? window.opener : window;
for (; w.name != 'RTop' && w.name != 'RBot'; w = w.parent) {
if (w.parent == w) {
// This message is not translated because a developer will need to find it.
alert('Internal error locating target frame in ' + (window.opener ? 'opener' : 'window'));
return false;
}
}

@sunsetsystems
Contributor

Agree re common JS functions. Need to balance this with minimizing the number of HTTP requests to load a page. So I guess this point should be part of a larger topic of guidelines. Similarly for loading JS at the end, though that bears more discussion as it may depend on the situation.

@mdsupport
Contributor
mdsupport commented Dec 12, 2016 edited

From software architecture perspective, when you construct a module you would have server files (php) and client files (js). Server code should focus on functions / business logic and client code focus on presentation. So client libraries will be very few. From network traffic perspective, having separate js code will allow us to minify them.

More importantly, taking calendar as an example for every date field, we force developer to add css and js references, at least 400 characters of html code and few lines of javascript. With a common client-side function, developer will have something like in its simplest form:

<input class='<emr-date / emr-datetime>' name='xyz' value='abc' />

jQ will then add css to head, bring in necessary js libraries and add all the decoration around every field. As a bonus, if you ever decide to switch calendars, it would be a single file.

Maybe @MatthewVita / @robertdown can highlight potential issues with common javascript libraries in this application.

@MatthewVita
Member

Hi @mdsupport,

The real "meat" of what you're correctly pointing out is a need for separation of concerns in parts of the codebase, which is a modernization item.

From software architecture perspective, when you construct a module you would have server files (php) and client files (js). Server code should focus on functions / business logic and client code focus on presentation.

I did just this with the recent product registration feature that Brady and I worked on:
https://github.com/openemr/openemr/tree/master/interface/product_registration

I think the code came out nice and we should start moving other parts of codebase in this direction. Perhaps this approach can be taken for improving the tabs/frames implementation. One nice aspect of this approach is that it is pretty portable to the long-term effort of switching to Zend and Doctrine.

Thanks for including me in this discussion. Apologies in advance for being more academic with my response.

-m

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment