ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Please have a look at:

http://jira.icefaces.org/browse/ICE-3713

It is said to be fixed in :

http://jira.icefaces.org/browse/ICE-3691

which is in SP1, so I suspect that is (still) the problem.

(Unlike 3713 with 1.7.2 I did not yet had the time yet have to investigate the problem)

When starting a flow, the page does not change to the viewroot indicated by the flow. So its like nothing is happening.
In other words, webflow 1.x integretation seems to be (this time completely) broken

I don't understand your comment. Can you elaborate this a bit?

As far as I know, the goal of declaring (overriding) a component in the faces context is just to support having custom components.

In this case, the custom ICEFaces UIViewRoot, should be declared in the faces-config with the custom class, overriding the original UIViewRoot component class.

When a caller needs a viewroot, its calls FacesContext.getCurrentInstance().getApplication().createComponent() . This will return an instance of the custom class registered with this component...

Anyone from ICEFaces had a look at this yet?

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

There is also a problem with the components state when working without weblow.

Test page setup:
Code:

 <ice:outputText value="test"/>
 <ice:commandButton actionListener="#{bean.toggle}"/>

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);
 				}
 			}
 		}
 	}

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.

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 <------------- at this moment the components are initialized to their default value! The attribute change at step "2" is lost!
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...

The D2DFaceletViewHandler instantiates the view root directly by calling the constructor on UIViewRoot. This is not the way it should be done.
The D2DFaceletViewHandler should depend use the FacesContext.getCurrentInstance().getApplication().createComponent() to instantiate the view root.
When extensions are needed on the default UIViewRoot, it is now not possible to plugin a new view root component (the only alternative is extension of the D2DFaceletViewHandler, which is dirty).

I define a component on my page with a valueChangeListener:

<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)

I have a screen with two forms. Each form has an selectinputText (autocomplete) . Each selectinputText is bound to a property of its corresponding backingaction. When I submit the first form, I change the value of the first selectInputText in code , but also of the second selectInputText(being in the other form), in code (in the backingaction).

Now, when the update is received by the broswer, it does seems to contain only the first form, and not the second form. This mean that the textfield in form one is updated, but the textfield in form two remains empty.

When I actually submit the first form, the reply contains both forms so the second selectInputText shows the value.

Any progress on this ?

Ok, in regards to my previous post I found out that:

Setting 'immediate' on the selectInputDate generates an actionEvent which is handled during apply request values phase. This means that update model is never executed. So, when you set the selectInputDate to 'immediate' you can safely jump in and out the field without causing it to update the model.

The only problem remains that when you click the button next to the calendar component (to open te popup) it still executes the update model phase. I think this is a bug, no ?

Its also weird that (once the popup is open) when you navigate FORWARD in months, no update to the model occurs (actionevent). when you go BACKWARDS there is an update occoring.... very weird.

Can someone give an explanation about this please?

Ok, in regards to my previous post I found out that:

Setting 'immediate' on the selectInputDate generates an actionEvent which is handled during apply request values phase. This means that update model is never executed. So, when you set the selectInputDate to 'immediate' you can safely jump in and out the field without causing it to update the model.

The only problem remains that when you click the button next to the calendar component (to open te popup) it still executes the update model phase. I think this is a bug, no ?

Its also weird that (once the popup is open) when you navigate FORWARD in months, no update to the model occurs (actionevent). when you go BACKWARDS there is an update occoring.... very weird.

Can someone give an explanation about this please?

I solved it with an IFrame, at least it works on IE.
You can simply add javascript to the outputlink component, or you can (like I did) create a custom component that overrides the original 'OutputLinkRenderer' from icefaces and automatically adds the javascript (there is no real difference, but the second solution its cleaner if you need it on multiple places)

[code]
javascript: element = document.createElement('iframe'); element.src=URL_TO_SERVLET; element.width=0; element.height=0; document.body.appendChild(element);
[code]

The IFrame will open a new 'invisible' window. So you get the 'save as...' and the icefaces components remain working in the parent window where you clicked the link.

This is in regard to this topic; http://www.icefaces.org/JForum/posts/list/8968.page

When I set 'immediate' to true on the selectInputdate component, the update model seems not to be executed (untill I hit the 'submit'). This actually solves the problem mentioned in the post refered above.

But this is not according to the spec or am I wrong? immediate on UIInput components should NOT skip the update model phase;..

I know I'm complaining in the previous post about why the update model is executed when I enter something in the selectInputDate, and here I'm complaning that immediate solves it:)

I just would like to know why immediate on the selectInputdate has this impact.... ?

Thanks.