Tag replacement using object private data

[John Lokanis]

I have a need to access the private data values and control names at runtime.  I have come up with a quick solution but was wondering if anyone had a better way to solve this problem.

 

Background:  I want to execute some SQL statements that insert data into a DB.  These statements are in a config file.  Each section of the config file has a name and a series of statements to execute.  These statements have tags for the data values that I want to replace with real data.  These tags correspond to the names of elements in a class's private data.

There are several classes that contain data I want to write.

There are several different sets of SQL statements, each with different set of tags within them.

I want to be able to modify the SQL statements outside of the application without changing the code.  This needs to work as long as the object containing the data has elements that correspond to all the tags in the SQL statements.

So, what I am looking for is a generic solution.  I feed in an object containing the data, a name of the set of SQL statements in the config file to use and the code takes the data out of the object, using the element names in the private data to match to the tag names in the SQL statements and then replaces the tags with the values of the data in the object.  I can then execute the statements and my data is in the database.

 

I have attached the VI I came up with to take the tag name and return the object data.  This has some limits I am willing to live with.  First, the elements in the object must have unique names.  If they are not unique, the tag is going to get replaced with the first match only.  Second, this mainly works for simple objects that do not use composition or arrays of other objects, since we would always match to the first element in the array.

 

Why not just create a VI that unbundles the data in the object and wires it into a VI to do the replacement and execution of the SQL?  Well, given the number of elements that need to be replaced, these VIs would be porcupines at best.  And I would have to update them every time I added elements to the class.

Why not simply bundle the class data into a cluster and pass that in, then use VI Server calls to get the cluster element names and do the tag replacement?  Again, I would have to maintain two versions of the class data structure and update both when changes were made.

And finally, why not build an array of name-value pairs from the object data and use that for tag replacement?  Same issue of maintenance.  I would have to add a new name constant each time I updated the class.

And with all of these solutions, I would have to build the custom version of the tag data extraction for every SQL command set case.

 

I know some of you have come up with some interesting ways of accessing class private data.  I am looking for a stable approach that is likely to continue to work in the future and is simple and fast.  Please share any solutions you have.

 

Here is my first attempt:

Get Class Private Data Value by Name.vi

 

-John

[mje]

Why even use static bound data if you're essentially looking to do late binding? Seems like an ideal place to use the look-up ability of a variant here.

 

 

Plus it doesn't necessarily break down the idea of scope. Keep what data you need to be late bound through that interface and anything that's off limits can stay statically bound as normal private data fields. There's of course performance issues going through the name lookup and type checking, but I don't see a way around that if you're not wanting to do bind things statically at compile time.

 

LV2013 Code: DynamicData.zip

[John Lokanis]

I am not sure I understand your solution.  But, I have already created the classes that store the data and do not want to modify them.  They are used throughout the application already and changes would be far reaching.

I could add a method to their parent that extracts the name-value pairs of the class or gets the value of the element by name.

[mje]

Ah, I see. I thought this was a design time thing, not something that's being worked into an existing implementation.

[shoneill]

Casting the object to an XML string doesn't do what you need?  This will be a killer if your objects store a lot of data but any values which are not the default for that class will be listed in a searchable form.

 

It's a gaping hole in object encapsulation which I've made use of before, but haven't actually used it since LV 2009 so maybe it's been "patched".

 

Shane.