I’m looking at Open EMR with a dev environment of Eclipse PHP. When I got the project pulled and configured Eclipse found 25 errors and over 13,000 warnings. Now the errors are a mix of harmless and false alarms … mostly mildly mangled HTML or HTML that it just thinks is mangled because the closing > is on another line with string concatenation happening in the middle.
So, two questions.
1 - What IDE/environment are other people using to tend this code base in and are you suppressing warnings?
2 - A lot of the warnings look easily fixable. For example, several hundred are from the verbiage “wrap=virtual” in textarea tags. This is a nonstandard tag which is why Eclipse has issues with it. And I’m nearly certain it doesn’t do anything (anymore)?
I’d like to get in a configuration where a “clean” parse has no warnings or errors … I’m just anal that way sorry … so if there is a recommended dev setup where that is so I’d love to switch to it. If not, may I submit some “hush up” re-factoring patches that clean this sort of stuff out?
From the web “You may from time to time see other variations on WRAP, such as VIRTUAL or PHYSICAL. Netscape introduced these attributes a few years ago as proposed extensions to HTML 3.0, then abandoned them. Officially, the HTML 4.0 specs don’t list WRAP, but Netscape and MSIE list WRAP = HARD | SOFT | OFF in their guides. It’s best to stick these three values.”
1) I use a linux command line console with a jed or vim editor on a local git repository from github.com. (running it on a OpenEMR Developer Appliance on a windows machine, so I putty into it)
2) Cleaning up code is always a good thing. Just ensure to do the proper testing. We just got done removing bad end of line code in about 200 files (to allow git to work in windows), so we’re definitely open to keeping it standard. If these are harmless, then may not be a great use of your time, but that decision truly depends on what you want to do.
The 25 flat out errors don’t take much time to fix. For example, in openemr/phpdmin/test/theme.php there are four ‘/label’ closing tags that are missing their ending ‘>’.
A lot of the warnings can be fixed with scripts. For example, a few thousand are from uppercase letters in html tags/attributes. Per html standards the tags are supposed to be all lowercase and they are lowercase in much of the project. The HTML::Parser perl library has already solved the problem of recognizing html tags amidst normal text, making transforming them all to lowercase easy. Others are more stubborn, for example areas where there are block element tags inside span tags ( the point of span is to be inline etc ), and would require a human touch.
But I can totally see being leery of some stranger writing a script to do that and submitting a patch that touches hundreds of files, particularly to suppress warnings in a development environment that you aren’t using and are unaffected by.
But if I do it just to my pull then I come out of step with you. So I figured I’d ask.
Also, I’m about to start reverse engineering setup.php to find all the places things get, well, setup. Is there existing documentation that shows that?
hey,
Sounds like fixing the erros is plausible, just be sure to test it.
Can you configure Eclipse to ignore the warnings, so your code doesn’t stray (may make patching harder for you). We definitely don’t want to limit our develop pool by not supporting preferred developer environments.
-brady
Project properties -> Validation - > HTML Validation -> downgrade various events from warn to ignore.
But if you do that then you don’t get warned when you do something silly. Like if I tell it to stop warning for invalid tags like
the virtual=wrap then it won’t react when I typo a tag name. So that reduces the utility of the tool to some extent.
Humbug etc.
On a side note, what is up with the sql/DBC_sql_statements directory? I don’t see it getting called anywhere
but it looks like its full of all sorts of juicy data. In addition, it creates tables that database.sql doesn’t. Are they legacy?
Just zipped up there for nostalgias sake?
hey,
sql/DBC_sql_statement no longer exist in the development tip; this were code from a set of developers in the past customizing openemr for Dutch system. Lots of non-standard practices used, so their code has been removed.
-brady