views:

593

answers:

1

Hi,

I'm currently working on a JSF 1.2 project (IBM implementation and a "company layer").

PROBLEM

Here's the situation (numbers of items are just for the example), simple CRUD

  1. List item
  2. I have a list of items
  3. I click on item 2 to see detail
  4. I click on modify, the modification page displays values of item 2
  5. Back to the list with a button "Back" and immediate="true" (because we don't want to submit the modifications)
  6. Detail of item 4
  7. Modify item 4 > Values of item 2 are displayed

BUT

  • if I set the "immediate" attribute of the "Back" button to false, values of item 4 are OK.
  • if I set the "disabled" attibute of an inputText component to true, value of item 4 is OK.
  • if I use <h:outputText value="#{item4.myValue}/> (UIOutput) instead of <h:inputText value="#{item4.myValue}/> (UIInput)

Also, I checked in debug mode that the bean I wanted to display was "item 4" and it was.

WHAT I FOUND

After some research on Google I found that this problem comes from the lifecycle of JSF, although the documentation and solutions found are for specific implementations of JSF. So I guess it's because the value is populated with "localValue" instead of "submittedValue" (@see EditableValueHolder interface could help understanding), and there are some solutions from these pages

RESULT

It doesn't work (I wouldn't be here, I swear ^^). The "Refresh" solution is ineffective. The "Erase input" is scary. I can't admit that I need to reference every input field! Plus I didn't find the setSubmittedValue() method on the UIInput in my IBM JSF. The "Clear" method is ineffective. I tried on one element, and on the complete component tree with this code

public void cleanAllChildren(List<UIComponentBase> list){
 for(UIComponentBase c : list){
  this.cleanAllChildren(c.getChildren());
  c.getChildren().clear();
 }
}

But without success. So here I am. Did I miss something? is there a nice tricky solution I didn't see? I'm not really familiar with the JSF lifecycle.

+1  A: 

Put the bean with request scoped data in request scope, not in session scope.

You probably have the entire list in session to "save" DB calls and all the work to retain values in the subsequent requests inside the same session. You can use a separate session scoped bean for that, e.g. DataManager. Then you should have a request scoped bean to represent the selected item, e.g. DataItem. You can familarize the both beans with help of managed property injection.

BalusC
You're right BalusC, I've my bean in session because I'm waiting for the Cobol service layer. I didn't think that could be the cause. I'll confirm this theory as soon as I come back at work, in 2010. Thanks for your help.
Baztoune
It works like a charm ;)For people having the same issue, you can have more information here http://java.dzone.com/articles/making-distinctions-between and on BalusC's blog http://balusc.blogspot.com/2006/06/using-datatables.html
Baztoune