you don't need a backing bean per page, if page1 and page2 share same
datas, why not use the same backing bean for both?
I understand. They don't necessarily share the same data. They're dependent on some common data but perform separate functions. The use case I'm describing shouldn't be that abnormal.
no-arguments constructor is indeed part of the definition of the bean
concept :). If your bean are session scoped, they must be moreover serializable. A class can only be serializable if it has a no argument constructor. I understand. So how does JSF allow me to initialize my beans with custom logic (call database, etc) when I am sending a user from page1.xhtml to page2.xhtml after calling a method on Page1.java (which must return a String)?
Let JSF do the initialization stuff itself based on bean definitions made
in faces-config.xml. This doesn't allow me to specify a method call on Page2.java to run my custom initialization logic. Yes, on page2.xhtml I would be able to access properties from Page1.java but this isn't what I'm looking for. I need to load other stuff in page2.xhtml based on data from page1.xhtml.
A form can combine several beans or a bean can be used by
several forms. Agreed. And have used this numerous times in the app. But in a few situations it makes more sense to have separate beans. I'm surprised that there's no way to call custom initializers. In EJB there's a @PostConstruct annotation that calls custom logic after the bean manager creates the bean. Thanks for the ideas and help. Based on what you're saying it sounds like there's no way to do what I'm looking to do? Later, Joe
