2

For a project I am updating a Java web application that has some loose ends. I'm having problems with the init-method of a bean, that is called while it should not be.

The page that causes the problems has three buttons to return to three different pages you have visited earlier. Two of these buttons cause the init-method of the bean of the page you are currently on, to be called. You have to press the button again to get the action performed (=return to the other page). The strange thing is: you can arrive at the problem-page via two menu options. One causes the problem, the other way does not. You return to the other page without problems.

Piece of xhtml of the problem-page:

<h:commandButton value="Show batch" action="/BatchDetail.xhtml" />
<h:commandButton value="Show messages" action="/BatchMessage.xhtml" />
<c:if test="#{batchMessageDetailBean.batch.part}">
   <h:commandButton value="Show both" action="/BatchAndBatchMessage.xhtml" />
</c:if>

The 'show batch' and 'show messages' cause the problem. The third button is only present via the menu option that causes the problem with the first two buttons. Strangely, this button does not call the init-method again.

I've read about the 'c:if' causing problems, but when I remove it entirely, nothing changes. The bean is @ViewScoped. I'm not using Spring. If you need more details, just ask.

Any ideas?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Century
  • 283
  • 1
  • 4
  • 22

1 Answers1

3

The <h:commandXxx> components submit the parent form via a POST request. Any request scoped backing beans referenced in the whole page will be reinitialized during restore view phase. And, when using Mojarra version older than 2.1.18, due to a chicken-egg bug, any view scoped beans referenced in view build time tags/attributes will also be reinitialized during restore view phase.

This is thus fully expected behavior.

The concrete problem here is that those buttons are basically being abused for plain page-to-page navigation. You don't want to perform a postback at all. You merely want to navigate to a different page. For that, you should be using <h:button> instead. This basically acts like a GET link. Additional bonus, the URL in browser's address bar will be reflected to the right URL.

<h:button value="Show batch" outcome="/BatchDetail.xhtml" />
<h:button value="Show messages" outcome="/BatchMessage.xhtml" />
<h:button value="Show both" outcome="/BatchAndBatchMessage.xhtml" rendered="#{batchMessageDetailBean.batch.part}" />

Note that I took the opportunity to improve the conditional rendering by just using the rendered attribute instead of a view build time tag, which not only solves the problem in case you're using Mojarra version older than 2.1.18, but also contributes positively as to "using the right tool for the job".

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thank you for your clear and extensive answer! (and updating my tags) I updated the code and have no problem anymore. Mojarra version is 2.1.19. I'm not sure why the original author chose c:if; 'rendered' is used almost everywhere else. I still wonder though why I did not have the same problem with the other menu option (same code, different way to get there). And why did the 'Show both' button not call the init-method? Still quite new to web applications but your answer taught me a lot! Thanks! Also the URL - current page thing is an issue I need to address. Thanks for showing me the way. – Century Dec 23 '14 at 17:37
  • As to "Show both button", it's either a misobservation, or that button is placed elsewhere in the page, having something else in its context we don't see. An [MCVE](http://stackoverflow.com/help/mcve) would help if you need more detail on that. – BalusC Dec 23 '14 at 19:24