I could... provided I really understand it. : ) Once I get thru the piece I'm working on I'll cut out that section and see if it makes a decent demo.
Thanks again. Irv On Jul 26, 10:50 am, Dan Wilson <[email protected]> wrote: > Hey Irv, > > That would be cool to have a demo of the differences in the results. Are you > interested in putting something together, now that you understand it? > > DW > > > > > > > > > > On Tue, Jul 26, 2011 at 1:49 PM, Irvin Wilson <[email protected]> wrote: > > It does - mostly. I guess I had in my head that, using security > > functions as an example, the controller would be designed to do > > whatever verification desired and then, if failed, jump to cfreturn > > and return whatever values set, including any result messages. The > > way it works seems fine to me though. I just couldn't figure out why > > half my controller function was not executing. I'll certainly fix > > what I have to work within the framework. > > > As an additional thought I think a demo of result redirect="true" vs. > > result redirect="false" would be handy. I refer back to the > > plantpeople demo and the other one from time to time. For some reason > > that piece has never quite clicked. It seems to me the default would > > be "true" since that just feels like it'd be the much more common > > setting between the two. > > > Thanks for the reply! > > > Irv Wilson > > > On Jul 26, 10:36 am, Dan Wilson <[email protected]> wrote: > > > The intent of this feature is to allow the developer to add a result that > > > alters the process flow. Take an event requiring authentication, for > > > example. > > > > The process would be: > > > > - User accesses an event requiring administration permissions. > > > - Model Glue code verifies user has required permission. > > > - If user has required permission, the Event Handler completely > > executes > > > giving user access to secured page. > > > - If user does not have required permission, user is redirected to the > > > login page. The use of Result w/ Redirect=True immediately stops > > processing > > > and transports user to log in page. > > > > So the result with redirect=true is used to halt the normal processing of > > > the event flow. If this did not happen, or if it happened after the event > > > was rendered, your unsecured user would be accessing secured event parts. > > > > For documentation: > >http://docs.model-glue.com/wiki/ReferenceMaterials/ModelGlueXmlRefere... > > > > Note the optional Redirect parameter notes.... > > > > Make sense? > > > > On Tue, Jul 26, 2011 at 1:20 PM, Irvin Wilson <[email protected]> wrote: > > > > I just learned something that I'd like to make sure I understand. (mg > > > > 3.1) > > > > > If you use arguments.event.addResult("blah") anywhere in a controller > > > > it appears that execution stops for that controller. At least that's > > > > the case if redirect="true" is set in the modelglue.xml results entry. > > > > > If this is correct I guess I'm wondering why. My controller is > > > > calling a model cfc that adds a record. I then check for success. > > > > Regardless of whether I succeed or fail I want to do a couple of other > > > > things prior to return. These don't fire. I tested by putting in > > > > cfabort immediately before and then after the addResult. Before will > > > > halt. After gets ignored so addResult is definitely returning to > > > > modelglue.xml and ignoring what comes after. > > > > > I guess I can just set a var or two with values based on success or > > > > failure and then do addResult at the bottom but seems clumsy. > > > > > Am I looking at this the wrong way? > > > > > Thank you! > > > > > Irv Wilson > > > > > PS. I did find an entry several years old using older version of mg > > > > where the poster was showing that entry order was important (set value > > > > prior to set result) for the same reason. It just seems odd. Seems > > > > cfreturn would return whatever result messages are set. Having them > > > > go back prematurely seems like a bug although I'm sure it's > > > > intentional. thx. > > > > > -- > > > > 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 > > > > -- > > > Plutarch - "The mind is not a vessel to be filled but a fire to be > > kindled." > > > -- > > 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 > > -- > Plutarch - "The mind is not a vessel to be filled but a fire to be kindled." -- 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
