No, we decided against adding redirect options to the event-mapping
command. If it's directly reference in the wiki (not tickets, as
tickets usually have discussion), please let me know the entries so that
can be corrected.
Brian H. said the following on 07/21/2009 02:09 PM:
> Last I've hard, there is only support for a new (in 1.8) "redirectEvent
> ()" method at the listener level. This is an improvement, but I think
> that defining that kind of flow is best expressed at the config level
> through the event-mapping tag. Anyone else agree?
The real question is take this code:
<event-handler event="...." >
<event-mapping event="denied" mapping="redirect_to__Site.ViewDenied"
redirect="true"/>
<event-mapping event="accepted" mapping="redirect_to__Site.ViewAccepted"
redirect="true" />
<notify listener="ContactsListener" method="........"/>
</event-handler>
How would you use the "denied" mapping? Would you use announceEvent()
or redirectEvent() methods?
* If you use redirectEvent(), then the redirect attribute of the
event-mapping command is merely nothing but "information".
* If you say you would use announceEvent(), then you're fundamentally
changing announceEvent()'s behavior of announcing a new event to add the
event-queue. It's single purpose of event announcement is turned on the
head and suddenly you are changing it to act like redirectEvent() only
when using an event-mapping with an attribute of "redirect". Performing
a redirect is *not* like announcing an event.
Another thing is that if you are not looking in the XML and just looking
at the listener code, changing the behavior of announceEvent() to do a
redirect is confusing until you look at the XML and realize that there
is an event-mapping with a redirect attribute.
Lastly, the event-mapping command is no long a single purpose command
that just declares event mappings as it could now include directives on
how the event-mapping should be used.
In the end, we decided that adding redirect="true" to event-mapping
fundamentally changes the behavior of announceEvent() and <announce>
command (because it would apply here as well) and altered the concept of
announcing an event versus performing a redirect.
In the end we decided to leave things in which there is are clear
boundaries in the behavior of things. With the addition of
redirectEvent(), event-mappings can either be another event announcement
or a redirect (via the methods or the respective commands).
> This way the
> listeners can simply go on with "announceEvent("accepted")" all the
> while oblivious to the fact that we are actually issuing a redirect
> instead of pushing that flow logic down into the listener layer.
>
Well, the same argument would apply from above that if you use
announceEvent() method in conjunction with an event-mapping as you
couldn't tell if announceEvent() will do the plain old even announcement
or magically do a redirect by just looking at the listener code. The
XML declarations / map is great and provides a great overview, but in
certain circumstances you do have to look at listener / filter / plugin
code to see whatever going on completely. It's part of developing an
application. Also, in general if you do a lot of "pass" / "fail" type
event-mappings, you can just document as best practice that you will
always do a redirectEvent() in your listener.
If you really want to show everything in the XML, you can take advantage
of the EL syntax in available in the redirect command:
<event-handler event="...." >
<event-arg name="xeDenied" value="redirect_to__Site.ViewDenied"/>
<event-arg name="xeAccepted" value="redirect_to__Site.ViewAccepted"/>
<notify listener="ContactsListener" method="........"/>
<redirect event="${event.xeResult}" />
</event-handler>
Your listener wouldn't do an announceEvent() or redirectEvent(), just
merely set an event-arg named "xeResult."
<!--- If everything passed --->
<cfif errors NEQ true>
<cfset arguments.event.setArg("xeResult",
arguments.event.getArg("xeAccepted")) />
<!--- If something failed --->
<cfelse>
<cfset arguments.event.setArg("xeResult",
arguments.event.getArg("xeDenied")) />
</cfif>
Since this shows everything in the XML without any additional code or
wonky stuff (just using event-args instead), this is another reason why
we felt in addition to the argument above, it just wasn't a good idea to
fundamentally change the behavior of event-mappings.
Hope this answers your question.
.Peter
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to Mach-II for CFML list.
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/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
-~----------~----~----~----~------~----~------~--~---
