Does anyone know of a way to get persisted values set in setNextEvent to live across a prehandler? I looked thru the posts here and I saw a question regarding setting a value in the prehandler but what about the following:
Handler A event does setNextEvent to HandlerB event / persist something.
Handler B has a prehandler that just checks for a status (like isSSL). If test passes does nothing else. Handler B event referred to above no longer has my persisted rc items however. If I comment out the prehandler they are there. I didn’t see anything anywhere to “forward” these on to the intended action from the prehandler. Am I missing something?
Can you re-word this, first off all RC / pRC variables live from pre-handler to handler as it is all in the same request. However, if you go from one even to another event, that happens to have a pre-handler, then you will need to persist it across events.
After reading the question again, could you provide some code. but your pre - handler should look like this.
function preHandler( event, rc, prc ,action,eventArguments){
}
I just checked the docs on this, against what Luis has in ContentBox and the docs are wrong.
Notice the order in the arguments.
Pre Advice
With this interceptor you can intercept local event actions and execute things before the requested action executes. You can do it globally by using the preHandler() method or targeted to a specific action_pre{actionName}()._
// executes before any action
function preHandler(event,action,eventArguments,rc,prc){
}
// executes before the list() action ONLY
function preList(event,action,eventArguments,rc,prc){
}
// concrete example
function preHandler(event,action,eventArguments,rc,prc){
if( !security.isLoggedIn() ){
event.overrideEvent('security.login');
[log.info](http://log.info)("Unauthorized accessed detected!", getHTTPRequestData());
}
}
function preList(event,action,eventArguments,rc,prc){
[log.info](http://log.info)("Starting executing the list action");
getPlugin("Timer").start('list-profile');
}
Thank you for the replies. I think your first one is really close to what I’m doing.
I’ve put code below but I should note that I realize that what I’m doing for status messages belongs in Messagebox, or at least
messageBox exists to handle them. I’m in the process of switching these over now. Still, sending an rc value from HandlerA.action to HandlerB.action
and having the rc values get deleted because there is a preHandler in HandlerB seems wrong to me, regardless of what I’m using the rc values for.
Yes? No? Thanks! Code below:
******* Handler “A” ***********
****** Handler “myaccount” **********
***** do some stuff *****
.........
Assume we’re passing the SSL test. In that case nothing happens and request moves on to myaccount.view. RC dump does NOT contain “statusError”. If I comment out
the preHandler then it does. Again, regardless of what I’m using it for or how the rc value is set in this example the fact that the rc struct is deleted by a preHandler
seems wrong to me. That’s why I’m assuming I have some setting wrong or something. If not I’m wondering why the piece where the rc struct is deleted can’t be changed to
if NOT preHandler delete structure rc. ??
Your setNextEvent() is only persisting the error results, that means the prehandler will be re-initialised.
When using setNextEvent() that is like a relocation that the user will see in the url, which also means they can hit the back button and go back a few steps, which cold break your app. Personally I would hide it by using runEvent() instead, this means that the url as far as the user is concerned ends up with the final redirect and not the steps in between if that makes sense. The second, I am sure I haven’t double checked this, but as it doesn’t go through the same workflow as setNextEvent() the RC / PRC can persist across to the handler. Reason being is that it will be seen as the same request.
Thanks. In this particular case both of the “next” events are destinations, one being the first page of their application if they have not yet applied and the other their main account page if they already have. The admittedly simple processing event just checks to see if they have applied for the job yet or not. In this case I “think” setNextEvent is the proper way to go.
As far as rc values not making it to the “next event” in setNextEvent when persisted this may not be a bug as it might be intentional but it certainly feels wrong. I’m just too new to Coldbox to say one way or the other.
I’m going to try MessageBox and see what happens as it’s status messages I’m sending over in this particular case. If it was something else, however (almost anything else), I’d be a little concerned about my options.
yeah in that case, your seetNextEvent() is the better option, just wanted to let you know.
As for RC, RC stands for request context, in the same way as the request scope, it only lives long enough for the current request. SetNextEvent() is the same as if the user type it in the url. Hence its relocation, which is basically saying we are send a new request to be run. If you need it to persist to the next request, you need the flash ram or the persist on the setNextEvent() so its inflated into the request.
Value should be persisted across the prehandler. It shouldn’t make any difference. I think the behavior you’re expecting is correct.
What does that SSL check do? Does it do a redirect? Is your test hitting it? If so, that’s where you’re losing it. The flash RAM only works for ONE request. Once it’s reinflated back into the RC, it’s deleted. If the prehandler is whisking your user away to an SSL version of the, page you’re not going to see your persisted stuff unless the prehandler SSL check persists it AGAIN.
I would highly recommend message box. It uses flash RAM under the covers, but it keeps the messages around until they are used which means they can survive redirects.
Use your browser’s network debugging tools to to track if you’re being redirected by the SSL check.
The prehandler would either take a person away in which case I wouldn’t expect the rc values to be there. In my test (post above a few posts) if I am connected via SSL then nothing happens, the prehandler just ends. The rc values, however, do not make it to the intended event which I would expect. Just for fun I’ll make a prehandler that does absolutely nothing, just to be sure.
Well, that’s embarrassing. I didn’t bother to check to see if isSSL() actually returned true when I was connected via SSL. It doesn’t, so yes prehandler was hitting my login and bouncing back as “Logged In”. I thought isSSL() was part of the framework? Now trying to figure out why it’s returning false…