GUI action design pattern

The sample app(CRUDView) class is not so clean with respect to the implementation of how mouse action would trigger window state changes, like some button are disabled and the others are enabled etc.

Each component class should not have to know anything except what they suppose to do, i.e, some state change.

All the GUI action should be understood as state transition.
 if we append listener to each node's listener, that is still bad.

the controlling logic is tightly associated with specific GUI action.
But what the mouse action will change is the state and that state change is the reason for the logic of GUI change.

so the logic should be centered around the state change.

for instance, following code may describe the state transition of each mouse click for the buttons.

state('a1')..>state('a2')['load'] = load
    ..>state('s3')['save'] = save;

state('a2')..>state('a2')['clear'] = clear
    ..>state('s3')['edit'] = edit;

That way, we see the real logic behind the GUI action. often such a  state is not explicitly expressed in the application code as in the current CRUDView code. and action methods are called from many places associated with buttons.
That messy way should be avoided.