[
http://issues.apache.org/jira/browse/TOMAHAWK-503?page=comments#action_12431082
]
Kevin Galligan commented on TOMAHAWK-503:
-----------------------------------------
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)
RedirectTrackerUtils.trackRedirect(FacesContext.getCurrentInstance());
return "success";
}
'trackRedirect' would just be something like
public static void trackRedirect(FacesContext context)
{
context.getExternalContext().getRequestMap().put("redirectTrackerEnabled",
Boolean.TRUE);
}
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.
> Capture and restore saveState Beans and messages when using redirect
> navigation rule
> ------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-503
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-503
> Project: MyFaces Tomahawk
> Issue Type: Improvement
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: Mario Ivankovits
> Assigned To: Mario Ivankovits
> Attachments: impl.diff, RedirectTracker.java, tom.diff
>
>
> Ok, this is a try to get what is described in the summary.
> The heart of this patch is the RedirectTracker.
> How it works:
> *) In NavigationHandlerImpl when it comes to the redirect the RedirectTracker
> will capture all required (save-state beans/messages) data. The tracker
> appends a special parameter (_rtid=) to the redirect url so the saved state
> can be looked up in an map.
> *) In LifeCycleImpl in restoreView the RedirectTracker will check for the
> special parameter and lookup the map using its value. If an entry was found
> the data will be restored.
> *) In UISaveState every bean rematerialized in restoreState will put it in a
> request-scoped map
> Known limitations:
> *) need to make the number of tracked redirects configureable (back-button)
> currently its hard-coded to 20
> *) some, as I didnt tested it very well
> I added this patch as a base to discuss what could be made better, though the
> goal is to add this functionality to myFaces.
> I hope some else jump in and we get a vital discussion about this topic.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
