How can you say for JSF there is no need to know any scripts.?

[hanumantha prem]

JSF is here to simplify life for application developers, making it possible for them to focus on the view without needing to know the
underlying markup or scripts.


I massively use scripts for onclick,onchange etc,etc javascript actions.
can somebody help me understanding this?

[Tim Holloway]

Core JSF doesn't do scripts, so you'd code your own in the usual way, allowing for the peculiar way that JSF pages get rendered. However, frameworks such as IceFaces and RichFaces contain tags that have built-in AJAX support. These are very intelligent tags that can do things like support tabs, expand/shrink windowpanes menus and tree views, do partial page updates and other useful stuff. The taglibraries themselves often generate all the JavaScript code that's needed, including adaptations for whichever web browser the client is using.

So you can get a lot done with no javascript code when using these tags.

Of course, if you want to do something that these AJAX tags can't do, you'd still need to know how to write your own scripts. But the need for scripts is greatly reduced or eliminated.

[Cameron Wallace McKenzie]

Certainly, JSF provides various actionListeners that allow you respond to certain events, like list items being selected, but indeed, these rarely provide the level of interactivity that the famed "Web 2.0" user interface demands. As was stated, JSF has been eagerly extended by frameworks like RichFaces, but until everyone converts to GWT, there really is a need to know how to write some solid scripts.

-Cameron McKenzie

[Tim Holloway]

Cameron Wallace McKenzie wrote:Certainly, JSF provides various actionListeners that allow you respond to certain events, like list items being selected, but indeed, these rarely provide the level of interactivity that the famed "Web 2.0" user interface demands. As was stated, JSF has been eagerly extended by frameworks like RichFaces, but until everyone converts to GWT, there really is a need to know how to write some solid scripts.

-Cameron McKenzie

You might be surprised. I've got 2 major websites that use RichFaces and just about the only JavaScript in them are popups of the "Are you sure you want to delete this?" flavor. Which [i]could[/b] be made into a custom JSF tag (h:confirmButton, anyone?), but so far I don't think anyone has. Maybe something to do this afternoon.

No, I lied. One of them has Google Maps on them. I did a custom JSF tag that allows you to write Google Maps API client code as a separate javascript file and bind it to the map JSF tag so there wouldn't be long ugly sequences of JavaScript code embedded in the JSF page.

Not to disparage GWT, but I haven't found a compelling need for it in my JSF apps.

[Cameron Wallace McKenzie]

about the only JavaScript in them are popups

And to think, I had so much respect for you, right up until you confessed that you're littering your applications with Pop-Ups!

Indeed, I think your point is well made. The GWT comment was more a sarcastic jab that anything (as is the above comment about your pop-ups). GWT really is the extreme end of the spectrum. I think JSF really provides a nice and happy medium between GWT and just ordinary Servlets and JSPs, especially when it's used properly and with a good understanding of the JSF lifecycle.

Ok, I better stop before this thread gets completely hijacked.

-Cameron McKenzie

[Tim Holloway]

Maybe I should have used the term "Confirmation Dialog". If you're referring to popping up browser windows, rest assured I don't hate people that much.

I did do a "pop-over" modal dialog the other day using RichFaces ModalDialog, though. It overlays part of its parent window, but doesn't open a new frame. If your REALLY want to, you can talk to it in JavaScript to open and close it, but for many purposes even that's a JavaScript-free operation.

[hanumantha prem]

Dear Cameron Wallace and Tim,
I am very new to JSF and don't have idea about web 2.0.as per as i understood,onclick,onsubmit all these actions can be handled at the server side.but there is a difference between server side event handling and client side event handling.I feel its bad idea to hit the server for every actions that can be handled by java Script(More load on server).and also you use document.form.submit() for these actions ,which is a javascript.What do you say?

[Tim Holloway]

Well, basic JSF doesn't use JavaScript at all, even for forms submission. Some of the AJAX extensions do their own forms submits, though. You don't code them yourself in that case, since the tag renderer does it for you.

There are 2 good reasons to do stuff client-side: 1) it takes some of the load off the server and 2) it generally gives faster reponse to the user. On the down side, you have less control over the execution environment when you execute client-side. In JavaScript, one of the things this means is having to tailor the JavaScript for a number of different web browsers/versions. Which can mean a lot of grunt work.

There's yet one more factor to consider. JavaScript can be turned off by the user (and for that matter, not all browsers support JavaScript). I seem to recall a time or two when Microsoft and/or Mozilla strongly recommended doing so to bypass serious browser security problems. And some people are just plain paranoid. So a truly well-written webapp shouldn't be break if JavaScript doesn't run. Additionally, to avoid hacking, you may want to double up on data validation - Client-side for responsiveness, Server-side for security.

JSF AJAX tags are great for this kind of stuff. The ideal AJAX JSF tag will sense the browser and javascript flavor, send out only the minimal amount of code needed to support it (instead of a humongous runs-for-all package) and will revert to server-only operation when JavaScript isn't available on the client all without effort on the programmer's part. So far, I haven't had the courage to try this last ability on my own apps, though and I don't know if RichFaces makes the attempt.

[hanumantha prem]

Thank you Tim for your response.