The point is, JSF isn't about forms. It's a Model/View/Controller framework. The end result of a JSF request is supposed to be that a form is validated, the backing bean(s) are updated, then an action is taken on a backing bean that (usually) takes the updated bean(s) and does something with that data. The only real "form" aspect to it, is that the forms delimit what particular objects are affected when an action is fired.
So first of all, there's more than one type of error. If the data doesn't pass validation, then effectively speaking, it isn't captured at all. if there's a failure in the action processor, the action processor hopefully has a better idea of what to do about it than some external generic logic.
It's a very common failing for JSF beginners to start throwing around lots of calls to arcane JSF functions and constructs. JSF is designed on Alan Kay's principle of "Simple things should be simple and complex things should be possible". Meaning, that except for the JSF model classes, most JSF code should be POJO code. If you've got a complex solution there's a very good chance you're overlooking the simple ones.
Truthfully, it's not wise in any endeavor to try and use all the complex functions when you're not familiar with the basics. Not that I'm innocent on that count, but JSF really is a platform that's supposed to make solutions simple.
Joined: Oct 13, 2010
Ok, I'm with you. I completly agree with you ... but ...
I worked for many years with struts, I know very well MVC ... so, maybe I'm in the wrong way now.
JSF is a simple (easy to use) framework you can make great things with.
I will explain my problem from another point of view, maybe you can give me a solution.
I have to trace user activity and in particular use input (legal stuff ... sorry cannot say more).
"Trace" means that I have to catch pages (it is easy), pressed button (easy) and user input. I'm not supposed to modify and bind each jsf object with a listener to save data when changed. So I thought I could create a "global" listener to do that dirty job for me.
Maybe I have to consider to create a super bean with a method that can dump the content of extended beans.
I see. Well, I've worked in a number of high-security applications and auditability has often been an issue. Normally, however, what we worried about was who was trying to do what. If someone made a questionable move with the context of the application, typically I'd throw a specific exception that reported what the offense was and let the upstream processors log, alert, and/or fire off warheads as appropriate. It was less a concern what specifically they were trying to do as that they were doing it at all and the response was predicated based on the nature of the offense, rather than trying to make it generic.
If you really need to know byte-for-byte what was going on, you're probably actually better just logging the raw network traffic instead of trying to pick the guts of JSF apart (only to have it all break when they do their next architectural revision). That can be done either at the OS level using something the the tcpdump utility or inside the appserver. Tomcat's Valve mechanism is used for things like that.
Oh yeah, speaking of MVC, it's a bit hazardous to say "submit a page" in JSF, since unlike most web frameworks, the URL is a tracking handle more than it is an absolute page locator. Which has been an annoyance to many of us, but that's how it works. Also, you don't "call a method" from a View (notice I avoid the term "page"). You fire an action. JSF isn't like servlets and JSPs where the View is translated into code.