tags:

views:

33

answers:

3

action method is not called Please refer to this question - , One of my UICommand Component is rendered conditionally , it was said in the answer of the linked question - point 5 - that if the Component's or any of its parents rendered or disabled attributes are false - then the action method will not be called ? If thats the case- How do i achieve the same functionality? Is there a work around ? or a trick ? or any other approach ?

Thanks!

+2  A: 

To the point, you'd like to retain the property responsible for the rendered condition in the subsequent request. There are several solutions for this problem:

  1. Put bean in session scope. It's easy, but it hurts. It's bad for user experience since changes will be reflected in all tabs/windows the user has open in the same session.

  2. Use <h:inputHidden> to transfer the property. In theory easy, but in practice it hurts as well. The value will namely get lost whenever a validation/conversion error has occurred in any of other inputs in the same form. This is an odditity in how JSF handles hidden input elements. A workaround is to use <h:inputHidden binding="#{bean.hidden}"> and do a hidden.getValue() and hidden.setValue() in bean.

  3. Use Tomahawk's <t:saveState>. The perfect solution as far. This will retain the value (or even a complete bean) in the subsequent request.

If you're already on JSF 2.0, the @ViewScoped would have solved this all. It behaves like the t:saveState.

BalusC
<Quote>you'd like to retain the property responsible for the rendered condition in the subsequent request.<Quote>What I dont understand is - The Command button is displayed because the rendered was true. What is meant by retaining the property here? Is not it already retained when the Button is clicked ? (!)
gurupriyan.e
A request scoped bean is garbaged when the HTTP response is finished. A fresh new bean will be created when you fire a new HTTP request by clicking link/button. This fresh new bean will have all default properties. The default property might have caused the `rendered` attribute to evaluate `false` during restore view. You have to take care that the bean get recreated with the same properties as it was during displaying the form. You can make use of the bean's constructor, `@PostConstruct` method, component binding, `t:saveState`, etc for this.
BalusC
Thanks BalusC.I get what you say. But I do not know how to do this. I cannot use Tomahawk lib files. How do I do this either using component binding or using the bean's constructor? Do you have sample code?
gurupriyan.e
That really depends on what the property responsible for the `rendered` attribute represents and how it is constructed in the initial request. In the previous question it's been accessed as `#{adminBean.displayResultsSize}`. This look very much like the size of the results as you display in the table. You'll need to reload the same results then.
BalusC
Thanks.Javascript came to rescue,preferred to use javascript than this stuff.
gurupriyan.e
There are indeed more ways which leads to Rome :)
BalusC
Accepting this as the answer which is more of a JSF way to do things. :)
gurupriyan.e
A: 

The trick is to have 'rendered' evaluate to true when it is time to run the action and then change the condition to false in the action method.

Let's say you have a link rendering based on a boolean in your bean called 'editing'. Then your action would look something like this:

public String myAction() {
    // whatever you want your action to do

    editing = false;
}

Edit: this assumes that the bean is either session scoped or the boolean get propagated between requests.

Colin Gislason
A: 

In my case, Javascript came for rescue, Which means, whatever was to be displayed conditionally , put them in a HTML Portion and don't display them display: none until the desired event occurs.

HTML Portion can have any JSF Tags(including CommandButtons) as you wish and would work (invoking the action methods and the stuff )perfectly okay.

gurupriyan.e