Scott Leberknight's Weblog

I managed to read a couple more pages of Core JavaServer Faces today and couldn't believe it when I read that JSF only supports POST requests for forms because apparently you can store session state on the client in a hidden field; this is apparently done automatically by JSF. Therefore since the contents of that field "can be quite large" you could possibly "overrun the buffer for request parameters." Are you serious? So for every form you create in JSF you must POST the submission? That is simply unbelievable. There is a reason there are both GET and POST requests - they are for different types of actions. Why in the world a framework would force you to (mis)use POST for every form submission is utterly beyond me. Then again, I suppose if you buy into the whole "JSF applications should be created using specific tools like Sun Studio Creator" model, then you probably either don't care what code is generated, wouldn't understand it anyway, or don't even realize there is a difference between GET and POST requests. If there weren't any difference, then why do Servlets have both doGet() and doPost() methods?

I would have thought the people designing JSF would know better than this. Spring MVC for example recognizes the distinction between GET and POST requests, and its AbstractController permits disabling GET and POST requests via a supportedMethods property, which by default supports HEAD, GET, and POST methods. In addition, Spring's AbstractFormController defines separate lifecycles for GET and POST requests, taking the viewpoint that GET requests typically correspond to "edit" operations while POST requests correspond to "save" or "delete" operations.

Finally, the fact that JSF doesn't even give the developer a choice just seems to be more evidence that it was designed for tools and not with developers in mind. And the implementation of storing client state in some gigantic hidden field seems ludicrous. That would mean you would need to have a form on every single page of a web application in order to carry that state around. To me that is just a poor design decision; it is certainly possible (and preferred) to design web applications with a minimum amount of session state. About the only things I ever store in session are User objects representing who the logged on user is. Sometimes I'll simply store the user's database id. Everything else that the view needs can be setup per request and set as request attributes. The only caveat is that I often store global data, e.g. for drop-down select lists and other rarely-changing reference data, in application scope. But seriously, is this really going to be the way the standard J2EE web framework works?