aethelwulffe wrote on Thursday, February 16, 2012:
WARNING! ART RANT:
Not into classic literature? 
…admittedly, if you look too closely at the spelling of the word without simply recognizing it, you might be inspired by the crudity of it’s possible meanings. Of course, I lived in an are called “The Mangrove Morass”.
I grew up reading 19th century literature (our community had not invested in any new library books for a rather extensive period of time), and I am rather surprised sometimes at what appear to be huge gaps in most folks vocabulary. My wife is far better more extensively institutionally educated than I, but chokes on words I consider to be etymologically basic English. I hear the local domestics haver (that means ‘babble’ without the Judea-Christian implications) about immigrants needing to “Larn Anglish” when they come to the US, yet look confused when I utilize a word longer than two letters.
ZEND
I agree about the whole “is a framework shift worth it” idea. There has to be a pay-off. Fine. On that side, I think it’s a pretty good holistic outlook as far as representative features for end users (holistic=big picture, complete). There are other factors rather than what an end user may call a feature.
Lets go over them:
API- Admittedly, Zend will not give us a completed programmer’s interface for OpenEMR developers. That would be our job. On the other hand, there ARE functions and API documents for those functions with the framework, though buried in it’s “obtuse morass” of technobabble that is the typical “Developer” answer for technical writing. We would be looking for tightening code using the existing functions, and creating our own API derived from Zend and our own libraries, or rolling our own functions and libraries into a cohesive set…and documenting it. There is a catch here for Zend: It’s own API seems inconsistent in different areas, and of course, it’s documentation sucks in more way than one. For instance, you may be reading along, and the language for use will flop back and forth between assuming one OS, and then another. It’s seriously inconsistent.
Developer Accessibility- PRO: There are good coders out there that would be pleased with a shift to Zend. CON: Most of us are not good coders. It seems folks either grew up with Zend, or it makes what used to seem easy very difficult…and they would have to start reading a lot of the php5.3, Apache, and OOP equivelant of 19th century literature to even begin to understand it’s use.
OTHER FRAMEWORKS:
Is there another framework that is applicable to OpenEMR and where it needs to go that is more N00b friendly? Ref Codeignitor or AppFlower?
ROLLING OUR OWN:
We want standards to make coding faster, reviewing easier, and allow for code maintenance cycles to actually happen. To do that, we need to define official API documented functions…and document them…while defining an “official” set of developer tools that are completely cross-platform. Differences in implementation for different Operating Systems on development machines as well as servers should be well annotated. This would involve going through a real code maintenance cycle to re-structure the openemr directory structure, cleaning up functions in a number of places and popping them into libraries, and documenting each function in a standardized manner.
Such a code maintenance cycle would probably be the best financial investment we could make. At this moment, items like basic 5010 billing and ONC cert are pretty much out of the way (not all of which has made it to the code base yet, and none of which has seen extensive testing, much less been put into a patch or release, but…). Re-vamping at this point would pay serious dividends in the long run. This would be a big project management piece (Development vs coding), but the work could easily be dispersed to many contributors if the coding standards were published. At one point, Ibelieve there was a standard for contrib forms that mattered. Directory structure, file names, and methodologies are pretty well defined, even if the ideas for it are pretty out-of date. Everywhere else in the EMR seems to be pretty much a free-for-all, and there is no road map. You have to go through code, guessing where shit is, tracking down one include after another…through multiple levels sometimes…to find what you are looking for. There should be ways to call scripts with defined functions and constants throughout the application. I have thousands of function from different engines floating in my head. I have been woking with OpenEMR for two years, and I can’t name even one function specific to OpenEMR that I can just use after referencing the proper include. They are inconsistent and undocumented as far as I know, though it is possible there are cryptic references somewhere buried on those wonderful wikis.
In one engine, I think: “I need to draw a square on the screen”. I don’t have to look at the API. I can GUESS what the function is. I also don’t have to worry about what library it is in, because the libraries that will be used are included in a library sorting include. I say "this is a draw function, so it starts with ‘draw’. So I guess draw_rectangle(view,x1,y1,x2,y2,c_black); Then I think: “I want it fancier than that”, so I guess draw_rectangle_color_extended(view,x1,y1,x2,y2,1, c_black,c_ltgray,3,c_red); to give me a gradient black to grey box, gradient from left to right, outlined with red 3 units thick. The functions are so standardized that most of the time I know the sequence of the arguments. If I need to go to the api, I can find what I am looking for indexed and searchable, and the definition will have the format, argument definitions, and a complete practical example of it’s use. I can almost always guess the name of the function, even if I am not sure of the arguments. We could have this too. With tools like that, you don’t have to have an initial understanding of a particular programming language to dabble, you don’t have to squint your eyes at long blocks of code with cryptic nomenclature to try to figure out what it is doing, and you can code in a happy content sort of way KNOWING that the functions themselves have proven performance.
That’s worth a lot to the projects of tomorrow. You can chop wood all you want, but if you don’t sharpen the axe (or don’t know how), you are not earning your pay, and you arn’t a professional woodcutter.
