Application Scripting and Event handling

1. Application Scripting and Event handling DucHM August 22, 2006

2. Agenda • Key Functionality • Default Behavior • Script class and Script inheritance • Structure of Events handling script class • Form and Script relation • Event handling • Terminating Action events from notification handlers • Validation Events • Inter-Form communication

3. Default behavior • A form can be defined in a hierarchy of visually inherited classes. Thus, an event handler (for a control) could be registered both in the derived form as well as in its base form. The event handler code in the parent form or in the ancestor form will be referred to as “default behavior”. • The event handlers can be thought of as “pre-execute” handlers. The event handler of the User Form gets called first. This event handler can, if desired, invoke “default-behavior” of the parent Vendor Form by using the Java super mechanism. To over-ride “default-behavior”, the User Form will call super() first and then over-ride the code as desired in the handler. All this is the step 1 as shown below. Step 2 is the execution of action meta-data. Finally, step 3 is the calling of post-click handler if required. The post-click handlers can also invoke “default-behavior” of the parent post-click handler by using super().The figure below shows the flow of events.

4. Default behavior (continue)

5. Script class and Script inheritance • The solution envisaged is to separate the event handling script from the form definition. The event handler script will be in a separate java class. This event handler script class should derive from an Amdocs defined base class – UIScriptBase. The UIScriptBase class will provide a host of services such as methods to initialize form instance variables with the actual references. • Just as to customize a form we visually inherit a new form class from the parent form, to customize a script handler we will need to inherit a new script handler class from the parent form’s script handler class, as shown in the figure below.

6. Script class and Script inheritance (continue)

7. Structure of Event handling script class • The event handling script class will contain the following blocks of code. 1. Methods for handling events. 2. IDE generated code to declare and initialize form instance variables. 3. Anything else that the user may require.

8. Structure of Event handling script class (continue) • An event handler method is associated to the event source (ex: a button) using a naming convention as follows – on<Event-Source-Id>_<Event-Id>, where <Event-Id> is the name of the event (ex- click>. For example – The “click” event handler for a Button with an id “MyButton” will have the following signature

9. Structure of Event handling script class (continue)

10. Structure of Event handling script class (continue)

11. Form and Script relation

12. Event Handling • The platform-specific events (Swing events) on the form and its controls are mapped to an Amdocs defined platform-neutral Event structure.

13. Termination Action events from the notification handlers Some actions will generate a chain of related notification events. For example, the Save action might generate the following notification events during the processing of the Save action • Validate event – can throw a AbortException • PreSave event – This event will be fired as soon as the ‘Save’ action is fired. Applications can trap this event to validate the data that is being saved. • PostSave event – This event will be fired when the Save operation is complete.

14. Inter-Form comunication • Parent form sending a message to one or more of its child forms. • A child form sending a message to its parent form. • A form1 sending a message to another form2. • A form broadcasting a message to all the open forms with a unique identity. A particular dataset item in the data model associated with the form identifies the uniqueness of a form. • A form broadcasting a message to all the open forms.

15. Script class handle messages • The code will have a message handler per message id. The signature of the message can be onMessage_<MsgId>(…) . For example, if the script wants to process a message with Id = “Hello”, then there can be a method by name onMessage_Hello( … ) to handle the message. If this method is not defined in the script, it would imply that the script does not want to process the message. • The implicit linking of event handler names to their method signatures can result in a clash in the handler method names. For example, if a button has a unique id “Message” and a Message id is named as “Click”, the signature onMessage_Click(…) will have two events (button click and message “click”) associated with it. We will need a naming convention to avoid such clashes. That can be part of detailed design.