I think you are mixing things up a bit. An application can only respond to a single event at a time, you can not send more than one event to the application simultaneously.
Originally posted by HarryF
Been thinking about the problem of how deal with multiple events. My opinion is the best way is to handle them in the ordered they are gathered from various sources (my first attempt dealt with them in the order they were registered - in other words how they appeared in Vincents $events array above). So if we use something like phils classes up there, perhaps in a single class called EventReceiver, extending Vincents example it might be
Same here. Since the web is - by nature - stateless, any event or request is standalone. Of course we use things like sessions to maintain state, but in essence it is still stateless.
Originally posted by voostind
The second case is, I think, much more common: an event is triggered, which in turn triggers another event. A user selects the page 'documentation', and on that page he selects the 'introduction' section. The 'section' event table makes no sense for any other page than the one with the documentation. This case can easily be solved by using an EventTable inside a triggered event. Events can be nested infinitely, as long as they aren't based on the same name.