DataItem socSecNum INT { displayName = "Social Security Number"} end
This documentation uses the term "properties" in a loose sense to refer to all the above variations.
You can set any of these properties in a set-value block, which is described more fully in Set-value blocks. For more information about the properties and values available for a specific part or statement, see the specific property topics for those parts and statements.
If a part is stereotyped, additional properties are available (see Stereotypes), not only for the part but possibly for fields within the part. For more information, see the specific data access or UI technologies for which the stereotype specializes that part.
DataItem IDNumber CHAR(9) { minimumInput = 9, // requires 9 input characters isDecimalDigit = yes, // requires digits column = "SSN" // is related to a column } endThe following statement declares a UI field of type IDNumber, but the statement does not require that the user type digits:
myID IDNumber { isDecimalDigit = no };
In this example, the override does not affect the minimumInput and column properties.
Record TestRecord y int {color = red}; endWhen you declare a variable based on this definition, you can override the value of the color property:
myRec TestRecord {y{color = black}};
You cannot access simple or complex properties at run time. (You may be able to access implicit fields.) For example, when you create variables that are stereotyped for relational database records, the logic that you write cannot retrieve or change the names assigned to the tableNames property, which identifies the database tables that are accessed by the record. Even if you override a property value in a variable declaration, your program logic cannot change the value that you specify at development time.
The lack of runtime access to such property values means that when you assign the content of a variable or use the variable as a parameter, the property value is not transferred along with the content. Similarly, when you pass a record to an EGL function, the parameter receives the field contents, but retains the properties that were assigned at development time. In other words, the function cannot see any overrides the program has made to record properties.
myService ExampleService { @xml { name="HelloWorld", namespace="http://my.website/services"} } ... end
You cannot access either the complex property or its property fields at run time.
myVar1 INT {color = red} = 5; myVar2 INT {color = blue} = 2; myVar1 = myVar2;
After the assignment, myVar1 has a value of 2 and a color of red.
The same thing happens when you pass a variable as an argument to a function. The function receives the value of the variable, but none of its properties.
myDictionary1 Dictionary { caseSensitive=NO }; myDictionary2 Dictionary { caseSensitive=YES }; myDictionary1 = myDictionary2;
After the assignment, myDictionary1 points to the same Dictionary part as myDictionary2, so myDictionary1 is now case sensitive.