|
Custom Business Objects available are Table, Query and LDAP
Query. LDAP Business Objects require an LDAP connection, and
will be examined separately. What we shall concentrate on here
are the database Business Objects.
There are two main differences between the Table and Query
Business Object types. Table Business Object is potentially
editable, given certain conditions, and it can only consist of one
table, and indeed all fields in that table. Query Business Objects
are always read-only and may consist of any tables or views and
any fields. They may also be based on stored procedures, which
is a big step forward.
The only type of Business Object that may be used in an editable
grid is a Table. This now effectively restricts editable grids from
containing calculated and sub query fields and from using joined
tables.
|
|
|
|
Moving to any Business Object component, takes you to all
Business Objects listed in a grid. You may set the name, type,
connection and behaviour (read-only or editable).
You may also set the default page size. This may be overridden
in the grid using the Business Object, but it is not clear if there is
some initial page size that may be reduced still further in the
grid. An example would be having a default of 100, so only 100
rows are returned from the server at a time, but a display page of
25. In effect four pages would be cached locally at any time.
There is a ‘requirement’ in the documentation (which does not
seem to be enforced) that the grid page size is a factor (divisor)
of the default page size, and this implies this is the way it will
work.
|
|
|
|
Looking at a Query Business Object type, you may enter any
query you wish. This may be entered manually or using the built
in Query Builder.
|
|
|
|
Even though I entered this query manually, it has been parsed
correctly by the Query Builder.
|
|
|
|
There are a great many settings, as you can see.
|
|
|
|
While discussing the Query Builder, it is worth noting that this
may be invoked from fields where an SQL statement may be used
to provide an option list. These are dropdown and listbox fields
alone, we believe. Invoking the Query Builder allows a full query
to be built, including parameters, such as the above.
We shall examine the SQL Builder separately in a future article as
it is very complex and powerful in its own right.
|
|
|
|
In the SQL we had parameters denoted by the ‘@’ prefix. These
are defined in the Parameters tab.
We can set the data type, a description and an optional default
value. The default value is set when an instance of the Business
Object is created for use in a Form or Process. This makes it easy
to create easily reusable Business Objects, but configurable as
the parameters can still be edited.
Here we set the default to “N” so that only ‘active’ records are
displayed. This can be easily overridden and set to “Y” to allow
all records to be displayed.
|
|
|
|
In the Variable Names tab you are able to view the table columns
and set the ‘variable name’, which is similar to an alias. These
Names may not contain spaces or symbols.
|
|
|
|
These variable names are used when binding a field or grid
column to a Business Object instance.
|
|
|
|
Oddly, however, the table column names are employed when
using the Business Object for options in a dropdown or listbox
field. We are sure this is a bug and it should be the variable
name displayed.
|
|
|
|
Finally, we can test the data returned by the query. Note that
this may return no data should a parameter default not be set, or
if set to any variable.
|
|
|
|
For a Table Business Object we have to select a Table from the
list. This effectively excludes views and stored procedures.
|
|
|
|
To build the conditions for this table, you are forced to use the
condition builder as shown. Frankly, we find this approach very
difficult to understand quickly, and thus we only use the table
Business Object type for read-only Business Objects when the
conditions are extremely simple.
In the case of an editable Business Object we are forced to use
it, however. For a ‘child’ table as shown here, only the FolderId
needs to be passed in as a parameter.
|
|
|
|
The default parameter we pass in is, as expected, the FolderId.
This allows us to employ the Business Object on a form without
the need to set the parameter.
|
|
|
|
Note that when we try to Test the Business Object, no records
are returned because of the variable used in the default
parameter.
|
1. Designer User Interface
