ICEfaces: How to disable send-receive-updates mechanism for some forms

Question

I am quite new to ICEfaces but already have experience with JSF/Facelets and the Java EE in general.

Currently, I am not using to much of ICEfaces except some utility tags like outputStyle and outputDeclaration, but even this is really nice to have.

Even though I plan on using some AJAX functionality later, I have some h:forms (or ice:forms) which I would like to send as normal JSF POST requests, without going via /block/send-receive-updates. The reason is, that I want to use a filter, which acts on the requested URI, which is impossible if everything is sent to /block/send-receive-updates.

Is there some way to do this?

Edit: To clarify what I want to do:

The web site we are developing consists of publicly available pages and some which only registered members can access. The standard FORM-based security mechanism as defined in the servlet standard is pretty inflexible, as it only allows to define a single login page which is shown, when someone wants to access some restricted content. Because we also want to user to be able to log in by using a small login form visible on every page, we developed a filter, which handles authentication and authorization almost like the web container. It redirects to a custom login page if the user is not authenticated/authorized, but also allows to authenticate a user from a backing-bean. To make it work almost transparently it wraps the HttpServletRequest to supply the Principal and the user roles.

When the filter redirects to the custom login page it saves the current request to "replay" it later, when the user has been successfully authenticated. To do this, the filter has to be able to detect, if a POST request came from the login page (and thus if the user is now authenticated/authorized). But if every POST is going via /block/send-receive-updates this doesn't work anymore.

Of course I could exclude the login page from being handled by ICEfaces, but this would mean I couldn't use any ICEfaces/AJAX on the login page.

Answer 1

I've been using IceFaces for nearly a year now and haven't yet come across any way of submitting the form without going via send-receive-updates. But I'm curious, you say "I plan on using some AJAX functionality later". The point of IceFaces is that it pretty much transparently adds AJAX to your JSF app. It's an "all or nothing" kind of thing - any page you have which uses IceFaces will use AJAX.

The only thing I can think of you could do is not use IceFaces for the pages you want to use POST requests on - i.e. you could map IceFaces pages to *.iface, but normal JSF to *.faces.

Alternatively, there may well be some other way of accomplishing what you want to do with filters.

Answer 2

This might not be the best way of doing this, but it might be a way. I'll assume, for the sake of argument, that your header holds your extra login form. If you were to make your header in either a seperate frame or in the main layout page and imbed your JSF pages into an iframe, this might work. The idea being that since it's being rendered as a seperate page, you can handle it in a seperate way.

Also, there might be a different way of handling your security that would make this more IceFaces-y. Perhaps, when you hit the filter and it determines that you're not logged in, it should create a bean (probably session) which holds the information from the original request (URL, parameters, etc.) and the sends you on to the login page. The login page does its thing, adding your security stuff, then uses the information in that session bean to force a redirect to your new page. You can use the FacesContext to get your HttpContext and do a redirect. You'd probably need to play around with the redirect to add any appropriate parameters. Lastly, you should get rid of the session bean.

Finally, I know that there are a couple of Frameworks (Spring WebFlow, springs to mind) that will save your request state, let you do the login, and redirect you back to where you were going in the first place pretty seamlessly (which, reminds me, I think Seam can do this too. Probably Orchestra and your other frameworks as well.)

Hope this helps!