Proper Navigation Problem of Richfaces 4.0

[hamzas100]

In the quest for performance problem solution of richfaces I came into solution that I have break my application into small pages with less richfaces components. Because since I used pupup panel, memory consumption of my application grows drastically. But unfortunately richfaces navigation components with action attribute does not handle well navigation(when you navigate from one page to another some of the components does not get rendered or selection of extended table does not work properly..etc).

why ???

Lets show you code example(the same applies to a4j:commandLink or h:commandLink ) :

  <rich:menuItem  label="Прих Накл Для Прилавки " action="#{navigator.goToPurchaseInvoiceForCounterOperations}" >
                        <f:setPropertyActionListener target="#{purchaseInvoiceForCounter.defaultLocation}"
                                                     value="#{customization.defaultSalesPoint}" />
                        <f:setPropertyActionListener target="#{purchaseInvoiceForCounter.defaultReevaluationActDone}"
                                                     value="#{customization.defaultReevaluationActDoneForPurchaseInvoice}" />
                        <f:setPropertyActionListener target="#{purchaseInvoiceForCounter.defaultCurrencyExchangeRate}"
                                                     value="#{customization.defaultCurrencyExchangeRate}" />
                        <a4j:ajax event="click" execute="@this" />
                    </rich:menuItem>

or

  <a4j:commandLink label="Прих Накл Для Прилавки " action="#{navigator.goToPurchaseInvoiceForCounterOperations}" >

  <f:setPropertyActionListener target="#{purchaseInvoiceForCounter.defaultLocation}"

  value="#{customization.defaultSalesPoint}" />

  <f:setPropertyActionListener target="#{purchaseInvoiceForCounter.defaultReevaluationActDone}"

  value="#{customization.defaultReevaluationActDoneForPurchaseInvoice}" />

  <f:setPropertyActionListener target="#{purchaseInvoiceForCounter.defaultCurrencyExchangeRate}"

  value="#{customization.defaultCurrencyExchangeRate}" />

  <a4j:ajax event="click" execute="@this" />

  </a4j:commandLink>

[hamzas100]

The solution lies here in using a proper JSF component(as you can see you can apply tooltip and image also). See the solution below(but unfortunately in solution below while navigating you will notice page refreshment or reload which is ok with my application) :

<h:link outcome="#{navigator.goToPurchaseInvoiceForCounterOperations}">
                        <h:graphicImage library="images" name="incomeForCounter.gif" alt="X"/>
                        <a4j:ajax event="mouseover" execute="@this" />
                        <rich:tooltip  styleClass="tooltip" layout="block">
                            <span style="white-space: nowrap">
                                Приходный Накладной Для Прилавки
                            </span>
                        </rich:tooltip>
                    </h:link >

[healeyb]

Using an action method to navigate to a different page works fine, if you are seeing problems there must be another issue. Of

course you'll be using POST requests, which is not considered ideal for pure navigation.

Regards,

Brendan.

[hamzas100]

Dear Healey I am finally using the same menu item and commandlink with action method. Actually former solution did not worked with menuitem. I have changed faces-config. xml by adding redirect as follows:

<navigation-rule>

        <from-view-id>reports.xhtml</from-view-id>

        <navigation-case>

            <from-outcome>settlements</from-outcome>

            <to-view-id>/settlements.xhtml</to-view-id>

            <redirect/>

        </navigation-case>

</navigation-rule>

I know that redirect only changes web address in web browser but I am not sure of clean redirection still(as post was used in case of h:link>?

thanks and regards,

Khurshed S Salimov

[healeyb]

I'm not completely following the existing situation and exactly what is not working now. The first thing is that in JSF 2 (which you must be

using because you are using RF 4) you don't have to use navigation rules in faces-config because JSF 2 introduced the notion of implicit

navigation. You can still use them, but I've never had the need. So with no navigation rules configured if I have h:link outcome="/login" and

I click on the link a GET request will be sent for http://myhost/MyProject/faces/login.xhtml, where xhtml is the default suffix configured in

web.xml.

<context-param>

        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>

        <param-value>.xhtml</param-value>

    </context-param>

    <context-param>

        <param-name>javax.faces.FACELETS_VIEW_MAPPINGS</param-name>

        <param-value>*.xhtml</param-value>

</context-param>

I seem to remember being surprised that no suffix had to be provided for h:link, but this is different for commandLink/Button. I'd suggest

hard-coding the navigation target rather than using an EL expression until you've got the basic navigation working.

If you're clicking on a button or link and getting a 404 you need to use the browser developer tools/firebug to see what's going on. Google

chrome comes with all the necessary tools built in. Just click F12, go to the network tab, reload the page (F5) and click on the link. You

should see the GET or POST request on the left hand side highlighted in red. Click on the request and select Headers to see the

incorrect target of the request.

From there it's normally pretty easy to resolve the issue, and you can compare a request that worked wth one that didn't.

Regards,

Brendan.

[hamzas100]

Dear Brendan ,

Many Thanks  for your help. Yes, it is now sending get requests.

regards,

Khurshed

[hamzas100]

The followings are what I found useful in targetting problem above

Comparing h:commandButton(a4j:commandButton) and h:button

What’s the difference between h:commandButton/h:commandLink and h:button/ link? The latter two components were introduced in 2.0 to enable bookmarkable JSF pages, when used in concert with the “View Parameters” feature explained later in this chapter. There are three main differences between h:button/h:link and h:commandButton/h:commandLink. First, h:button/h:link causes the browser to issue an HTTP GET request, while h:commandButton/h:commandLink does a form POST. This means that any components in the page that have values entered by the user, such as text fields, checkboxes, etc., will not automatically be submitted to the server when using h:button/h:link. To cause values to be submitted with h:button/h:link, extra action has to be taken, using the “View Parameters” feature. The second main difference between the two kinds of components is that h:button/ h:link has an outcome attribute to describe where to go next while h:commandButton/ h:commandLink uses an action attribute for this purpose. This is because the former does not result in an ActionEvent in the event system, while the latter does. Finally, and most important to the complete understanding of this feature, the h:button/h:link components cause the navigation system to be asked to derive the outcome during the rendering of the page, and the answer to this question is encoded in the markup of the page. In contrast, the h:commandButton/h:commandLink components cause the navigation system to be asked to derive the outcome on the POSTBACK from the page. This is a difference in timing. Rendering always happens before POSTBACK.

JSF includes two components that support bookmarkability

1. h:button
2. h:link

Whether or not to use redirects

largely depends on whether what is shown in the address bar of the browser matters or could be confusing if the page referenced no longer matches the page being rendered. Another important consideration of when to use redirects is performance. Using a redirect will terminate the current request and cause a new request response cycle to occur. If the page has a very large set of components, this could have a noticeable performance impact. Redirects can also necessitate an extra round trip to reinstantiate any request-scoped objects that have disappeared by the next request.

informations taken from section More Sophisticated Navigation Examples. JavaServer Faces 2.0: The Complete Reference. by Ed Burns Chris Schalk with Neil Griffin. p.116