Introduction to properties

Properties set specific options for parts. In general, you specify the properties when you create the part and then the properties are static. In certain circumstances, however, it is possible to change a property dynamically.

The available properties are different for each part and for each stereotype, so when creating a part, check to see what properties are appropriate. Some parts have required properties, but most properties are optional.

The most common type of property is a simple property, a name-value pair that sets an option for the part. Most parts can accept one or more simple properties by listing the name of the property and the value for the property within braces ( { } ) at the beginning of the part definition. If you specify more than one property for the part, separate the name-value pairs with commas:
DataItem cost money(10,2) 
    {Currency = yes,
     CurrencySymbol = "$"}
end
The code block that begins with the opening brace and ends with the closing brace (that is, the list of properties and their values) is referred to as a set-values block.

Properties are useful only in specific situations. For example, DataItem parts can include properties that apply only to specific types of user interfaces. As in the previous example, you can specify the properties currency and currencySymbol on any DataItem part to indicate that the DataItem represents a currency value and to specify the monetary symbol used in displaying the value. From the topic "currencySymbol" in the EGL Language Reference, you can see that this property has an effect when used on a web page, but not in a Console User Interface application.

Property values

You must provide a valid value for each property. Some properties accept string literals, some accept a "yes" or "no" value, some accept values from lists of options called enumerations, and others accept array literals. In most cases, you cannot use a variable or constant as the value of a property. In other words, you cannot use a boolean variable or a string variable set to "yes" or "no" for the value of the currency property; you must specify a literal, unquoted "yes" or "no" value.

However, a few properties require that you supply the name of a variable or part as a value. In this case, the property is not using the value of the variable or part; it is referring to the variable or part itself. For example, the JSF Handler part accepts the onPreRenderFunction property. This property specifies a function within the handler that runs automatically each time the handler runs. In this case, you might write the handler as follows:
handler myPage type JSFHandler
    {onPreRenderFunction = refreshFunction}

    function refreshFunction()
    end

end
In this example, the onPreRenderFunction is set to the name of the function refreshFunction. The handler must have a function with this name or EGL will throw a validation error.

Some properties are provided for compatibility with previous versions or migrated code and are unnecessary for new EGL applications. To know which properties are provided for new code and which are used for compatibility, see the EGL Language Reference topic that covers a particular part and its properties.

Inheriting and overriding properties

When you create a part based on another part, the new part inherits the properties of the old part:
DataItem myRedVar int {color = red} end

Record myRedRecord type BasicRecord
    myField myRedVar;
end
In this case, the field myField behaves as though you had specified the color property on it.
However, properties do not transfer between most variables, as in this example:
myRedInt int {color = red};
myBlueInt int {color = blue};
myBlueInt = myRedInt;
In this case, myBlueInt still has the color property set to blue.

Reference variables are an exception to property transfers. See "Properties" in the EGL Language Reference.

You can explicitly override properties, as in the following example:
DataItem myRedVar int {color = red} end

Record myBlueRecord type BasicRecord
    myField myRedVar {color = blue};
end
In this case, the field myField overrides the red value with the blue value.
In this way, it is legal but not recommended to define a property twice for one part or variable. The last property specification sets the value, as in this example:
myBlueVar int {color = red, color = blue};
In this case, the variable's color property is set to blue because the second definition overrides the first.

Feedback