In JSF, we can specify the method to be executed when an event occurs. (Very similar to a observer-observable) But, there are no interfaces to implement. You just give the method name in the xml file (faces-config.xml) and make sure the method has a particular set of parameters.
Thats like using function pointers. In my opinion, a better way of doing it would have been what Swing does. With event listeners. (There ARE event listers in JSF) just that method binding is not architected like one. More details: Page 5-6 Section 5-2 of the JSF Specification 1.0
Maybe this solution was chosen in order not to become intrusive. What I mean is: if I do not have to implement any interface (as it is required in an event handling mechanism) and I am able to bind any method than my code remains absolutely unlinked to the JSF.
If "un-intrusiveness" was the factor, I'm not sure if they totally achieved it. 1. Some of the methods have to return a string which decides how the navigation will be performed. (This is a contract between the bean developer and the framework and hence is a lockin). 2. It is not that our methods can have whatever signature we like. Some methods need to accept a list of JSF specific parameters, which very much binds us to the framework. The only "wriggle room" we get is the name of the method, which can be anything. 3. To indicate an exception, we need to throw a sub class of a runtime FacesException(i don't have anything against runtime exceptions, i think thats really not the focus of this discussion). But, what i want to point to is, we already will be using JSF specific exception hierarchy. 4. In anycase, if we have to be framework independent, a layer can be provided by the application developers (or any other framework that builds over JSF). Struts achieves the same by urging developers not to code business rules in action classes.
I do not say that an application needs/doesnot need to be JSF application independent. Thats the decision of the architect. In anycase, not using interfaces to achieve the contract between JSF and the application would not alter that decision in any manner.
I'm not totally sure that not using interfaces for this reason is a valid argument. They do provide compile time type checking and a clean and object oriented way of method invocation (virtual functions). Whereas, the approach taken relies on "function pointers".
I understand that JSF is supposed to be "tooled", and the tools will/need to provide compile time checking, but giving up on object oriented ness to depend on a tool does not convince me enough. It also becomes difficult to use existing code checkers or other optimizers etc on code which lacks compile time type checking. [ October 26, 2004: Message edited by: Dushy Inguva ]
Joined: Jul 12, 2004
Even if I totally agree with you that imposing the signature is not very non-intrusive, you must not missunderstand the difference between contracts and intrusive.
Joined: Jun 24, 2003
I don't know if my understanding is wrong, and I don't mean to be rude, but I think a contract by itself does impose an amount of 'dependence' which brings in intrusive-ness.
That is why, we usually use an extra "mapping/shielding" layer to prevent a framework lockin. Please feel free to correct me.
Joined: Jul 12, 2004
Agree with you that dependency brings in a way intrusion... but a method signature cannot be considered an intrusion.