Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Invalid
-
Affects Version/s: 1.7.2
-
Component/s: Framework
-
Labels:None
-
Environment:Windows, x86, webflow 1.0.5
-
ICEsoft Forum Reference:
Description
<ice:inputText value="test" valueChangeListener="#{myAction.valueChange}"/>
In my action I retrieve the component from the actionEvent and I change the value of an attribute. For example, I set the 'rendered' attribute to 'false'.
Now, for some reason this attribute gets replaced with the original value (which was true). This happens in the render response phase. The same problem is also seen when doing actual component binding. The result is that I cannot control the components state from my actions anymore.
Note: this seems to be a problem when IN a flow (webflow 1.0.x). When testing the page OUTSIDE a flow it works fine.
This is a problem since 1.7.2 (it worked in 1.7.1)
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
This seems to be broken by the the fix for issue: ICE-3664
BridgesFacesContext sets the ViewRoot back to NULL at line 235 (switchToNormalMode).
This method seems to be called upon a GET following a POST.
I understand that ICE-3664 is a fix to ensure that the viewroot is properly rendered on consequent GET requests.
However, just setting the viewroot to null will break regression with webflow and cause problems.
Example scenario:
1. A form is being posted, a webflow transition is triggered
2. Webflow executes the action: the action invoked changes an attribute of a certain component on the pages (sets a 'rendered' attribute from false to true for example)
3. Webflow issues a redirect to the browser
4. Broswer follows redirect
5. Server receives a GET request: icefaces sets viewroot to NULL
6. New UIViewRoot is created [b]<------------- at this moment the components are initialized to their default value! The attribute change at step "2" is lost![/b]
7. View gets rendered
If a clean viewroot is created, at least the state of the existing one should be transfered to the new viewstate somehow...
Assigning to Ted to examine in the context of all reported WebFlow issues.
The ViewRoot is not set to null anymore by ICEfaces so it is possible that this issue is fixed in 1.7.2SP1, 1.8DR#2 and Trunk. See commit http://sventon.icefaces.org/svn/diffprev.svn?path=%2ficefaces%2fbranches%2ficefaces-1.7%2ficefaces%2fcore%2fsrc%2fcom%2ficesoft%2ffaces%2fcontext%2fBridgeFacesContext.java&revision=17907&name=repo&commitrev=17907 .
Errorken Errorken, can you verify that this is the case?
I'm marking this issue invalid for now. As I said in my previous comment, currently the ViewRoot is not cleared anymore when a GET/page request is received.
In case this issue still exists with 1.8DR2 or Trunk we will need a test case to reproduce the problem (especially when additional frameworks are used in combination with ICEfaces).
I tested it some time ago with 1.7.2 SP1 and it seems to be fixed indeed, thanks
A test case is easily made, I'll upload an here example shortly
This seems to be broken by the the fix for issue:
ICE-3664BridgesFacesContext sets the ViewRoot back to NULL at line 235 (switchToNormalMode).
This method seems to be called upon a GET following a POST.
I understand that
ICE-3664is a fix to ensure that the viewroot is properly rendered on consequent GET requests.However, just setting the viewroot to null will break regression with webflow and cause problems.
Example scenario:
1. A form is being posted, a webflow transition is triggered
2. Webflow executes the action: the action invoked changes an attribute of a certain component on the pages (sets a 'rendered' attribute from false to true for example)
3. Webflow issues a redirect to the browser
4. Broswer follows redirect
5. Server receives a GET request: icefaces sets viewroot to NULL
6. New UIViewRoot is created [b]<------------- at this moment the components are initialized to their default value! The attribute change at step "2" is lost![/b]
7. View gets rendered
If a clean viewroot is created, at least the state of the existing one should be transfered to the new viewstate somehow...