Changes between Initial Version and Version 1 of ReferenceMaterials/RequestLifeCycle

Show
Ignore:
Timestamp:
03/16/10 18:43:21 (16 years ago)
Author:
QuackFuzed (IP: 74.196.209.189)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ReferenceMaterials/RequestLifeCycle

    v1 v1  
     1= Model-Glue Event Request Life Cycle = 
     2 
     3The typical Model-Glue event life cycle looks like this: 
     4 
     5 1. The initial event-handler is executed. 
     6 1. Any messages contained within the event-handler are broadcast. 
     7 1. Any results contained within the event-handler are fired, and their events are queued. 
     8 1. Any views contained within the event-handled are queued. 
     9 1. The event queue is processed, and any queued events are executed, repeating steps 2-5 as necessary. 
     10 1. Once all queued events have been executed, all queued views are rendered. 
     11 
     12There are, however, a couple of exceptions to this general rule: 
     13 
     14 1. If a <result /> has the redirect attribute set to true, the redirection to the event will occur immediately when the result is fired. 
     15 1. Events arising from named results (e.g. <result name="resultName" do="otherEvent" >) will be queued before implicit results (e.g. <result do="otherEvent" >). 
     16 
     17Furthermore, when these two cases are combined, the ''redirection will occur at the time that the named result is added by the message listener function'', which could mean that some message broadcasts would be skipped (as would any other results and views). 
     18 
     19As far as event types go, it might be helpful to conceptualize types as "wrappers" for an event-handler. Any broadcasts, results or views that are present in an event type will be merged into the event-handler, and placed either before or after the handler's own broadcasts/results/views blocks. 
     20 
     21Therefore, this configuration: 
     22 
     23{{{ 
     24#!xml 
     25<event-type name="sometype"> 
     26    <before> 
     27        <broadcasts> 
     28            <message name="beforemessage" /> 
     29        </broadcasts> 
     30        <results> 
     31            <result do="beforeresult" /> 
     32        </results> 
     33        <views> 
     34            <include name="beforeview" template="before.cfm" /> 
     35        </views> 
     36    </before> 
     37    <after> 
     38        <broadcasts> 
     39            <message name="aftermessage" /> 
     40        </broadcasts> 
     41        <results> 
     42            <result do="afterresult" /> 
     43        </results> 
     44        <views> 
     45            <include name="afterview" template="after.cfm" /> 
     46        </views> 
     47    </after> 
     48</event-type> 
     49 
     50<event-handler name="someevent" type="sometype"> 
     51    <broadcasts> 
     52        <message name="eventmessage" /> 
     53    </broadcasts> 
     54    <results> 
     55        <result do="eventresult" /> 
     56    </results> 
     57    <views> 
     58        <include name="eventview" template="event.cfm" /> 
     59    </views> 
     60</event-handler> 
     61}}} 
     62 
     63would be functionally equivalent to this: 
     64 
     65{{{ 
     66#!xml 
     67<event-handler name="someevent"> 
     68    <broadcasts> 
     69        <message name="beforemessage" /> 
     70        <message name="eventmessage" /> 
     71        <message name="aftermessage" /> 
     72    </broadcasts> 
     73    <results> 
     74        <result do="beforeresult" /> 
     75        <result do="eventresult" /> 
     76        <result do="afterresult" /> 
     77    </results> 
     78    <views> 
     79        <include name="beforeview" template="before.cfm" /> 
     80        <include name="eventview" template="event.cfm" /> 
     81        <include name="afterview" template="after.cfm" /> 
     82    </views> 
     83</event-handler> 
     84}}} 
     85 
     86== Summary/Review == 
     87 
     88The order of execution for event-handlers is: 
     89 
     90 1. broadcasts 
     91 1. results 
     92 1. views 
     93 
     94A key thing to understand here is that while message listener functions are invoked at the time messages are broadcast, both events added via results and views are queued rather than being executed/rendered when the event-handler is processed.