I am upgrading our project from MyFaces 1.1 and JSPs to JSF 2.0 and Facelets. I was using Apache Shale, and have all kinds of isPostBack() checks in the overridden init() methods of Shale. Obviously Shale is no longer supported, let alone needed, so I am ripping all of the Sale usage out. My thinking is I would simply place a call to the overridden init() methods in my constructor and replace Shale's IsPostBack() with that of the FacesContext. I am now using the IsPostback() method of the FacesContext to perform this check, and the problem I am having now is this method is always returning true. Even when navigating to a new page, I still receive a true for the isPostback() check...
I am using the JSF 2.0 framework and running on Tomcat 6.0.14. I also added the following .jars to Tomcat's lib folder:el-api-2.2 & el-impl-2.2, per Cay Horstmann and his JSF 2.0 and Tomcat blog.
The application runs fine, other than the problem described and there are no errors in the logs.
You're making me glad that I made a clean break from Struts to JSF and didn't attempt to use any of the interim approaches.
On the downside, however, this means that I can't give you any advice as to the details of your particular problem.
I can however, repeat the axiom that I tell everyone in this forum:
If you're using any javax.faces packages other than the faces model classes, there's a good chance you're doing things the hard way.
JSF is designed to embody Alan Kay's assertion that "Simple things should be Simple, and Complex things should be Possible". Altogether too often, people start mucking around with stuff specific to JSF's innards that could be done much more cleanly using POJO code. And, as you have seen to your pain, the next time a new platform comes along, that means a lot of work to replace all that cleverness. Whereas a POJO is a POJO, no matter what platform you're using.
An IDE is no substitute for an Intelligent Developer.
Joined: Nov 24, 2010
Thank you Tim for your time!
Just to be clear. I have now ripped out all of the Apache Shale stuffs. That said, I am still using Tomahawk for simple things like <t:htmlTag></t:htmlTag>.
If I may ask a more specific question regarding my problem, the FacesConfig.IsPostback() is supposed to return false on a "first time" navigation to the page, correct? In other words, work the same functionality as Apache Shale .
Also if I may, what or how do handle object initialization on "first time page loads"? Are you using the FacesConfig.IsPostback() check?
I only used isPostback() once long ago and I don't remember what the details were, although I believe it was in a PhaseListener (something else I don't often use).
Go back about 2 years in this forum and you'll find a lot of discussion on "page load" initialization, though. It's a popular topic.
For the most part, I don't go that route since it's subject to issues relating to things like the "Back" button so I do "page load" based on workflow rather than technical issues. So my most common strategy is to have an internal init() method that resets the session-scoped backing bean to the state that it should be in when a workflow process starts. The Views in the workflow usually are presented as a result of an action on some other backing bean, so they frequently invoke a "beginXXX()" method on the workflow's backing bean and the "beginXXX()" method usually sets up the workflow context (such as new/edit and which item to edit) and that often begins with a call to the workflow bean's init() method.
For direct URL access, I normally use PrettyFaces, which invokes an action method as part of the bookmark URL retrieval process, so the same general idea applies. It's been a long while since I've invoked a View directly via an HTTP GET request, but of course, that would suggest that I look at the request type and determine that it was a GET rather than a POST(back). And that would require javax.faces voodoo, since I'd have to get the HTTP context via FacesContext. But I usually have a generic utility class I use for stuff like that so I can keep the javax.faces code out of the backing bean. Which gives the additional benefit of allowing me to unit test a backing bean without having a web browser running or even a fully-constructed WAR.
Incidentally, historically, the lifetime of a session-scoped backing bean was too long to reliably handle First View without jumping through hoops, and request scope wasn't long enough. However, in JSF2, there's a View Scope and that should serve most purposes. A PostConstruct() method is useful in that context.