D
dbeavon
Guest
There was a lot of confusion where static TT definitions are concerned. I spent quite a bit of time working thru this too. The problem is that TT's themselves aren't OO objects in ABL, and can't be passed around easily like other reference/heap data types. The conclusion I finally came to was that, come what may, I wanted my business logic classes to be separated as much as possible (in OO/ABL) from the temp-tables and datasets that they depend on. For this to happen, we decided that the logic classes should pull TT definitions from "include files", and should only be permitted to access them as "REFERENCE-ONLY" . That means any time you need one, it needs to be passed in from your appserver lean-in program (BY-REFERENCE) or you may one day need a utility OO class that creates an instance for you (OUTPUT BIND). Here is some code that gives an idea of what an "include file" would look like: /*------------------------------------------------------------------------ File : CoolData.i ** {1} for REFERENCE-ONLY ** {2} for access modifier ** {3} for additional prefix specification ** (when more than one instance of data is needed : eg. TT2, TT3, TT4, etc) ** ----------------------------------------------------------------------*/ DEFINE {2} TEMP-TABLE TT{3}_CoolTable {1} ... A business logic class would refer to it like so: {app/CoolData.i REFERENCE-ONLY PRIVATE 1} But, somewhere along the way, the source of the actual underlying TT instance would need to declare it like so. (eg in your appserver lead-in program) {app/CoolData.i} Hope this helps. If you come from a Java or C# programming background, it is easy to be frustrated by the implementation of static TT/DS in ABL, since they aren't very flexible when sending them around from one piece of logic to the next, or using more than one copy of them at a time. The alternative is "dynamic" TT/DS handles but those suffer from other types of problems.
Continue reading...
Continue reading...