Jeremy, First off, thank you for pointing out the omission of the redirect attribute in the event-type documentation. I went ahead and added the attribute to the examples, but I'm not sure if this is the best place to detail the differences in the behavior of the result tag when this attribute is used, as this page is really intended to explain the use the event-type feature. (I could well be wrong though -- perhaps a brief note drawing attention to the redirect would be helpful?)
Would you mind taking a look at the explanation of the result tag in the XML reference? I'd be curious to hear if you had any suggestions for improving the description of this tag: http://docs.model-glue.com/wiki/ReferenceMaterials/ModelGlueXmlReference#result To be clear on how this works, if the redirect attribute is not used, then the event specified in the result tag is added to the event queue for the request, and any queued events are executed in order after the initial event completes. Otherwise, using the redirect attribute will halt processing of the current event by using <cflocation> "under the hood" to re-route to the indicated event. As far as Dan's suggestion goes, I believe that he means you can do something like this in your event-type XML: <message name="CheckRole"> <argument name="requiredRole" value="staff" /> <argument name="notLoggedInEvent" value="user.login" /> <argument name="invalidRoleEvent" value="user.noPrivs" /> </message> And then in your controller function, instead of using the addResult() method to fire a named result, you would do something along the lines of: <cfset var requiredRole = arguments.event.getArgument("requiredRole") /> <cfset var notLoggedInEvent = arguments.event.getArgument("notLoggedInEvent") /> <cfset var invalidRoleEvent = arguments.event.getArgument("invalidRoleEvent") /> <cfif isLoggedIn() is false> <cfset arguments.event.forward(notLoggedInEvent) /> <cfelseif hasValidRole(requiredRole) is false> <cfset arguments.event.forward(invalidRoleEvent) /> </cfif> The point here would be that you are defining the target events in your XML config, so if they need to be changed, you don't have to touch the controller method, and the documentation of your application's flow is still present in the XML. Let me know if any of this is unclear or could use some further explanation. Thanks, -- Ezra On Mon, Oct 19, 2009 at 2:36 PM, Jeremy Prevost <[email protected]> wrote: > > Dan, > > I think I see where you are going with this and I am very much > interested in a code sample. No hurry though (i.e. please don't try to > write it on a Blackberry!) > > Thanks, > Jeremy > > On Oct 19, 4:22 pm, Dan Wilson <[email protected]> wrote: >> You could also do something on your controller. >> >> Look for the condition and use event.forward() to handle the redirect there. >> >> For better documentation purposes, you can use an argument to your >> message to store the event you wish to forward to, preserving the >> application blueprint.. >> >> I'm on my blackberry, so I'll avoid the long code sample. Let me know >> of you'd like a more full technique. >> >> Dw >> >> -- >> “Come to the edge, he said. They said: We are afraid. Come to the >> edge, he said. They came. He pushed them and they flew.” >> >> Guillaume Apollinaire quotes > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
