I've started using the patch I put in, and the whole thing is quite useful. I've really been wanting this redirect state type of thing for quite a while. Very cool.
I just posted another patch with another semi-hacky addition. The '_rtid' param worried me because its a simple numeric, so a user could just change that value with undefined results. I took the easy route and appended a dash and the current timestamp. Significantly more difficult to just type in a different value. Would be better with a random number, or even a hash (although, in theory, a hash would have the astronomically small chance of a duplicate, so I think either [request #]-[timestamp] or [request #]-[random] would be best).
Please keep me posted as to additions or changes.
-Kevin
On 8/30/06, Mario Ivankovits <
[EMAIL PROTECTED]> wrote:
Hi!
> http://issues.apache.org/jira/browse/TOMAHAWK-503
>
> This patch is really meant to start discussions about ideas rather
> than be the actual implementation. But, again, it works.
I plan to allow to add a REDIRECT_POLICY parameter which accepts a
FQN-classname and two implementations for it:
TrackRedirectAlways and TrackRedirectManual
In case of "Manual" you can use methods like those from Kevin's patch
(btw, thanks for this patch)
Hmmm ... The plan is, that it should eventually be possible to have a
e.g TrackRedirectNavigational implementation where you can intercept the
navigation redirect url and e.g . react on special added redirectTracker
hints - e.g. /to/view.jsp|trackRedirect=true or
/to/view.jsp|trackBeans=myBean1,myBean2
Not sure whats required to make this work, at least its a plan ;-)
Ciao,
Mario
