|
The last section of a Sisendel file allows the definition of
adjusting parameters to fine tune the production of generatable
files for the entity that defines those parameters.
Several levels of adjusting are allowed,
as parameters can refer to features related to:
- Sections;
- Collections within sections;
- Items of collections within sections.
Adjusting parameters can be expressed as numbers - both
integer or floating point - or as character strings in double
quotes ".
The syntax of adjusting parameters is described in the following
tables. Each adjusting parameter must be written on one logical line.
Table 11 - Section adjusting parameter syntax
|
Language item
|
Description
|
Example
|
|
section.
|
Identifier of the section for which the parameter applies
|
UI.
|
|
parameter
|
Parameter identifier
|
make_xml
|
|
= value
|
Value of the parameter, either a number (integer or floating point) or a string surrounded by double quotes "
|
= "true"
|
Table 12 - Collection adjusting parameter syntax
|
Language item
|
Description
|
Example
|
|
section.
|
Identifier of the section for which the parameter applies
|
UI.
|
|
collection.
|
Identifier of the collection for which the parameter applies
|
full_view.
|
|
parameter
|
Parameter identifier
|
width
|
|
= value
|
Value of the parameter, either a number (integer or floating point) or a string surrounded by double quotes "
|
= 300
|
Table 13 - Field adjusting parameter syntax
|
Language item
|
Description
|
Example
|
|
section.
|
Identifier of the section for which the parameter applies
|
LOGIC.
|
|
collection.
|
Identifier of the collection for which the parameter applies
|
class.
|
|
index.
|
Field index of the collection member for which the parameter applies
|
b.
|
|
parameter
|
Parameter identifier
|
implementation
|
|
= value
|
Value of the parameter, either a number (integer or floating point) or a string surrounded by double quotes "
|
= "callCustomer(BY_PHONE)"
|
Adjusting parameters feature a broad applicability range.
For example, a Java[tm] project team using EJBs (Enterprise Java Beans)
for their application may decide by project convention to
define a collection LOGIC.ejb in their entity files,
regardless of the type of
EJB (entity vs. stateful session vs. stateless session vs.
message-driven).
An adjusting parameter such as LOGIC.ejb
may then be set to the actual EJB type, for instance "entity".
This would instruct the Sisendel translator to apply the project
guidelines (or best practices, or patterns) recorded
in the Java[tm] Sisendel molds that are specific for entity EJBs.
In case of change of EJB type for one or more Sisendel entities,
it would then suffice to modify the corresponding adjusting parameters
- for instance setting them to "stateful session" -
and reproduce in a very short time all relevant Java[tm] files,
thus instructing the Sisendel translator to apply the peculiarities
of stateful session EJBs.
Several earlier code examples showed the use and results of
ADJUSTing parameters, in particular
"customer.ef"
and
"person_info.ef"
. The following code fragments and illustration show the relevant parts of
those examples.
Section customer.ADJUST contains both collection and
fields adjusting parameters, described in the following code
example.
|
Code Example 15 - Section customer.ADJUST
|
Line 2 of this code fragment instructs Sisendel to generate
an SQL script that creates a database table according
to collection DB.table.
Lines 3 and 4 contain the implementation of function
fields phone_call and
cell_call, to be included as class methods
code in the generated files that derive from collection
LOGIC.class. By coincidence, the implementation of
the functions can be used for both Java and C++ methods,
as shown below in the resulting code.
|
|
|
Source code - File "cust_adj"
|
1 ----------------------- ADJUST
2 DB.table.create = "true"
3 LOGIC.class.phone_call.code = "callCustomer(BY_PHONE);"
4 LOGIC.class.cell_call.code = "callCustomer(BY_CELL);"
|
|
The adjusting result for section DB is listed below.
The generation of this SQL script has been triggered
by setting ADJUST parameter DB.table.create
to "true".
|
From DB.table.create = "true" to "customer.sql" - File "business/DB/customer.sql"
|
1 --
2 -- This SQL script created by somusar/SoProMach[tm]
3 --
4
5 create table customer (
6 companyname varchar(80) not null,
7 street varchar(80) not null,
8 city varchar(80) not null,
9 state varchar(40) null,
10 zip varchar(20) not null,
11 country varchar(40) not null,
12 website varchar(80) null,
13 contactlastname varchar(40) not null,
14 contactfirstname varchar(40) not null,
15 contactemailaddr varchar(60) not null,
16 contacttelephone varchar(40) null,
17 contactcellphone varchar(40) null,
18 constraint pk_customer primary key (companyname)
19 )
20 ;
21
|
|
The following Java[tm] and C++ code fragments show the adjusting results for
section LOGIC.
|
Java[tm] methods implemented according to LOGIC.class adjusting - File "cust_adj_java"
|
1 /**
2 * Method 'Call cust. by phone'
3 */
4
5 public void phoneCall ()
6 {
7 callCustomer(BY_PHONE);
8 }
9
10 /**
11 * Method 'Call cust. by cell.'
12 */
13
14 public void cellCall ()
15 {
16 callCustomer(BY_CELL);
17 }
|
|
|
C++ methods implemented according to LOGIC.class adjusting - File "cust_adj_c++"
|
1 /*
2 * Method 'Call cust. by phone'
3 */
4
5 void phoneCall ()
6 {
7 callCustomer(BY_PHONE);
8 }
9
10 /*
11 * Method 'Call cust. by cell.'
12 */
13
14 void cellCall ()
15 {
16 callCustomer(BY_CELL);
17 }
|
|
Section person_info.ADJUST contains both collection and
field adjusting parameters.
|
Code Example 16 - Section person_info.ADJUST
|
Line 2 of this code fragment contains the same adjusting
parameter as for customer.DB.table, this time set
to "false".
Lines 3 and 4 contain refinements for the layout of one field
of collection UI.full_view.
|
|
|
Source code - File "pinfo_adj"
|
1 ----------------------- ADJUST
2 DB.table.create = "false"
3 UI.full_view.photo.size = "70x100"
4 UI.full_view.photo.rowspan = "3"
|
|
In this case, no SQL script is generated,
as ADJUST parameter DB.table.create
is set to "false".
The following illustration shows the adjusting results for
section UI: image "Photo" has a reserved space of 70 x 100 pixels
and spans across three rows, as specified by the corresponding
layout adjusting.
Figure 6 - Layout refinements derived from UI.full_view adjusting
[Previous chapter]
[Next chapter]
[Back to top]
|
