How do you call into a Table Class

[Mayada Al-Kishtini]

Thank you Bas for answering Das's question, you covered it in an excellent way.

This is my 2 cents to Das (in a simpler approach):

Das, it all depends on the way you design your app and what type of methods you are creating. We tend to gather all common related routines and methods in object classes, so they are accessible to the entire app and can easily be maintained.

Re your question "do they keep scope with variables in windows, declared in windows, or do you have to pass everything as parameters or references"

Again it depends on what variables you are referring to, if you are referring to a column in your list or row variable, then those will be visible in your table class (but not the object class), other variables declared in the window will need to be passed to the table class or object as parameters.

 For table classes, I sometime have methods in the table class, other than the (select, insert, delete and update), to get data related to that table, example: in your window you have a row var custrow, defined from table class t_customer, table class could have a method called $getCustomerAddresses.
Then you could do something like this :

customer_seq could be a local or instance var in your window.

Do  custrow.$selectexact('cust_seq', customer_seq)  ;;populate the row var

Do custrow.$getCustomerAddresses() Returns custAddressRow  
OR
Do custrow.$getCustomerAddresses()  ---you populate columns in custrow with the results so you can access it from your window as custrow.address1, custrow.address2 etc.

In this case $getCustomerAddresses will have access to all your custrow schema columns..$cinst.cust_id, $ cinst.cust_seq etc..so you don't need to pass them as params.
The output from $getCustomerAddresses could either be returned as a row variable custAddressRow to your window, or you could add the extra columns to your table class in the table class $construct by doing this:

Do inherited
Do $cinst.$cols.$add('address1 ,kCharacter,kSimplechar,100) 
Do $cinst.$cols.$add('address2 ,kCharacter,kSimplechar,100)

and just populate them in $getCustomerAddresses and in this case the data will be available in your window thru the custrow.columnname.

This is just a simple example of a case where you don't need to pass params to the table class method; otherwise, in general, variables declared in your window won't be visible to your object or table class unless you pass it to them. 

HTH,
Mayada

-----Original Message-----
From: omnisdev-en [mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Bastiaan Olij
Sent: Tuesday, January 30, 2018 5:31 PM
To: OmnisList
Subject: Re: How do you call into a Table Class

Hey Das,

I could write an entire book on this subject :)

The short answer is, what you suggest is a bad idea. This will probably be the longest part of your learning curve wrapping your head around object orientation and why it works. Until you grasp it, it'll feel like its constantly throwing up needless roadblocks. Once you grasp it you'll find you'll be writing much more stable and usable code.

There is a golden rule in OO and that is that an object should never know about its outside world. If you create a class (in your example a table class) and the execution of a method of that class depends on the existence of something outside of that class (in your example variables on a window), then suddenly that object has a number of problems, I'll list two of them, but its the tip of the iceberg.

Think of the fact that unlike Omnis Classic, Omnis Studio allows you to have multiple instances of a class. For instance, in classic your table is represented by a file class, a file class can only hold one record at a time. A function you wrote only had to deal with one such record, you could cut lots of corners knowing this.
Now in Studio I have a table class, instantiated as many times as I want. Lets say I have a window that enters a customer and for that customer I want to record two addresses. A mailing address and a delivery address. Good database design tells me I'll have a table with customers, and I will have a table with addresses. Each customer will have two records in the address table.
On my window I want to show those two addresses so I have two instance variables of type row both defined from my address table class.
Now my function on my table class uses a variable on my window... But I have two records... I need two different variables, but I hard coded it and I told the table class it should use a variable on my window called X.

For the second example, think of having a table class for an invoice table. Again on my window I have a row variable defined from this table class. For whatever reason this table class assumes certain other variables exist on my window and uses those variables in its methods.
All good and dandy so far. My window works, I'm happy.
Unfortunately for my colleague however, some months later she is tasked with writing a process that creates invoices for all un-invoice work for all our clients. Our client is tired of having to do those manually through the window I created so they want to automate this. She creates a new window that gathers all the un-invoiced work, loops through this data and for every entry creates an invoice that invoices that work.
Inside this look she creates a row variable, she defines it from my invoice table class, populates the columns and calls $insert.
$insert errors out because $insert relies on a bunch of things that only exist on my window that was written for a user to enter a single invoice.

Now the thing is, there is one concept that is hard to get when moving from traditional top down programming to object oriented programming.
You are used to variables with data existing somewhere, and handing those variables over to a function.
In OO methods work on data. Object classes remain the easiest ones to explain this with. You have an object, that object encapsulates a number of variables, and it has a number of methods that perform actions on and with that data. The object should be self contained, it encapsulates the variables and logic. In practice, once used properly, it means you're variables won't exist on your window, they will exist within the object, most of the time and yes, those few times you need to use a variable in your window, you'll have to pass that as a parameter to a method.

A table class simply adds to that columns of your table but functionality they are no different than using an object which has an instance variable for each column in your table. Practically table classes just make working with those columns easier because it holds more meta data about your table that allows you to generate the required SQL to interact with your database.

Anyways, enough information overload :)

Cheers,

Bas


On 30/1/18 11:42 am, Das Goravani wrote:
> Mayada,
>
> Why do you prefer the object class, and, the call is not the same because a table is INSIDE a row or list, the object is not, as far I understand, and, what about losing touch with your variables inside the window you’re calling from?  I can’t lose touch with them… I have yet to see how a table works out, I’m just trying it now… tables and objects… do they keep scope with variables in windows, declared in windows, or do you have to pass everything as parameters or references, that I am curious about.  Thank you for your valuable time. 
>
> Das Goravani
> We both have nice names

_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com