• Post Reply Bookmark Topic Watch Topic
  • New Topic

RichFaces re rendering not working after Ajax Form Submit

 
Jehan Jaleel
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have a button implemented as a RichFaces a4j Command Link...



When this button is clicked I want an input field another part of the page to be refreshed...



Specifically what I need is for the disabled property to be updated. Notice how disabled currently calls the Controller to see if the object is in paused state. Right now what happens is even after user pauses by clicking the button the input field remains disabled. Only a full page refresh enables it.

I tried using the render and reRender attributes that the RichFaces docs (http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/ArchitectureOverview.html) mentioned but to no avail.

Can anyone offer any suggestions?

Thanks in advance for any help.
 
Tim Holloway
Bartender
Posts: 18417
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. JSF backing beans are not Controllers. In JSF, the Controllers are in the tag implementation code and in the FacesServlet, not in user-written code. AJAX listeners and JSF Action methods are not Controller methods, they're a function outside of the MVC paradigm. So naming a backing bean "controller" is incorrect.

2. EL method expressions are supposed to be method references, not method calling code. Code on the View template is bad. It breaks the MVC separation of concerns and can adversely affect both security and performance. JSF was designed so that action methods should not need to be passed parameters, since all the values and more are normally already posted to the backing bean by JSF itself.

3. Your actual question: I think that your commandButton element is defective. It appears to be blending features of JSF2 and RichFaces 3 together. If you are using RichFaces 4 (and JSF2), I think the a4j:commandButton is replaced by an ordinary h:commandButton paired with an f:ajax element. RichFaces 3 won't work properly with the f:ajax tag (as well as certain other JSF2 features).

I also hope that all those references to "job" in the sample don't mean that you are spawning threads from JSF. That is explicitly forbidden by the core J2EE standard (not just JSF) and can cause your entire server to crash unpredictably.
 
Jehan Jaleel
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim,

Thanks for taking the time to respond and for telling me about some of the JSF Standards and Best Practices. I actually did not write this code myself but simply inherited. I know it would be best to refactor but right now I just need it to work.

Regarding my actual problem, I am not sure though what you mean by saying the commandLink element is defective. The method specified in the action attribute is being called and I am seeing the code in the JSF backing being firing when I put a breakpoint there. So the commandLink itself is working.

My only question is why the h PanelGroup element is not getting updated like the RichFaces docs which I provided in the link said it would. Specifically the disabled attribute of in the input field which the PanelGroup encompasses is not being called. Do you have any idea why this is happening?

Thanks again,
Jehan
 
Tim Holloway
Bartender
Posts: 18417
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, now you've done it. Made me RTFM.

According to my copy of the RichFaces 3 docs, there is no "execute" attribute for JSF commandLink and therefore it would be ignored. But the "@this" was what really set off an alarm, since I think that's strictly for the JSF2 f:ajax element, and not for RichFaces.

My experience with RichFaces is that sometimes reRender can be quirky, although usually reRender on a naming container such as a panel or panelGroup works pretty well.

One thing that I am uncertain of, however, is the parameterized EL call "#{controller.onPauseRun(task)}". The original JSF method reference "#{controller.onPauseRun}" form will cause invocation of the onPauseRun method at a specific point in the JSF lifecycle because it is a reference (data item) that the JSF action controller uses to select the method to invoke in the action handling phase. A function call (parameterized or not) MAY not get called at that point in time, since the evaluation is handled by the EL processor, which is a distinct subsystem from JSF, available also to non-JSF resources such as vanilla JSPs. So it's possible that things are being processed out of order.

For complex EL expessions like your disabled attribute, I prefer to apply a little Propositional Calculus aided and abetted by EL's non-Java syntax extensions so I'd code it like this:


Functionally, should be the same, but I find it easier to read and debug this way. Easier still would be to add a boolean property method that collapsed the whole thing down to a simple properly reference and put the logic in the backing bean, but even I make exceptions when the expression isn't too complicated. It's already bad enough that "disabled" is a negative attribute so you need a double-negative to get a positive (enabled) result.
 
Jehan Jaleel
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I figured it out. The command Link was actually in a separate JSF page from the input field which had the disabled attribute. It was being included in like so...



So I think the problem was the commandLink was not "seeing" the panelGroup that it needed to re render. Rather than even using the reRender attribute, I simply added the Panel Group (which has the input field which has the disabled) called "taskCostWidget" to the existing render attirbute but I prefaced it with "main"...



This did the trick.

My sincere apologies for not sharing this information with you earlier. But your advice was valuable in helping me focus on exactly where the problem was, and it also helped me learn more about JSF, as well as see the many issues in this code I am now responsible for.

Thanks again.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!