Summary
The field is our single data element in Studio, it is named when mapping screens and throughout our definitions and code is treated as a String datatype. While of a simple datatype, fields can be treated differently, and have significant impact on how our applications are generated based on the properties set.
Any Flynet Studio Field with a specific name should have the same length as other field's with the same name, and there are many features in Studio to help you identify the correct name and/or length for a field you are mapping on a screen.
Note that when two fields have the same name, they are in-fact different fields in Studio, but will become defined in generated code as the same field when the lengths are identical. When two fields have the same name but different lengths, the first one defined in the definition will be generated with the same name you see in Studio, while any subsequent fields are generated with the field name concatenated with the container FieldMap's qualified name.
Roles
| Host | Fields can be protected (labels) or unprotected (entry fields). When entry-capable (unprotected), a field can be simple data to be stored in a database when updated, or can have navigation impact. A field having navigation impact might be a customer number, entered on the first screen in a sequence, and displaying the details for that customer in following screens. In this instance, we have a property set on the field giving it a NavigationUse of keyVariable. |
| UI | Depending on the activity being represented in your user interface, a field may be hidden through filtering, or if displayed, set with a different entry characteristic (making an unprotected field protected, for example). The biggest impact on the user interface of a field is the FieldTemplate you set for the field. The best example of this is setting the FieldTemplate of a date entry field to the DateEntry template, which presents an entry field with a clickable calendar control to the user. Click here for more details on datafield support in Studio. |
This completes the major section, Guide to Application Roles and Behaviors
Click to view the next section, Design Guide: ASP.NET Features
