Archive for 2E Beginner

Use Domain Fields for Maintainable Applications

Developing maintainable 2E applications takes thought before writing any action diagram code or even before creating fields.  One of the great features of Synon is the ability to create fields by referencing other fields.  Once a field is referenced, all fields that reference the base field take on the attributes of the base field.  The concept is easy.  Let’s see how using this concept can help make more maintainable applications.

 How to use Domain fields effectively:

  • Plan ahead and create many of the domain fields.
  • Use a specific identifier for the domain fields.
  • If you create a file and a domain field does not exist for the new field, create the new domain field first.
  • Make sure all developers follow the standards.

It is important to plan ahead when using referenced fields as domain fields.  The benefits you receive for this planning will last for years if properly maintained. A great benefit is that if you ever move your model to Web Option, you can point a style to a domain field and all of the fields that reference the domain field will pick up the HTML styles of the domain field.  Within your model, you can also make mass changes. Any changes to your domain fields will change all the fields that reference it. This is quite powerful.

One of the important items to plan out is the way you will identify the domain fields.  Some show use a *, other use D) while others might use a D_.  It is good to have the identifier as the first few characters of the field.  Then, the name of the field needs to let the developer know what the field is, without having to look at the field properties (ie. D_Text_25).  It is very important to pick a standard and stick with it. 

Besides the a naming standard, you should create a handful of the primary fields your system will use. Typically, this responsibility will be left with the DBA. If you have one person in your company that does this, the job is much easier.  The DBA will also be responsible to create domain fields that do not exist for new database fields.  Stick to the plan any time a database field is created it MUST reference a domain field.

If each developer has the ability to act as a DBA, then standards need to be enforced even more strictly.  Any time a new database field is created, it MUST reference a domain field. 

Many existing models have not followed the practice of using domain fields.  Is it worth fixing this?  In most cases, not if you have a large model. The job would be too large for the benefits.  If you have a fairly small model, then it may be worth creating a plan to update the fields as projects are completed.

Even though it takes planning, up front work and discipline to use Domain fields, years down the road you will either be glad you maintained the practice or you will regret not following the standards.  The benefits will outweigh the struggle to maintain the standards.

CA 2E / Synon Interview Series: Question 6

The understanding of parameter context is a very important area in building 2E functions.  Explain the difference in passing parameters by FLD, RCD or KEY contexts. 

Interview Question 5 Answer

List 2 numeric and 3 alphanumeric field types.

[table "3" not found /]

CA 2E / Synon Interview Series: Question 5

List 2 numeric and 3 alphanumeric field types.

2E Tip – Add and Remove a Function Field

I will be adding some basic navigation tips so someone new to 2E can learn how to do some of the simple tasks. One of the biggest challenges facing a person just starting in 2E is the learn the navigation.  As time passes, the fingers will do the walking and you will hardly have to think about how to do this basic tasks, but it is a daunting task right out of the “horse race” gate.

Today we will look at how to add and remove a function field from the device design. A function field is a field that is part of the model but it is not necessarily part of a file.  In the early days of 2E we had to create specific fields that were not related to a file at all.  Now we are able to choose fields that are attributes or keys on the file but they cannot exist on the current file the device design is built over.  If they were on the device design file, they would already exist on the screen because they are part of the access path.

Step 1 – Navigate to the Device Design.

a.  F into the file were your function exists.
b.  S into the function to modify.

Step 2 – Add a Field  to the Device Design.

a. Place your courser on the field before the location to add the function field.
b. Press F19
c. If you know the name of the field you can add it on the Edit Device Function Field screen.  Otherwise place a ? to prompt for fields.
d. Position to the field you want to add and select it with an X.
Note: If you do not find a field you want you can create a function field at this time by pressing F10 and defining the field.
e. Adjust the field attributes to look correct on the screen.

Step 3. Delete a Field from the Device Design.

a. Place you courser on the field to be deleted.
b. Press F20.
c. Press F11 to delete the field entry from the screen.  This only applies to device function fields.

 
 
© 2013 CM First Group - All rights reserved