|
|
|
The Model-Driven System Builder
|
|
JeeWiz Architect's Guide
|
|
|
|
Contents >
14. 'Business Object' Reference
|
|
|
14.13 BusinessMethod Object
| Superclass | method |
| Description | Defines an operation (a business method) in the business object model.
This will be exposed outside the business object. (The exact means by which this is done is not tied down in the business object model. It could be done by the the templates e.g. by including on a business interface - currently not implemented. It could also be done by a derived model, e.g. the J2EE, where business methods are included on the local EJB interfaces, and on the remote interface if requested.)
Business methods are by definition public.
In the J2EE model:
- instance methods are defined on the local and optionally remote interfaces.
- static methods are defined on the localHome and optionally Home interfaces.
Note that the 'text' of the object (the character in the XML format) may be used to specify the Java code to implement the business method.
The business method may potentially be exposed across different boundaries.
Currently, the two boundaries are
- the RMI boundary, which is used by web applications and EJB clients. This is the default
- the web service boundary. To specify this, a tag of 'template=ws-operation' must be specified.
If the template tagged value is not available, this can be specified by
giving the value "template=ws-operation".
To specify parameters, a business method on a business object may have
- a list of parameters, or
- a reference to an 'input-data-view' object
(but not both).
The reference to the 'input-data-view' object is used to automatically add a second parameter to the
business method, giving the changes that should be applied to the data-view and its related data-views.
This technique should not be used for web service operations, partly because the web service operation
is strictly defined (and adding the changes class would break the service contract) but also
because the changes object does not marshal across web services (because it may contain a HashMap).
The list of parameters explicitly specifies the parameters.
To specify the result, a business method may have
- a result type, which explicitly names the result type
- the result-data-view. This is mapped into the value object for the named data view.
With modeling tools that allow a typed name, a single parameter with a typed class reference is preferable.
|
Contained
Lists |
| 1 |
|
| |
| 2 |
|
| |
| 3 |
|
| |
| 4 |
| 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 |
|
| |
| 5 |
| 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 |
|
| |
| 6 |
| Name | rolesBlocked |
| Type | String |
| Description | Members of these roles are blocked, whether they are granted permission elsewhere or not.
|
| Unique | false |
|
|
| Validation |
1.
You can only specify the input-data-view or a list of parameters, but not both
2.
You can only specify the result-data-view object or a return type, but not both
|
Inherited
properties |
|
14.13.1 Property 'remote'
|
| Description | Indicates that the business method is to be put onto the remote interface (for instance methods, or onto the remote home interface for static methods).
(All *business* methods and creators (as opposed to non-business methods) in the J2EE model are put onto the local interface, regardless of the setting of 'remote'.)
On session objects (but not on other business objects), the remote flag is set by the standard patterns to be true if it is not set. For other objects, the default of 'false' is preserved if the remote flag is not explicitly set.
|
| Type | boolean |
| Default | false |
14.13.2 Property 'isBusinessMethod'
|
| Description | A hidden property which indicates that the method in question is indeed a business method.
Current usage is in the logging in the \base\VM_global_library.vm where we want to determine whether we are dealing
with a business method. This property means that there is no need to seach lists."
|
| Type | boolean |
| Default | true |
| Hidden | true |
14.13.3 Property 'inputDataView'
|
| Description | The name of the data view from which the input information for the method should come.
In other words, setting this property will result in a parameter list consisting of one parameter whose type is the value object for the specified data view.
This data view should contain all the information for the method, so no explicit parameters should be defined.
|
| Type | String |
14.13.4 Property 'resultDataView'
|
| Description | The name of the data view from which the result information will come.
The actual return type of the method will be the value object for the specified data view.
If the result-data-view is specified, the return-type should not be.
|
| Type | String |
14.13.5 Property 'generateTest'
|
| Description | This will generate test pages, if the session is similarly flagged. It assumes that the methods take one parameter as input, deliver one return type, and optionally expose one Exception.
The parameter, return type and exception can be info objects of views.
|
| Type | boolean |
| Default | false |
14.13.6 Property 'access'
|
| Overrides | java:method.access |
| Description | In the business model, business object/methods and attributes are by definition public - they are designed for access by clients outside the object. Therefore the 'access' value is fixed at 'public'.
This factor hides the 'access' property from users.
However, the attribute can be set programmatically (i.e. in some patterns access is set to private) so that it will be rendered via normal field generators according to the architect's design.
|
| Type | String |
| Default | public |
| Hidden | true |
14.13.7 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.13.8 Property 'userNameBase'
|
| Description | This is the user-visible name for this object (currently it is used on business objects, business-methods and data-views.
In the standard rendering, this is further embellished in component.properties to create the userName, which the user will actually see.
For example, say the name of a session object is AccountTransaction.
Then the default for the user-name-base will be 'Account Transaction'.
This will be embellished in component.properties to give the userName 'Account Transactions'.
Either the userNameBase or the userName can then be used in scripts.
|
| Type | String |
Copyright (c) 2001-2008 New Technology/enterprise Ltd.
| |
