my dog learned polymorphism*
The moose likes JSF and the fly likes JSF and AJAX are just opposite Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "JSF and AJAX are just opposite" Watch "JSF and AJAX are just opposite" New topic
Author

JSF and AJAX are just opposite

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
One (JSF) is evolved to eliminate JS and other uses JS extensively.

Right?
[ May 31, 2006: Message edited by: rathi ji ]
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
How did you come to the conlusion that "JSF is evolved to eliminate JS"? Plenty of JSF components (see Tomahawk for example) generate heaps of JavaScript. The nice thing is that a web app developer can let the JSF implementation worry about most (but not all ) of the JS details. Nothing stops a JSF component from being implemented using AJAX.


There is no emoticon for what I am feeling!
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by Jeff Albertson:
How did you come to the conlusion that "JSF is evolved to eliminate JS"? Plenty of JSF components (see Tomahawk for example) generate heaps of JavaScript. The nice thing is that a web app developer can let the JSF implementation worry about most (but not all ) of the JS details. Nothing stops a JSF component from being implemented using AJAX.


I thought, JSF handle validation and conversion nicely (that usually done through JS) so...

:roll:
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Originally posted by rathi ji:


I thought, JSF handle validation and conversion nicely (that usually done through JS) so...

:roll:


Nothing stops you from mixing client-side validation into JSF. Iin any case, one need server-side validation because the client could be turning off JavaScript. Conversion, by definition, is done on the server side -- HTTP posts strings to you, not numbers and dates, for example!
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by Jeff Albertson:


Nothing stops you from mixing client-side validation into JSF. Iin any case, one need server-side validation because the client could be turning off JavaScript. Conversion, by definition, is done on the server side -- HTTP posts strings to you, not numbers and dates, for example!


Thanks Jeff for nice explaination.

Dave Boyd
Greenhorn

Joined: May 29, 2006
Posts: 10
if you ever wanted to check out the source that JSF procedures you may be shocked just how much javascript is used

just look at the command components for example
Sergey Smirnov
Ranch Hand

Joined: May 29, 2003
Posts: 167

Nothing stops you from mixing client-side validation into JSF. Iin any case, one need server-side validation because the client could be turning off JavaScript. Conversion, by definition, is done on the server side -- HTTP posts strings to you, not numbers and dates, for example!


I agree about "nothing stops...", but cannot see the special reason why the code of the validators should be duplicated. Having the javascript based validators was the only one choice in pre-AJAX era, because the server-side code was just unacceptable. In case of AJAX you have a chance to reuse the same code.

--
Sergey : https://ajax4jsf.dev.java.net
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSF and AJAX are just opposite
 
Similar Threads
Safari - TypeError on first submit
JSF... My post-JavaOne impressions.
Is it possible to make temporary .properties files that last the session?
Grid in web application
<hx:datatable using javascript to set a selected rows background color