Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 1.7.2
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:ICEFaces 1.7.2 (comps; core;facelets)
JSF RI 1.2_09 (problem exists with older version as well)
Description
Test page setup:
[code]
<ice:outputText value="test"/>
<ice:commandButton actionListener="#{bean.toggle}"/>
[/code]
ActionListener setup:
[code]
public void action(ActionEvent actionEvent) {
for (UIComponent child : actionEvent.getComponent().getParent()
.getChildren()) {
if (child instanceof HtmlOutputText) {
HtmlOutputText output = ((HtmlOutputText) child);
if (output.isRendered()) {
output.setRendered(false);
} else {
output.setRendered(true);
}
}
}
}
[/code]
The action listener will lookup the 'outputText' and toggle its rendered attribute.
The rendered attribute is by default 'true'.
Failing test:
1. Open the page (output text is rendered = OK)
2. Click the button (output text gets hidden = OK -> implemented toggle behavior in action listener)
3. Click the button again (output text gets shown = OK -> implemented toggle behavior in action listener)
4. Click the button once more (output text gets hidden = OK ...........)
5. Now, hit F5 in browser
6. Output text gets shown (NOT OK !)
The problem here, is once again, related to setting the viewroot to NULL.
This is what happens:
1. I hit F5, browser sends GET
2. ICEFaces discovers this is a GET and sets viewroot to null
3. A clean viewroot is created by JSF
4. Components are getting bound by facelets, but there is nowhere state injected
NOTE: it works when BINDING the component to the action instead of looking it up via the component tree; when doing this the component instance is retained on the action.
The facelets componentHandler will (instead of creating a new instance) execute the binding VE pointing to the action containing the component instance.
This way the state is reatained and it appears to be working.
Issue Links
- depends on
-
ICE-3664
Component attribute state overwritten with webflow1.0.x
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Did this work as desired with ICEfaces 1.7.1? (In other words, is this a regression or a new feature.)
If Spring requires pseudo-postback support, then this is probably doable.
Value binding would break the entire goal of JSF component binding.
Fact is that at the moment, JSF retains state whenever the request is marked as a 'postback'.
Webflows 'get' (in the post/redirect/get) must be treated as a postback (its not a 'post' but it serves the same goal - as state must be retained)
Therefore webflow adds the 'javax.viewstate' request parameter which serves, according to the JSF spec, to indicate if a request is a postback.
I feel that ICEFaces should at least respect this and see if the request is a postback BEFORE setting the viewroot to NULL
Just assuming a GET is by default not a postback is just wrong.
This could easily be fixed in ICEFaces just by checking if its a postback:
if(!postback)
viewroot = null;
Would this be possible?
A much simpler solution is to use a ValueBinding for the rendered attribute, and just toggle the boolean in your bean.
I don't believe that stock JSF would persist the component state through an F5 refresh, so it's not something ICEfaces should do either.
A possible solution would be to check if the get should be considered as a postback BEFORE setting the view root to NULL.
- GET requet comming in
- GET is postback ?
Yes: leave view root as is
No: null out view root
Imho this should solve the problem
Ted; as I pointed out here http://www.icefaces.org/JForum/posts/list/0/10250.page#42063 this is a regression issue.
There is no such problem with 1.7.1 (we also reverted from 1.7.2 back to 1.7.1 because of this issue)
Resume:
Since 1.7.2 the viewroot is explicitly set to null when the request is a GET.
According to the changelog, this was done to fix an other issue showing blank pages or something.
However, when working with webflow, some GET requests should be considered as postback (as Mark pointed out here: 'pseudo-postback')
This can be detected by a request parameter 'javax.viewstate' as described by the spec.
There is alo a convinience method that checks this I believe.
I think a solution would be to null the viewroot when its a GET but NOT a postback.
This should fix the webflow issue and not break the fix for the initial problem