aspose file tools*
The moose likes JSF and the fly likes onblur event hijacks my onclick! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "onblur event hijacks my onclick!" Watch "onblur event hijacks my onclick!" New topic
Author

onblur event hijacks my onclick!

Dan Webber
Greenhorn

Joined: Mar 31, 2011
Posts: 5
Hello,

I am having a bit of an issue with onblur/onclick events in my JSF (RichFaces) application. I have summarised the code below:



So basically, when the value of inputvalue is changed, I want to call my backing bean, which in turn will cause the page to rerender and display different fields on the page. This basically gives me a dynamic, data sensitive entry page. This works fine! Unfortunately, when the value of inputvalue has been changed and the user clicks cancel, the onchange event is fired, while the onclick associated with the button appears to be ignored. This results in the page rerendering, but the cancellation does not happen. I'm pretty new to JSF, so I don't really know what approach I should be taking here. I tried to add an <a4j:support> component to the button in an attempt to get multiple requests sent to the bean, as I'm perfectly happy for the page to rerender and then cancel. However, this did not seem to work either.

Any thoughts or insights would be greatly appreciated!!


Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

Welcome to the JavaRanch, Dan!

If you use the rich:commandButton instead of Tomahawk's version, you'll get AJAX support without the need to add a separate a4j:support sub-element.

As far as the actual problem, I can't definitely tell, but I can think of some "gotchas".

First, some JavaScript attributes can interfere with the normal processing of events and therefore have to return a boolean value. The "onclick" event is one of them - you can cancel a submit by having it return false.

Second, I've become rather painfully aware lately that doing a reRender on a container of the the element requesting the reRender can lead to unexpected behaviours. In fact, it's even possible that the post-submit JavaScript is being erased before it can be executed as the form is updated (including the control with the JavaScript in it!).

Hope that helps!


Customer surveys are for companies who didn't pay proper attention to begin with.
Dan Webber
Greenhorn

Joined: Mar 31, 2011
Posts: 5
Thanks for the reply Tim. I appreciate the tips on the gotchas. I'm guessing I should look to add an a4j:region around the specific elements that are likely to change? That means that the component requesting the rerender will be outside the region and it should be safer that way...? I will try this out and see if it makes any difference anyway...

One thought I did have is if I had a command button that was bound to a control in my bean, is there anything within the control that will identify that it was clicked?

Thanks again for your help
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

Dan Webber wrote:

One thought I did have is if I had a command button that was bound to a control in my bean, is there anything within the control that will identify that it was clicked?



A commandButton is a control. However, in your code sample, what will happen is that when the control is fired (clicked), the form containing it will be submitted. JSF will validate the inputs, and if validation succeeds, update the bound properties and then invoke your action method. If you have multiple Submit controls, the easiest way to determine which one was clicked is to simply implement a separate action method to each of them. They can then invoke any common code they want to.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: onblur event hijacks my onclick!