|
|
|
The Model-Driven System Builder
|
|
JeeWiz Architect's Guide
|
|
|
|
Contents >
14. 'Business Object' Reference
|
|
|
14.9 BaseViewField Object
| Superclass | field |
| Subclassed By |
|
| Description | This is the base for the data-view-field, sto-field and ui-view-field.
|
Contained
Lists |
| 1 |
| Name | constraint |
| Type | constraint |
| Description | Constraints for this field.
|
| GenerateAllList | false |
|
| |
| 2 |
| Name | style |
| Type | String |
| Description | You can specify one or more styles to give information to the code generation scripts.
The meaning of the styles is up to the script writer.
The styles can be used as flags by the script calling
$styleList.contains( "styleOfInterest" )
[ Currently, there is no built-in support for style="styleType=value" type semantics.
This would have to be defined by each script writer.
]
Examples of the use of styles:
- characteristics of a web page (e.g. should it be included in one of the menus)
- whether an entity should be automatically mapped to a data-view (the 'maintain' style).
Note that styles and the 'group' property are different concepts, and therefore complimentary.
Many modelling objects - such as data-views and their fields, or business methods - can be put into groups as a hint as to where to render the UI pages.
Typically groups are used to define 'where' to place the meta class, whereas styles indicate how to render the object.
|
| Unique | false |
|
| |
| 3 |
| Name | rolesReadonly |
| Type | String |
| Description | If the principal is not in the roles-allowed or the roles-blocked, they may have
their access limited to read only by being included in a role here.
|
| Unique | false |
|
| |
| 4 |
| Name | rolesAllowed |
| Type | String |
| Description | If no roles are specified all roles are allowed that are not explicitly prohibited,
otherwise only the specified roles are allowed.
|
| Unique | false |
|
| |
| 5 |
| Name | rolesBlocked |
| Type | String |
| Description | Members of these roles are blocked, whether they are granted permission elsewhere or not.
|
| Unique | false |
|
|
| Validation |
The filter-expression is only allowed for fields of type String
|
Inherited
properties |
|
14.9.1 Property 'name'
|
| Overrides | java:namedValue.name |
| Description | The name will become the name of the field in the generated view class.
|
| Type | String |
14.9.2 Property 'type'
|
| Overrides | java:namedValue.type |
| Description | Specifies the type of the field and may be the name of a primitive type (e.g. int) or simple type (like Date).
For STOs and ui-views, the type is specified as required.
For data-views,
the type is specified directly for inbound fields (where the 'related-attribute' and 'relation'
properties are not specified) or derived indirectly from the underlying attribute (where the
'related-attribute' property is specified).
|
| Type | String |
14.9.3 Property 'onLoadExpression'
|
| Description | A simple expression entered by the modeller that calculates a value for the data-view-field after the data has been retrieved from the database.
|
| Type | String |
14.9.4 Property 'onStoreExpression'
|
| Description | A simple expression entered by the modeller that calculates the value for the data-view-field before the data is stored in the database.
|
| Type | String |
14.9.5 Property 'filterExpression'
|
| Description | This property gives an expression to filter incoming string values to be set into the field.
This allows minor pre-processing of values before validation checks are made.
The expression should use a string-valued variable of the same name as the field (or related attribute if the field has no name) and produce a string value that is to be used as the filtered value.
For example, to remove white-space from a string field named 'f' in Java, the filter-expression would be "f.trim()".
This expression is resolved for the language type, so if you are writing dual Java/C#, you could specify "f.${lang.String.trim}()".
This will result in "f.trim()" in Java and "f.Trim()" in C#.
The exact sequence surrounding the use of this field are:
- The 'set' method is called with the unfiltered value with a parameter named after the field.
- The method checks for non-null (and handles null values separately).
- The parameter is filtered, by evaluating the filter-expression.
- Validation checks are applied, using the result from the filter-expression.
- The new value is set into the local property.
If the system has multiple tiers that use this value - for example, it is used both in screens and data-views - the filter expression will be used twice.
This means that the filter-expression itself should return the same value if used on an already-filtered expression.
Expressions that remove extraneous characters - as does the trim() method - meet this requirement;
expressions that reorder or add extra values without checking the format of the existing value will not.
|
| Type | String |
14.9.6 Property 'lookupGroup'
|
| Description | The dataview field can get values from a field in a corresponding search/select page. It
and all other dataview fields with the same lookup group name will be populated on a successful
return from the search/select page. Unlike a relationship lookup, this will not link the
dataview to the dataview backing the search page. This is just a transfer of values from
one screen to another.
|
| Type | String |
14.9.7 Property 'lookupDataView'
|
| Description | The lookup takes place on a search/select page backed by this dataview. This only should
be specified once for the lookup group. If it is specified differently on different lookup
fields of the same lookup group, the result is undefined.
|
| Type | String |
14.9.8 Property 'lookupField'
|
| Description | The field is populated from the specified lookup-field on the lookup dataview
|
| Type | String |
14.9.9 Property 'orderable'
|
| Description | orderable indicates to the UI that this field can be ordered on the value of the field contents (ascending or descending). Note the default value is 'true' - fields are generally orderable
|
| Type | boolean |
| Default | true |
14.9.10 Property 'renderSpecial'
|
| Description | Allows for a runtime callout to impl class code before display.
|
| Type | boolean |
| Default | false |
14.9.11 Property 'htmlInsert'
|
| Description | text to insert in an HTML rendering of the field eg. onclick="javascript: myfunct('myval');"
|
| Type | String |
14.9.12 Property 'default'
|
| Overrides | baseViewField.default |
| Description | Specifies a default value to which the field will be set when created.
This is an expression which should be compatible with the field's 'type', or the generated program will not compile.
For primitive types, this will typically be just the literal value of the default, although it can be an expression.
Note that you should just specify the value part for numeric values, not a type-defining suffix.
For example, you must specify "0" rather that "0L".
For non-string objects, the default should create an object - e.g. 'new Integer(8)'.
String defaults are assumed to be string literals less the surrounding "".
They will have double-quotes added automatically, so the default is a String constant - e.g. Fred goes into the code as "Fred".
You can alter this action, to specify expressions for string defaults, by prefixing the expression with '\', which will be stripped off.
You can also start and end the default string value with '"', in which case it will not be altered.
String examples:
input: Fred
code: "Fred"
input: \otherfield.substring(1)
code: otherfield.substring(1)
input: \""
code: ""
The default expression as processed by the above algorithm can be retrieved via the method getDefaultExpression().
|
| Type | String |
14.9.13 Property 'group'
|
| Description | A group is a hint to generation scripts as to where to place this object.
It provides an alternative, more flexbile way of grouping business-methods, objects, data-views and pages.
For example, pages for data-maintenance might be in the "DataMaintenance" group,
while specially-designed sessions might be in the "BusinessFunctions" group.
(Expressing this grouping cannot be derived from the hierarchy: all pages are children of a single application.)
Another usage could be to group fields for presentation based on their group name.
The 'group' property should be used to guide presentation to the user, whereas 'style' should be used to guide further pattern generation.
The 'default' group is the null value (script writers must use '#if( !$group )' to identify the default group.
|
| Type | String |
14.9.14 Property 'readable'
|
| Overrides | baseViewField.readable |
| Description | Defines whether a public 'getter' method will be generated to get the value.
|
| Type | boolean |
| Default | true |
14.9.15 Property 'required'
|
| Description | This determines whether a value needs to be input into this field.
This field applies to strings (text fields), dates and references to other objects.
It does not apply to numbers or money (currency) or other primitive data types.
|
| Type | boolean |
| Default | false |
14.9.16 Property 'writeable'
|
| Overrides | baseViewField.writeable |
| Description | Defines whether a public 'setter' method will be generated to set the attribute.
|
| Type | boolean |
| Default | true |
14.9.17 Property 'convertEmptyStringsToNull'
|
| Description | This delegated property when set causes empty values, on input (e.g. on screens) into optional fields, to be converted to null.
This property is present on the attribute or data-view-field and their parents.
This property has no effect on required values.
By default, this property is set (in the Business Object Model's system.properties).
If this value is not set, there is no way to express 'no value' on input screens.
|
| Type | boolean |
| Delegates | true |
14.9.18 Property 'dontDisplay'
|
| Description | Set this property to prevent the field appearing on a page.
By default this value is false - so the field will appear on the page.
However, the standard patterns set this value true if the type is not displayable.
|
| Type | boolean |
14.9.19 Property 'externalName'
|
| Description | This is the basis for the external name used for the field.
For example, users may think of 'Order Number', whereas the field itself is ord_num (following local variable naming conventions possibly).
For input fields (i.e. one with no related attribute) the external-name defaults to the name (with spaces and capitals added to separate words).
For fields with a related attribute, the external-name defaults to
- the data-view's name if there is one, otherwise to
- the related-attribute's external-name if there is one, otherwise to
- the related-attribute's name.
This can be further mapped to the actual name presented by particular interfaces. This can be done automatically in the component.properties file for the data-view-field.
For example, variants of the name are available through helper methods - getExternal[XML/JavaClass/CapsAndSpaces]Name formats, which may be useful in XML or screen representations of the name.
|
| Type | String |
14.9.20 Property 'summaryName'
|
| Description | A field holding a short name used in grid headers, etc
|
| Type | String |
14.9.21 Property 'useOnSummary'
|
| Description | Use-on-summary tells the standard patterns whether to use this view field on a summary list.
A summary list is shown when the view is the subject of a search (e.g. find all orders for a particular customer) which returns multiple rows.
Rather than bring back all information in an entity or data-view, the summary (based on the summary fields/attributes) is displayed.
The group of all summary fields should be distinctive enough to allow the user to identify a particular record.
There is a related 'use-on-summary' property on the entity's attribute; the relationship between these two is described below.
The standard patterns construct the 'summary' of a view automatically, using the first of the following approaches that succeed:
- One or more fields on the view are explicitly marked 'use-on-summary'.
In this case, the summary is the list of all such fields.
- Failing that, for data-views, the data-view-field may have a related-attribute on the initial entity that is explicitly marked as 'use-on-summary'.
If there are any such data-view-fields, the summary is the list of all such fields.
- Failing that, for data-views, the data-view-field may have a related-attribute on the initial entity that is part of the primary key for the entity.
If there are any such data-view-fields, the summary is the list of all such fields.
- Finally, when all else fails, all fields on the data-view are used. This may result in an interesting rendering!
|
| Type | boolean |
| Default | false |
14.9.22 Property 'useOnSearch'
|
| Description | Use-on-search tells the patterns whether to use this field on a search screen.
|
| Type | boolean |
| Default | false |
14.9.23 Property 'textEvent'
|
| Description | If an event is entered here, when the summary text is printed in a gridline, it will form a URL that fires the event.
|
| Type | String |
14.9.24 Property 'screenPosition'
|
| Description | A numeric value indicating the position of this page or control within a group. This affects the position of the item's display on the screen, relative to other members of the group. The value is a string of 1-6 digits; the order is calculated numerically rather than alphabetically - so 25 is higher than 5. Lower-valued positions appear first. The value of '-1' indicates that the this field should not placed on the ScreenPositionList (determined by the DataView). This would be used when the specific renderer would want to handle the placing of the field rather than via the automatic rendering which is based on the ScreenPositionList. If this is not specified, then the order of controls within a group is determined by the order in the XML specification file. The order within the specification can be set if the XML is being specified directly and this field need not be specified. However, for specifications from UML design tools this may not be possible and it will be necessary to set this field to control screen order.
|
| Type | String |
14.9.25 Property 'uiControl'
|
| Description | Specifies the ui control to use for this field. If specified, this field must correctly name a UI control - see your local standards for a complete list.
The standard JeeWiz options are:
TBD
If there is no value for the ui-control property, a suitable UI control for the type will be chosen.
See also ui-style, which can guide the selection process if ui-control is not specified.
|
| Type | String |
14.9.26 Property 'format'
|
| Description | The format works together with the display style at the presentation layer. It might override the date format for
a textbox date or numeric, or it might override the height and width of a textarea. It is up to the UiControl
as to how, or whether this property is processed.
|
| Type | String |
Copyright (c) 2001-2008 New Technology/enterprise Ltd.
| |
