Tips_todo > Objectclasses > Data Objects
I'm not sure if "data objects" is the correct term for this tip. If there is a better term which I should be using, please email it to me.
When you get fairly deep into the object-oriented mindset, you start to see that everything in Omnis Studio is an object. Objects have attributes or properties, plus methods that do things. In Omnis these attributes or properties plus methods that do things are represented by public methods.
Let's say we create an object class called "oApplicationProperties".
Now we decide to add some "properities" to this object. A public method is added to oApplicationProperties for each "property". ($ApplicationName, $VersionNumber, $CreatedBy, $LastModifiedDate)
The code behind each of these "property" methods ends with "Quit method VALUE".
You can also make a "property" assignable, by adding a $assign method.
e.g. $LastModifiedDate.$assign(pLastModifiedDate)
The public method name actually includes the ".$assign" suffix in the method name!
You can now instantiate "oApplicationProperties" using an instance variable in a window class, and then use the instance variable name followed by the public method name as the $dataname for the entry fields in the window class.
e.g. Instead of "iList.COLNAME", you would use "ioProperties.$LastModifiedDate"
If there is a $assign method available for a property, Omnis Studio will automatically call the $assign method in the data object just prior to the evAfter event for the entry field.
Thanks goes to Weitse Jacobs for demonstrating "data objects" in Omnis Studio to me.1. You can use data objects to create a "layer" between your interface layer (window and report classes) and your persistence layer (schemas/queries/table classes). This layer can give you finer control between these classes and the flexibility to use different field names.
2. The $assign suffixed method is called before evAfter allowing you to execute code prior to the evAfter event. There may be situations where this would be useful.There are some drawbacks to using data objects.
1. A list property cannot be directly used in a window object $dataname.
If I have a data object property, $ListOfThings, I can't put that property name directly into a headed list, droplist, combolist, etc. Studio simply won't support it. The work around is to create a list variable in the window class, and "Calculate iList as ioPref.$ListOfThings".
2. Data objects can be used in web client remote forms. To the best of my knowledge remote forms will only support row and list variables.
3. Creating the data objects can be time consuming. You have to create a public method for each property, and a .$assign suffix method for each assignable property.
(In StudioWorks I created a data object superclass which allows you to use a schema class to define "properties" in a data object. The superclass automatically adds new "property" methods for any columns that are added to the schema class. You might question the sanity of going through all that effort, but there are places where data objects improve code readability and reduce code maintenance.)The question remains, are there any practical uses for "data objects".
I have found data objects to be handy for storing and modifying "preferences" properties.
Code Documentor uses an object called "oCodeDocumentorPrefs".
The window class "wTips_CodeDocumentorPrefs" uses ioPrefs.$PropertyName for the $dataname in various fields. Changing a value in wTips_CodeDocumentorPrefs changes the value in the "oCodeDocumentorPrefs" data object. Any code which uses on of the "oCodeDocumentorPrefs" properties will use the new value.
To check out the Code Documentor Preferences object and window,
1. Select "Code Documentor" in the lower tabstrip.
2. Right-click anywhere in the Code Preferences window and select "Code Documentor Preferences"
3. Ctrl/Cmnd+T to check out the fields in the window and the code behind the window.
Playing around with data objects has helped deepen my understanding of Omnis Studio and see object classes (and window classes, menus, toolbars, table classees) from an object-oriented programming viewpoint.
Think about the F6 properties of a window class. ($name, $title, $left, $right)
Calculate Left as $cwind.$left()
Do $cwind.$left.$assign(100)
Do you see the similarities to a data object? Is the window class property "$left" really just a "public method" of the window class? Is there a "$left.$assign" method that just simply doesn't show up in the F6 Property Manager, but does really exist? Does the "$canassign" method simply check for the existing of a ".$assign" suffixed method?
Do you see how you could set up your own "property sheets" using object classes?