Additional properties for a custom plugin

This forum is for programmers who have questions about the source code.
Post Reply
User avatar
tim
Posts: 24
Joined: Wed Mar 08, 2017 5:11 am

Additional properties for a custom plugin

Post by tim » Mon May 01, 2017 4:42 am

We would like to have some user-configurable additional properties for our plugin.

Presumably, we need to create some initial OpenDentBusiness.ProgramProperty entries that will populate the additional properties table in the program link edit form. However, since this is a custom program link, the ProgramNum value is unknown at compile time. Is there a way for a plugin to get its ProgramNum? If not, should there be (maybe in a similar manner how Plugin.Host is set on plugin load)?

Thanks.

allends
Posts: 235
Joined: Fri Aug 23, 2013 11:29 am

Re: Additional properties for a custom plugin

Post by allends » Mon May 01, 2017 8:15 am

If I was going to go about this I would just give them a setup window from somewhere in the program that they could set their own custom preferences.
I would store those in either my own MySQL table or an XML file depending on if they were workstation or database specific.
Allen
Open Dental Software
http://www.opendental.com

User avatar
cmcgehee
Posts: 711
Joined: Tue Aug 25, 2015 5:06 pm
Location: Salem, Oregon

Re: Additional properties for a custom plugin

Post by cmcgehee » Mon May 01, 2017 8:33 am

To expand on Allen's answer, storing these preferences in your own MySQL table would be easier for you in the long run. For example, if you decided later on that you would like to assign program properties on a user level, if you have everything stored in your own table, you can easily add any column that you need. Very rarely we even remove columns or a table, so it would be safer to store data specific to your application in a separate table. Just be sure to not give it a name like 'programpropertyuser' because Open Dental could conceivably create a table with that name in the future. Name it something like 'timscoolpluginprogramproperty'.
Chris McGehee
Open Dental Software
http://www.opendental.com

User avatar
wjstarck
Posts: 935
Joined: Tue Jul 31, 2007 7:18 am
Location: Keller, TX
Contact:

Re: Additional properties for a custom plugin

Post by wjstarck » Fri Jun 02, 2017 8:04 am

This brings up an interesting question.

I can imagine the possibility of several third party developers settling on the same table prefix(es) for their tables with potentially disastrous consequences.

Here's an example:

My anesthesia software utilizes a 3rd party MySQL schema engine that parses HL7 data that is sent to a folder on the server from networkable vital sign monitors via a TCP/IP listener. By design and for easy identification (and to separate them from OD tables), the prefix naming convention for all of my tables is anesth. The software then imports the data directly into my OD database tables to be displayed on an anesthetic record.

Setup in the third party software is done my generating and validating an HL7 schema depending on which version of HL7 the developer has implemented (in my case it's 2.4). When this setup is done, it's necessary to assign a 4 character prefix to the tables that will be generated by the schema engine. The software then appends a '_' to this prefix so that all of the tables generated by the schema engine look like so:

anes_segment_msh_a
anes_segment_pid_a
...


and so on.

OK, so far so good. It's possible to create, repair, remove and recreate HL7 schema tables without any affect on similarly named tables, because the schema software is supposed to know that the '_' that's appended to the 4 letter table prefix identifies the table as unique to the schema engine, and the schema engine will NEVER EVER TOUCH any MySQL table that might begin with the first four characters but isn't directly followed by an underscore. Did I say NEVER EVER?

Notice how I said 'supposed to know' in the previous paragraph? Well, it 'supposedly knew' for over 7 years. I had no reason to suspect it would ever operate differently. That changed on August 22nd, 2016. Turns out the developers had introduced a bug that caused their software to ignore the underscore character following the table prefix. So, installation of their new version completely wiped out all of my tables FROM.THE.BEGINNING.OF.TIME since my tables began with the character string 'ANES' (mine are named anestheticrecord, anestheticdata, anesthmedsinventory, etc.).

Now in software that tracks delivery of controlled substances to patients that is a VERY BAD THING (TM) since there is this little government agency known as the DEA that does not have a very big sense of humor for things like missing data when it pertains to delivery of controlled substances.

My workaround was to name the tables created by the schema engine with the prefix 'aaa' so that this NEVER.HAPPENS.AGAIN. But what would happen if another 3rd party developer settles on 'aaa' as a prefix for his tables because that would put all of his tables at the beginning of the table list for convenience? I shudder to think of the consequences, as in the case of my scenario, there might not be a MySQL routine the developer has written to check if tables already exist before overwriting or deleting them.

So it seems a solution might be for OD to implement a database of developers with a list of their reserved table prefixes that could be published on the OD website. Ideally, the database would be interactive so a developer could register his or her respective prefixes, and the date that each prefix was recorded could be displayed.

Then, any new developer could check the database against his or her schema before naming his or her tables. Disaster averted.

What do you think?
Cheers,

Bill Starck, DDS
Big Idea Software, LLC
Developer, EASy(Electronic Anesthesia System) for Open Dental
817-807-1709
TX, USA

Post Reply