ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Dear Forum,

I'm getting quite desperate on trying one of my current in-development icefaces apps (1.8.2, JSF 1.2, Tomcat) in GF3 and the 2.0 alpha of icefaces with the compatibility jars in place. So far, I've adapted the web.xml + faces-config.xml and changed all .jspx files to .xhtml. However, one fundamental concept fails to work which I used heavily in one of my apps for page navigation. Instead of relying on navigation rules and page flow, a String property representing the path to the page is changed as the result of a navigation action (menuItem or commandLink or commandButton).
The pages and sub-pages are included with the

<ui:include src="#{nav.path}" />

pattern and this used to work like a charm in the JSF1.2/MyFaces 1.2 together with Icefaces 1.8.2

Under 2.0alpha, the nav bean gets called upon menuItem click, the path is selected but the view seems not to get rebuild.

(the path getter is not being called)

The Menu and the sub - page are embedded in a panelBorder.

Is this probably due to bugs/gaps in 2.0alpha and will probably get fixed or is this a fundamental change in behaviour - maybe due to JSF2.0?

It would be frustrating to learn that a brand-new app has been created on a deprecated page inclusion /navigation pattern.

EDIT: it takes 2 mouse clicks on the menuItem to change the top-level pages (included in the center region of the panelBorder). Navigation in one of these loaded pages (with a nested ui:include) does not work.

Kind regards
Michael

Not sure exactly what you are referring to as this may require a simple sample attached to this thread to look at to fully understand. However, try an <f:ajax/> tag in your menu item to see if it's just not being submitted. Also could post your xhtml with backing bean here to review.

Thanks for your response - please find a jar with source code and resources attached - it's the same pattern regarding pages and navigation as my current 1.8.2 application.

kind regards

Michael

I reckon nobody else is suffering from that problem - I'm somewhat stuck. Including parts of the view with <ui:include src=... and an EL expression referencing a bean property is probably a widely used pattern.

kind regards
Michael

Hello Michael,

I had the same problem. Look here: http://www.icefaces.org/JForum/posts/list/15869.page

I don't use this kind of navigation anymore. So how do I do navigation now?

- I use GET requests now available with JSF2, eg. <h:link outcome="home?faces-redirect=true" value="Go to Home Screen" />

- When doing navigation in an action method I add "?faces-redirect=true" to the viewID to be returned, eg. return "home?faces-redirect=true"

Hope this helps,
Patrick

Hello Patrick,

thanks for your input. If I'm not mistaken, the kind of navigation that might need to be abandoned was recommended in tutorials - instead of using page flow with navigation rules and outcomes. I really loved the way <ui:component> elements could be made available to parts of the page (as visible by the user) without any page reload or flicker.
For example, in my app I'm using a <ice:panelBorder> with a static menu in the west and changing page content in the center. Could this be achieved by your method?

Kind regards
Michael

I was also worried about page reloads and flicker, but it doesn't happen, at least I don't see it. The Icefaces Direct-to-DOM rendering seems still to be working. Just add a <h:link> to your component and test it.

Regards,
Patrick

Hello Patrick,

I tried to apply the suggestions to my showcase example. In my NavigationBean, I return the root facelet of my app

public String openCrud() {
log.info("Opening Crud");
this.index = NAV_CRUD;
return "/start.xhtml?faces-redirect=true";
}
public String openLogo() {
log.info("Opening LOGO");
this.index = NAV_LOGO;
return "/start.xhtml?faces-redirect=true";
}
The NavigationBean is session scoped. It works nicely to flip back and forth between the two selections from the <ice:menuItem>
Now, the path that will be returned from the NavigationBean when setting the NAV_CRUD index shows a <ui:component> with its further, nested include path.
This bean is - and I probably do not fully understand the new scopes -
View Scoped or Custom scoped "window". Clicking on an "OpenDetail" command button shall switch the page index of the sub-component to the detail form, it calls the openDetail() method in myCrudBean:

public String openDetail() {
log.info("Opening Detail");
this.index = P_DETAIL;
return "/start.xhtml?faces-redirect=true";
}

However, the MyCrudBean gets instantiated after every click and thus "forgets" the new values.
My 1.8.2. code uses the Icefaces Request Scope behaviour where beans survive request boundaries without having to be session scoped beans.

Kind regards
Michael

Then assign the MyCrudBean to session scope too. Whenever you press an entry in your menu you switch the view (always to start.xhtml, but that doesn't matter, it is a new view). So all beans that live only as long as the view will be recycled. That is my guess.

More about scopes:
http://wiki.icefaces.org/display/ICE/Compatibility#Compatibility-scopes

Regards,
Patrick

Hello Patrick!

I will try that of course - and I will always have to set the outcome to the root facelet with option facelet-redirect=true to force the rebuild of the tree?!

Pity that what looked like a recommended practice is now causing trouble when moving to a newer version, requiring code change. Interested to learn how ICEfaces.com copes with that for their commercial users.

I'm not afraid of that but rather that I would have to dump the chosen design pattern. And I reckon that staying with 1.8.2. and JSF 1.2 is not an option (it all started that GF3 shall become our "standard" AS).

EDIT:
one further phenomenon: when calling an action method (e.g. doSearch()) from an <ice:inputText> component by pressing enter in such field, the action methods for the <ice:commandButton> gets called as well - bug or feature?

If there was a chance to use 1.8.2 against JS2.0 with 100% 1.8.2 behaviour I'd probably more than happy...

kind regards
Michael

Hello Michael,

whenever I have to change a view I do it with a redirect. This has the advantage that URL in the browser also changes. I tried skipping the redirect, but I got errors that might be related to the alpha status of Icefaces2. Even if you do a redirect, Icefaces does the partial rendering (no flicker as you named it).

The suggestions I make are not supposed to be ultimate and correct answers to your problems but might help you with your own investigations. I might be wrong or might have missed important aspects.

Kind regards,
Patrick

Hello Patrick,

yes, that's where I got stuck with a bit. The sex appeal of the original design was that I could create a gui pretty much like a standard (i.e.non-web gui). By including different ui:components different sub-parts of the screen were changing (=different set of controls) like previously invisible panels have been unveiled.
Maybe I overdid it and have a ui:component including a ui:component including a ui:component and each layer is controlled by a path wich is dynamically set in a bean property.

At the moment, it seems to session scope (don't can assess the side affect of doing that at the moment) all managed beans that supply a navigation path for ui:include and for every action method that changes the path of one ui:component inclusion, the outcome is set to root-facelet?facelet-redirect=true

If that works, it would let me get away in a probably not-so-far-away future with hopefully minor changes to the existing code.

The issue that action methods of buttons are called even though the button has not been clicked might be due to the alpha state of icefaces. Probably should use an faces button here.

Do I understand correctly that when I set the outcome of an action method, the view name (=the facelet) will become the new component root?

kind regards
Michael

p.s. what kills me is that it seems not having the option to choose. If GF3 is becoming our standard, I must take it with JSF2.0 - and thus I must move my app to Icefaces 2.0.

Yes, every view will have its own component tree. But if views use the same "page-template", eg.

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
template="/portal/templates/page-template.xhtml">

then a great deal of componts are shared between the views. And this is the reason you don't see any flicker, because Icefaces identifies these shared components that didn't change between view navigation and only propagates the component tree changes to the client.

Hello! :-)

I think the culprit is found - changing the context parm

Code:

 <context-param>
 		<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
 		<param-value>false</param-value>
 	</context-param>

from true to false and the 1.8 application seems to work without change to the code (outcome to the root facelet with redirect=true).

However, I have no idea what the downside of setting this context parm might be.

Kind regards
Michael