|
5.7 How to Make an Event Do Things Events are triggered by pressing buttons, activating links or following on from a previous event by moving on to a page with an entry (or menu-entry) event. Unless an error occurs, an event will take the user to the success page, which for a modeled event is where the directional association points to. If there is an error processing the event, the user is returned to the previous page. This is standard functionality. If you need the event to do more you will need to do something. You can access some standard functionality by adding a style. For example using the "create" style will make the event analyse the data entered and validate it against constraints. Event styles are dealt with elsewhere (How to Model a Styled Page with Styled Events). To add bespoke functionality, you will need to access some code. Normally, you should provide a hook for an application programmer. This takes the form of setting the businessMethod property on the event, which will cause the transform to create a local stub method of whatever name you choose, which the programmer can fill in. The programmer can do most things from this type of method, but if the functionality goes past things to do with layout, navigation or data manipulation, in other words if it has real business logic, it is often better to also add a business method to a service. These form common areas of code that the programmer can access from as many places in the presentation layer as required. So you will be giving the programmer two areas to write code, one at the presentation layer where he can prepare data and set up page navigation, and one at the service layer for business logic, which he can call from the presentation layer. It is possible to call a session method directly, but this is not recommended. By setting the bean property to the session object name and the businessMethod to the name of a method on the session object, the event will call the code directly. It will pass in the data from the page in the form of its value object and the method should accept that as a parameter. This is a mechanism used internally within the transform and you should only use it if you're comfortable that you understand the implications. For trivial functionality, it is possible to put a line or two of code in the text field. For a J2EE transform this will need to be written in Java. This may sound simple, but it should only be used for the most basic functionality. It also has the disadvantage of making your model language dependent. For bespoke non-business functionality that you may want to use on several pages, you could consider asking the architect to write you some functionality into the transform which you could access as a styled event. Say you want to have an event that toggles between two different versions of the same page. This is the sort of thing that you might be able to model as a one off, but also might want to use on several page pairs. Top Tip:
Links:
Copyright © 2001-2006 New Technology / enterprise Ltd. | |||||||||||||||||||||