The notion of being able to use a reference key to access an object is important from a script creation and maintenance perspective. Sure, the basic operations seem to work fine, but its infinitely less effort to simply change a data file and object map than to do anything with code (as well as mitigating the associated risks in changing code).
In my continued search for a use for the OR, I looked at two possible options. The first was to define the objects within a page with special precursors - like "ed" for an edit field, "ls" for a list field, etc. By using these object names as the data table parameters, I figured that I would instantly have a mapping of sorts.
The first issue I realized that I had not accounted for within this structure was the parent. Sure, I have the child but I have no idea of its parents within this formulation. A simple work around was to pass the parent object to the function to handle the data table processing. Another solution that would work would to have used the entire parent object structure as the identifier - this I didn't try since it would be too ugly. Given the parent object and child name its possible to create the child object using the precursor key. The object definition could be made in the following way:
The next obvious alternative is to define the object with a reference within a dictionary. The reference would be the key and would be used as the parameter in the data table. This is a fairly elegant solution which has the following appearance:
A generic means of identifying the type of object so that the correct action is performed on it is a simple task. The need to do this is necessary so that for entering a value one can call the correct function be it Set or Select. One solution is the following:
Redefining the object within a dictionary just to simplify the scripting process doesn't seem to be logical. If I throw out the OR and use DP then I've one less place for performing maintenance.
I still don't know why you would use the OR. One more possibility remains to be explored and that is the OR object model. A brief look has left it looking as light on the useful side as the OR itself but I'll give it due consideration in time.
In my continued search for a use for the OR, I looked at two possible options. The first was to define the objects within a page with special precursors - like "ed" for an edit field, "ls" for a list field, etc. By using these object names as the data table parameters, I figured that I would instantly have a mapping of sorts.
The first issue I realized that I had not accounted for within this structure was the parent. Sure, I have the child but I have no idea of its parents within this formulation. A simple work around was to pass the parent object to the function to handle the data table processing. Another solution that would work would to have used the entire parent object structure as the identifier - this I didn't try since it would be too ugly. Given the parent object and child name its possible to create the child object using the precursor key. The object definition could be made in the following way:
Select Case right(objName, 2)As a solution this works but having to track the parent object is not exactly the aim of the exercise. Sure using the entire object definition as a column header would work but doesn't make for simple data management not to mention the headache of maintaining the column headers when the application changes.
Case "ed"
Execute "Set appObj = " & parentObj & ".WebEdit(" & objName & ")"
The next obvious alternative is to define the object with a reference within a dictionary. The reference would be the key and would be used as the parameter in the data table. This is a fairly elegant solution which has the following appearance:
Dim appObjects: Set appObject = CreateObject("Scripting.Dictionary")
appObjects.Add "myEditField", Browser("A Browser").Page("A Browser").WebEdit("myEditField")
A generic means of identifying the type of object so that the correct action is performed on it is a simple task. The need to do this is necessary so that for entering a value one can call the correct function be it Set or Select. One solution is the following:
If InStr(appObj.ToString(), "edit") ThenUltimately this works. The issue is that I question why I've defined the object in the OR. Does the OR really save effort over using DP?
appObject.Set DataTable(keyString, myDataTable)
Redefining the object within a dictionary just to simplify the scripting process doesn't seem to be logical. If I throw out the OR and use DP then I've one less place for performing maintenance.
I still don't know why you would use the OR. One more possibility remains to be explored and that is the OR object model. A brief look has left it looking as light on the useful side as the OR itself but I'll give it due consideration in time.
No comments:
Post a Comment