Forum Discussion
I have never understood why implementors use Textn properties in such a manner.
It might be a little difficult to implement after the fact, but the most obvious solution (to me) is to store delimited PropertyName=Value pairs in the Textn properties. A Textn property can store up to 2GB of text, so you shouldn't need to worry about running out of space.
Example: Text1: Deptartment=Other,TransMethod=XYZ,Colors=[Green,White],LegalDesc=[XYZ, Inc.]
Not only can you store more than 8 things in member or 4 things in a Workflow, but the PropertyName also offers some clues as to what the Value means and what it might be used by, whereas Text8=Y (in your screen shot) offers no clues, and worse, where Text8 might be blank, does that mean it can safely be used for something?
You will need to build a function that can efficiently parse through and return the Value for a desired PropertyName. You should probably also build the function to allow Value to contain a delimited list of values, as I showed in the above example where I wrapped the value in [], which can also be used to store alternate descriptions that could include delimiters.
I have been using delimited PropertyName=Value pairs in OS for 10 years now. In many implementations, I can stack all PropertyName=Value pairs in Text1. The main reason I will utilize additional Textn properties is if certain PropertyName=Values pairs need to vary by ScenarioType/Time differently than other PropertyName=Value pairs. I have taken it to the next level by building a Text Property Manager where I centrally manage to what Textn a PropertyName has been assigned, such that if I find out down the road that the PropertyName needs to be moved, I can do so without changing any code.
Related Content
- 3 years ago
- 3 years ago
- 1 year ago
- 3 years ago