How do you call into a Table Class

[Andreas Pfeiffer]

Bas,

This is a brilliant explanation!

Best,

Andreas

> Am 30.01.2018 um 23:31 schrieb Bastiaan Olij <bastiaan at basenlily.me>:
> 
> 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