I've been playing around with this for a little bit and have some thoughts. The first thought is this is great and I've felt something like this is needed. However, I think the functionality needs to be configurable. There are several general use cases where this would be very helpful, but also situations where this becomes a problem.
The first general issue I'm concerned with is related to the following:
"I think it would be VERY nice if we get myfaces to work with <redirect the same way as without"
I think this would be true is certain situations, but just making '<redirect/>' the same seems like it would actually break the JSF implementation. In concept, myfaces sits on top of and extends the standard jsf implementation. This, however, alters the base of functionality. I would think it would be better to allow redirects to carry state information, but it should be explicitly turned on rather than just happening.
1) Want to break state completely. This is the "standard" situation. You redirect, and all page and request level state is lost. This is useful if the user has completed a full "page cycle" and they are being redirected to a home page of sorts. In fact, with are recent application I had some issues with using a redirect and expecting the state to be completely refreshed. Bad coding? Maybe, but still. I was expecting it to work a different way.
2) Want to post a message, but otherwise drop state. For example, adding a new "Account" record. When its done, the user would be returned to the "Account List" page, but a message like "Account added" should be posted to the top. All other request state, however, should be lost.
3) Full requst state retained. This allows the "correct" url to show up in the browser, and allows the user to hit "Refresh" without the double post problem.
I think there should be some way of turning this on and off for particular requests. In fact, I think it should be more like by default it functions as it does currently, and must be explicitly turned on to carry state. I'm not sure how that would be configured. The "natural" place would seem to be in the config file, but I don't really like the idea of either changing the config file format or adding custom info to the url.
Another method, that would be a little more "hacky", but functional would be to add a special key/value to the request map, and test for it in the 'redirect' function of the 'RedirectTrackerExternalContextWrapper'. So, if you have a function that performs something, at the end just put something like the following:
public String someFunction()
.... (the code)
'trackRedirect' would just be something like
public static void trackRedirect(FacesContext context)
This of course clutters the code with UI specifc issues, but I think its workable from a purely functional perspective. Thoughts?
Also, I think it might be a good idea to use an id number that's a little more obfuscated. Having a low numberd sequential id means somebody is going to start messing around with it manually.