This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Inadequate support for JSF component events | ||
---|---|---|---|
Product: | obsolete | Reporter: | Gregory Murphy <gjmurphy> |
Component: | visualweb | Assignee: | Winston Prakash <wjprakash> |
Status: | NEW --- | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | Macintosh | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Gregory Murphy
2007-01-02 21:20:00 UTC
The semantics of binding expressions as used in the so-called "event properties" is different than that of the binding expressions used in tags for event listeners. The event property takes a method binding, and the only requirement is that the bound method conform to the signature of the method defined by the listener for that event (the standard JSF event listener interfaces, ActionListener and ValueChangeListener, define only one method per interface). The standard event listener tags, ActionListenerTag and ValueChangeListenerTag, have a property that binds them to an instance of a class that implements the ActionListener or ValueChangeListener interface, respectively. The default listener tags are not suited to our current event handling strategy, since we support events not by creating a new instance of a class that implements the event listener interface, but rather by injecting a method into the page bean. However, instead of saving the binding to this injected method as a the value of an "event property", we could save it as the value of a property on a special event listener tag. This tag would be made the child of the component tag, and in that it would look just like other event tags like ActionListenerTag of ValueChangeListenerTag. However, this tag would not correspond to a component. Upon evaluation of the JSP, the tag class would create an instance of a listener whose handler method wraps a call to the bound handler method, and add the instance to the component's list of event listeners. The JSP fragment for a button and its action listener might look something like this: <webuijsf:button binding="#{Page1.button1}" id="button1"> <f:actionListenerWrapper method="#{Page1.button1_action}"/> </webuijsf:button> Initially, the wrapper tags could be defined by Visual Web Pack, but we should consider suggesting these as additions for JSF 2.0. If Visual Web Pack were to support events in this way, the Design-Time API could be simplified, as the mechanics needed to associated events with properties would no longer be needed. This would also greatly simplify the annotation processor used for component development. Quite a bit of logic is needed to generate these associations. I was able to use tags and classes already provided by JSF to hook up an event-handling method. The ActionListenerTag and ValueChangeListenerTag can be used to associate their parent tag's component with a property that returns the appropriate action listener. There are also concrete listener classes provided in JSF 1.2, MethodExpressionActionListener and MethodExpressionValueChangeListener, which can be used to wrap a method expression. To handle a button action, in the page bean I added the following: public ActionListener getButton1ActionListener() { MethodExpression methodExpression = this.getApplication().getExpressionFactory().createMethodExpression( FacesContext.getCurrentInstance().getELContext(), "#{Page1.button1_action}", null, new Class[] {ActionEvent.class}); return new MethodExpressionActionListener(methodExpression); } public void button1_action(ActionEvent event) { this.staticText1.setText("Action occurred"); } In the JSP I added: <webuijsf:button binding="#{Page1.button1}" id="button1"> <f:actionListener binding="#{Page1.button1ActionListener}"/> </webuijsf:button> A strategy like this would provide support for the actions defined by JSF, however, it is not readily extensible to other, custom actions. Changing this in to enhancement as it is actually an enhancement, not a defect. Inteterestingly, in Creator 1.0 we had the same strategy as Grgory mentioned about creating Action Listener (hidden inside the folds of constructor). Then for Creaor 2 we moved on to use the simple "action" property, which looked simple for Creator Users. But with power users like NB users for VWP, it makes sense to revert back. |