On 4/14/06, Werner Punz <[EMAIL PROTECTED]> wrote:
If that is indeed what the original poster wanted, then I hope the original poster will realize that what he/she wants is *not* what the HTTP specs say a GET request should do. In particular, a GET request should be idempotent -- it should be no problem to repeat the request multiple times (no fair charging my credit card again if this happens to be the checkout page of a shopping app), and you should (in general) get the same results each time you invoke the same URL via a GET.
Applications that are based on GET requests that process form submits, then, should generally be considered broken, as far as the HTTP spec is concerned ... and that is not anything specific to JSF.
What matters for JSF and GETs is to be able to create bookmarkable URLs for idempotent requests ("show me the current items in my shopping cart" or "show me the current items that match my most recent query"). No, that is not the default behavior of links created by the standard "command" components. But yes, it is easy to do the same thing you would do in any other framework to deal with such requests. Indeed, because of the managed property ability to do dependency injection on backing beans, it is actually *easier* to deal with this kind of situation than it is in something like Struts 1.x.
Adam Winer schrieb:
> Mike,
>
> What do you mean by "not supported in the core"?
>
> A GET request turns into an initial render request - no
> phases other than Render Response - but Jacob's entirely
> correct that JSF *does* support GET, and you can funnel
> request parameters directly into your managed beans.
> This is definitely supported by the core, required by the
> spec, etc. No theory here.
>
I think what the original poster wanted was to have the entire form and
event handling based on get, that is not possible with the current state
of components to my knowledge unless someone writes a get parametrizable
form.
If that is indeed what the original poster wanted, then I hope the original poster will realize that what he/she wants is *not* what the HTTP specs say a GET request should do. In particular, a GET request should be idempotent -- it should be no problem to repeat the request multiple times (no fair charging my credit card again if this happens to be the checkout page of a shopping app), and you should (in general) get the same results each time you invoke the same URL via a GET.
Applications that are based on GET requests that process form submits, then, should generally be considered broken, as far as the HTTP spec is concerned ... and that is not anything specific to JSF.
What matters for JSF and GETs is to be able to create bookmarkable URLs for idempotent requests ("show me the current items in my shopping cart" or "show me the current items that match my most recent query"). No, that is not the default behavior of links created by the standard "command" components. But yes, it is easy to do the same thing you would do in any other framework to deal with such requests. Indeed, because of the managed property ability to do dependency injection on backing beans, it is actually *easier* to deal with this kind of situation than it is in something like Struts 1.x.
But we all know how much limitations such an approach imposes and that
it causes more problems than it really solves.
Craig McClanahan
