The issue here came about when trying to propagate click events from a child table pair tag to its parent facelet page. The table pair contained buttons to move rows between the tables, and to reorder rows on the target table – a typical design pattern used in this case to assign roles and rights to a user. The table pair tag is responsible for all the buttons for this function – move row selection left/right, move all left/right, reorder target row selection up, reorder target row selection down.
My general design in this situation is for the backing bean structure to mirror the objects on the page. There is therefore an overall page bean which has a child table pair bean for the table pair facelet tag, which in turn has 2 child table beans for its subsidiary facelet table tags. Whilst the parent facelet page does not need to know about the above button logic (it just pulls the result rows out of the child beans e.g. when a save is done), it does need to know when the child table pair has caused the page to be dirty, i.e. to have unsaved changes, which comes about when one of the above buttons is clicked.
My ideal solution to this would be to add an additional action listener on the table pair buttons – the main one is handled by the table pair bean, and an additional one on each button calls a single method on the overall page bean to notify that the page has changed. The parent does not need to know which button was clicked or why, but merely to know that a change has occurred. However this idea is scuppered in JSF 1.2 by the fact that a secondary f:actionListener tag on a button does not accept a method binding like the primary actionListener, but takes a fully qualified class name which must implement the ActionListener interface. This is a right pain as it is a class and not even an instance – you cannot tie the event to a particular bean.
My next attempt was to simply inject a parent reference in the TablePair bean in faces-config.xml, however this fails because JSF does not allow cyclic references in faces-config.
My final solution was therefore to pass a value binding for my own ChangeListener interface on the parent bean to the TablePair tag as a parameter, and declare this on each button using f:attribute. The TablePair bean then fetches the bean reference from the attribute when its actionListener is fired and calls the notify method on the reference’s Change Listener implementation. (I could also have used setPropertyActionListener to simplify this but an ICEfaces bug prevented this working – setPropertyActionListener was being called after the actionListener so the latter only ever saw a null value). The following code fragment illustrates what was used to pull the reference out of the attribute (note that this is incomplete and imports etc. are missing) :-
// Calling code
private static final String CHANGE_LISTENER_ATTRIBUTE = "changeListener";
...
ChangeListener changeListener =
JSFUtil.fetchComponentAttribute(actionEvent, CHANGE_LISTENER_ATTRIBUTE);
if (changeListener != null)
changeListener.notify(this);
...
// Utility Class
public class JSFUtil {
public static<F> F fetchComponentAttribute(ActionEvent actionEvent, String attribute) {
UIComponent component = actionEvent.getComponent();
Map<String, Object> attributes = component.getAttributes();
return (F)(attributes.get(attribute));
}
}
When propagating changes like this, it is important that the design does not cause recursive notifications, for example where a change gets passed up from one child to a parent, back down from the parent to all its children, who send it back up and so on. To this end, I therefore distinguish between the following concepts to avoid this happening:-
- Action Notification Events are only propagated upwards from children to parents, and are only raised in respect of external actions, for example when a button click in a child tag causes a change which the parent needs to know about. ActionNotifications are never raised as a result of a property change on a component which could have been initiated by a parent. For clarity, if an external action causes a property change and needs to propagate this upwards, it is the fact that an external action occurred which is being propagated, and not the fact that a property has changed, i.e. in JSF terms it is the result of an action event and not a value change event. This means that whilst such an external action will pass an event up as well as changing a property, if a parent directly changes the same property, no event will be propagated up. A child cannot directly change properties in its parent so it needs this mechanism to tell the parent “something external such as a button or link click has happened in me which you need to be aware of”. Typically this will be because a click action on the child has made the whole page dirty and the parent therefore needs to change component state throughout the page to reflect this (for example to enable the save and discard buttons and disable navigation from the page). As notifications only travel upwards, recursive notifications cannot therefore occur.
- Property Changes are only performed by a component on itself or on its child components. On itself, it can change any of its internal properties. On a child component, it can change any of the publically changeable properties of the child. As stated above, such changes will never give rise to action notification event propagation. However, property changes can certainly propagate downwards as required.
The state determination of a JSF page or a custom component can become complex when a number of components need to be, for example, selectively enabled and disabled depending on various property combinations. If the logic to determine the state is scattered throughout the component’s managed bean, or even worse, is coded in value expressions on a JSF page, it is hard to make sense of the state determination logic, easy to miss logic that is required, and easy to break the state determination when the code is changed. Therefore, I always use a private changeState method on a bean to perform all the state determination and changes. Typically this will involve a ladder of if..else based logic which checks properties on the bean, and then for example sets or clears various enable/disable properties for the JSF components. In State Machine terms, the various properties of the bean are inputs to the changeState method, and the method uses these inputs to determine a new state for the bean, setting various properties for the new state. I am not fussy about the precise implementation of this – in complex cases, it may be worth using a state machine/state table driven approach to determine state, and maintain a ‘current state’ for the bean which is independant of the beans properties, but for most normal cases this is overkill. What is important is to use an implementation which is clear, correct and easy to maintain, and where the mechanism is easy to understand and flows naturally from the state change requirements. This method should be called whenever a change happens to any of the inputs which the method uses to determine state, and therefore will normally be called many times throughout the bean. If AOP is in use, this might be a good candidate for using a pointcut and advice to dynamically insert the calls, for example on various property changes. In typical cases, I end up with a dirty flag on the bean which indicates that something has changed, and the changeState method checks the flag and sets various enable/disable properties as required. It is therefore often worth having an overloaded version of changeState which allows new values of such inputs to be passed in and set, and then the state change logic performed, in a single call.
As mentioned earlier, I specifically do not perform any such logic on a JSF page. The presence of logic in value expressions on a JSF page is a warning bell as it may indicate that either MVC controller logic or worse, business logic has been placed on the page. As an example, my TablePair bean allows the ‘move selected rows to destination’ button to be clicked if any rows have been selected in the source table – otherwise the button is disabled. It would be possible to code an ‘anyRowsSelected’ property on the bean, and call this property directly from the disable attribute on the JSF page. Whilst this is a simple example, I would contend that this effectively places a controller logic decision in the MVC view. The correct way would be for the disable property on the button to directly refer to an enable/disable flag on the bean, and for the changeState method in the bean to call anyRowsSelected as a method, and set the enable/disable flag as required. This removes all evidence of the logic from the view, and also means that if the logic changes, for example if other conditions can occur on the bean which affect the button state, the change is made in the correct place – only in the changeState method on the bean. The JSF page would not need to be touched and has no knowledge of this.
