(newbie at oo)
I created a class to manage chores of handling a Master-Detail relationship for an invoice(s) document.
So, created include file with dataset that is "equal" to real data-table on db to handle data creation inside class.
Then used that same include on .w with browse,and fields for getting data from user, accesory tables and then validating etc. the usual stuff as I can imagine...
So I finished with "ttMaster" and "ttDetail" on window side, just about to send to object, which in turn has methods to accept data to create ttMaster and ttDetail inside and the flush to db.
That didn't seemed too natural for me at this point, as I have the same tables that the class will be creating by means of methods exposed on that class.
In fact, on user side, data was filled on that tt's as the class will be used by a "proxy" procedure on app server.
So will be sending dataset to create_invoice.p on hServer (the proxy), wich in turn will instantiate that class just to call methods to create ttMaster and ttDetail, doing something like:
oMaster:CREATE_NEW(ttMaster.Datex, ttMaster.Customer, .etc.) // same for detail...
and method will receive paramters, just to:
CREATE (another)ttMaster.
ASSIGN
Datex = paramDatex
Customer = paramCustomer .etc.
after all that...
SAVE_Method():
CREATE database.Master.
ASSIGN
Master.Datex = (another)ttMaster.Datex.....
I really hope I had explained correctly so I can transmit my confussion.. (jajaja)
What is the correct way of doing this?
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.