Mark Collette says:

It seems that just like how there's outputLink, that does a non-Ajax GET,
we need outputButton, or a flag on commandButton, that would do a
non-Ajax postback. There's got to be times where you'd want to postback
against the current view, but want a full page refresh as the response.

So the prescribed fix for this is to add a new attribute to the ice:commandButton (and commandLink) components to optionally force the submit to be a non-Ajax GET, instead of the usual ajax post-back.

The attribute could be called "useGetForSubmit" (boolean).

Arran, is the customer wanting to do a GET or a POST? If they want to do a GET, that's just an application change. But if they want to do a non-Ajax POST, then that may require some component and framework changes. The risk potential is highest in the framework.

They would like to do a POST so that the form values are not shown in the URL.

The suggested application work-around is to use just-ice.jar, instead of icefaces.jar. The login page would only use h: components, and f: tags, and potentially ui: Facelets tags, if they're using Facelets. Every other page can not use h: components, but would instead use ice: components, as well as the f: and ui: tags. The login would then trigger a redirect to an ICEfaces page. Transitions to the login page should use redirects as well.

In ICEfaces 2, this may be solved by the ace:fileEntry. It uses a regular POST to submit the form, when an h:commandButton is clicked. All you'd have to do is add the ace:fileEntry, and make it invisible, and then the form submit would use this mode. We could even refactor out the form submission code, so that it could be enabled via an attribute on the form, and not require the ace:fileEntry at all.

Fixed in ICEfaces 2.0 ace:fileEntry component.