• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

My Opinion on JSF Method Binding

 
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

What do you think about this?
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

my 2c
./pope
 
Dushy Inguva
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

./pope
 
Dushy Inguva
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Pope,

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.
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agree with you that dependency brings in a way intrusion... but a method signature cannot be considered an intrusion.

./pope

ps: we got to stop this :roll:
 
reply
    Bookmark Topic Watch Topic
  • New Topic