I'm afraid that this isn't quite correct. While the built-in
onRequestEnd event handler is indeed executed after views are
rendered, this is not true of events that are queued by means of a
result tag. The order of execution for event-handlers is actually
broadcasts, then results, then views.

Additionally, a 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.

The typical event lifecycle looks like this:

1. The initial event-handler is executed

2. Any messages contained within the event-handler are broadcast

3. Any results contained within the event-handler are fired, and their
events are queued

4. Any views contained within the event-handled are queued

5. The event queue is processed, and any queued events are executed,
repeating steps 2-5 as necessary

6. Once all queued events have been executed, all queued views are rendered

There are a couple of exceptions to this general rule, the first one
being the case of a result has the redirect attribute set to true --
the redirection to the event will occur immediately when the result is
fired.

The second special case is that of a named result, as events arising
from named results will be queued before implicit results.
Furthermore, when these two cases are combined, then 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).

As 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. Therefore, this configuration:

<event-type name="sometype">
    <before>
        <broadcasts>
            <message name="beforemessage" />
        </broadcasts>
        <results>
            <result do="beforeresult" />
        </results>
        <views>
            <include name="beforeview" template="before.cfm />
        </views>
    </before>
    <after>
        <broadcasts>
            <message name="aftermessage" />
        </broadcasts>
        <results>
            <result do="afterresult" />
        </results>
        <views>
            <include name="afterview" template="after.cfm />
        </views>
    </after>
</event-type>

<event-handler name="someevent" type="sometype">
    <broadcasts>
        <message name="eventmessage" />
    </broadcasts>
    <results>
        <result do="eventresult" />
    </results>
    <views>
        <include name="eventview" template="event.cfm />
    </views>
</event-handler>

would be functionally equivalent to this:

<event-handler name="someevent">
    <broadcasts>
        <message name="beforemessage" />
        <message name="eventmessage" />
        <message name="aftermessage" />
    </broadcasts>
    <results>
        <result do="beforeresult" />
        <result do="eventresult" />
        <result do="afterresult" />
    </results>
    <views>
        <include name="beforeview" template="before.cfm />
        <include name="eventview" template="event.cfm />
        <include name="afterview" template="after.cfm />
    </views>
</event-handler>

(Please excuse any typos.)

Now, as far as the original question is concerned, I must admit that
I'm not clear on what the desired goal is here. You were intending to
use onRequestEnd to add the rendered HTML of the view stack as an
event value, and then retrieve this via the remoting call?

--
Ezra Parker


On Fri, Jan 15, 2010 at 4:52 PM, Chuck Savage <[email protected]> wrote:
> Well I haven't used OnRequestEnd, but I would presume that if your using it
> in a <broadcasts> statement, then it would actually be executed before any
> <views>
>
> I think all <broadcasts> get executed, then all <views>, then all <results>,
> doesn't matter about their <before> and <after>'s as it relates to those 3
> tags, internally, a <before> broadcast happens before an <after> broadcast.
> But an <after> broadcast happens before a <before> <view>.
>
> My solution is only a work-around, not an actual OnRequestStart.  If you
> want a OnRequestEnd,
>
> I suggest moving the call in the Remote type from <broadcasts> to <results>
>
> IE, make an event-handler like so
>
> <event-handler name="OnRequestEnd" access="private">
> do your OnRequestEnd stuff here, broadcasts, etc stuff you want done last
> </event-handler>
>
> Then in the Remote event-type, do this...
>
>>         <event-type name="Remote">
>>             <before>
>>                 <broadcasts format="remote">
>>                     <message name="OnRequestStart" />
>>                 </broadcasts>
>>             </before>
> <after>
>   <results>
>      <result do="OnRequestEnd" />
>   </results>
> </after>
> </event-type>
>
> Since results are run last, and an after result last of all (unless other
> after's are added after), it should run after the view is rendered.
>
> --
> Chuck Savage
> http://SeaRisen.com
>
> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> You received this message because you are subscribed to the Google
> Groups "model-glue" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en
>
-- 
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog

You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

Reply via email to