Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Forward_Event
I just want to clear up my knowledge of the Forward_Event function.
Our old product does not use SRP's Frameworks. The is no Write_Pre support for example.
When I was introduced to OI, I was told inhouse that by the time the code in the Write event in the form was executed the actual write to the DB had already happened. However, in most of the Write events there is some code, then a Forward_Event, then some more code. I was further told that basically this behaved like a Pre-Write-Post situation.
I never really questioned it because I didn't really need to.
Now I am supporting some old code and sort of need to understand the flow.
The doc explains "The Forward_Event subroutine allows the current event to be passed to the next event handler in the current chain. This enables an event handler to implement some processing both before and after the remainder of the event chain."
My question is this:
Using a forward event allows the Write to behave with Pre-Write-Post behaviors? If so, with no Forward event, would that not make the Write a PRE action, not a POST?
Our old product does not use SRP's Frameworks. The is no Write_Pre support for example.
When I was introduced to OI, I was told inhouse that by the time the code in the Write event in the form was executed the actual write to the DB had already happened. However, in most of the Write events there is some code, then a Forward_Event, then some more code. I was further told that basically this behaved like a Pre-Write-Post situation.
I never really questioned it because I didn't really need to.
Now I am supporting some old code and sort of need to understand the flow.
The doc explains "The Forward_Event subroutine allows the current event to be passed to the next event handler in the current chain. This enables an event handler to implement some processing both before and after the remainder of the event chain."
My question is this:
Using a forward event allows the Write to behave with Pre-Write-Post behaviors? If so, with no Forward event, would that not make the Write a PRE action, not a POST?
Comments
NB: In OI10, Quick Events can be set to 'Have Priority'. This moves the Quick Event Handler from the bottom of the event chain to the top. This means the you can move all Script Event Handler code, that may have been necessary for any PRE event chain processing, to a centralised commuter routine instead.
HTH, M@
I read that once upon a time but obviously need to take a fresh look.
The SRP Wiki looks to be down at the moment so I will check that later.
Don did mention last year that OI10 having the ability fire Quick Events first was needing to be looked at for what that means for Frameworks. We aren't on 10 yet so I never chased up that particular comment with him.
Thanks for mentioning about the Wiki being down. I had to restart the server. It should be back online now.
Using a forward event allows the Write to behave with Pre-Write-Post behaviors? If so, with no Forward event, would that not make the Write a PRE action, not a POST?
M@ gave an excellent answer so I won’t be improving upon it. But I would like to make a pointed comment related to the question. A Script event handler is *ALWAYS* a pre-event action. Full stop.
Except you have improved on it ;) . It would be better to say that a Quick Event that Has Priority immediately follows the Script Event Handler in the event chain, right?. So the complete picture would look like this:
(Excuse me hacking your diagram ;)
@DonBakke, that has been the source of my confusion. There was a miscommunication/bad info in my early days that I kept remembering that wasn't gelling at all with what I was seeing.
I love a good diagram @MattCrozier!
I obviously knew the hierarchy of applications but I cant say I thought too much about hierarchy of Control vs Event. It makes total sense if you stop and thing about it for just a second though..
That is right. I'm happy to see that your hacked version of our diagram is also correct in that you removed the Quick Event that would ordinarily appear at the tail end. The reason for me calling attention to this is that a QuickEvent either has priority or it doesn't, but it can't be both. That is to say you can't have a pre-System Event QuickEvent and a post-System Event QuickEvent for the same event chain.
In the early user conferences when the new priority feature for QuickEvents was being introduced, I had notes suggesting that it would be possible to have two types of QuickEvents for the same event chain. This would make it possible to have modular control over the event chain simply through QuickEvents (and commuter modules). When the product was released, I was disappointed to learn that this wasn't the design intent.
The upshot is that if give your QuickEvent priority, then you'll still have to rely upon Forward_Event() to execute the System Event handler (and other inherited event handlers) and then have it come back so you can execute any "post" event logic.
I always found it helpful to remember that the more unique an event handler is the sooner it will get called in the event chain. There is nothing more unique that an event handler for a specific event for a specific control on a specific form within a specific application.
I've always felt pretty unique.
But I suppose maybe not quite as unique as that description.
Maybe I should make a habit of being more specific.