As I make a few changes which are benefiting my practice now and I believe might be useful to others, I am realizing that the problem with changing how things work is that there is an established user base already, some of whom will not want certain things changed, although they may want to upgrade for bug fixes and new features that are in line with what they are already used to.
Here is my idea:
in the administration section, there will be a page where the administrator picks a particular configuration, named after the programmer who is in charge of that configuration. Then, features that go with that configuration will be activated.
The way it works is like this: files that belong to a configuration will be either new files or modification of existing files. If the file is a modification, it will have the same name as the standard file, but the name will end in _developername.php, for example: patient_report_markleeds.php. If it is a new file, it will have the same kind of ending to identify it. The developer will be responsible to make sure that the code is in place to choose the correct file based on the selected configuration. The configuration will be saved and checked in the array table. This is a table I am using (it may not be in the CVS version yet) which is like a rudimentary associative array for storing lists of strings and configuration data. It has a set of functions that go with it for the access interface.
If implemented properly, users will not notice major changes that go against the interface they are used to unless they want to enable an alternate configuration to take a look.
I have done most of the work on this and I could set it up and take the recent changes I have made to OpenEMR and make them available as a configuration.
Let me know if this is a good idea and if there is any interest.
Of course, if users and developers agree on changes made within a configuration, the involved files could be brought into the standard configuration space.
One thing we want to avoid is redundant code. I.e. it’s almost always better to have a section of code that checks for and acts on different configuration options, than to clone that section for each different option.
It’s OK add a feature that others don’t want, as long as there’s a straightforward way to enable/disable it. See for example the changes that I made to support use by athletic teams, which are enabled only if you set $GLOBALS[‘athletic_team’] to true in globals.php.
Also it will be more useful to identify an option according to the feature that it enables, rather than by someone’s name.
I would say an administration page makes sense for options that the user may want to change from time to time. For something that’s a one-time setup choice during installation, I wouldn’t bother.
That’s pretty much what I’m working with now, just different names for the columns. I can add on a description column. I named my table ‘array’ and the columns ‘array_key’ and ‘array_value’.
The important thing is the interface of access functions. The table structure can always be changed behind the interface.
It also allows for forms which can have selectable and editable presets.
I am going to commit some files later so you will be able to look at it and try it out.