To add one additional wrinkle here, a little while back we added an "extensible" attribute to event-handlers that alters the default overriding behavior. This was actually done to address a backwards-compatibility issue from Model-Glue 2 in regards to the built-in modelglue.onRequestStart, modelglue.onQueueComplete and modelglue.onRequestEnd event-handlers, but it can also be leveraged in user-defined event-handlers as well.
In a nutshell, if you have two event-handlers with the same name, and the first one has the "extensible" attribute set to true, then the messages, results and views of the second event-handler will be appended to the first instead of the second event-handler replacing it. This also has not been documented yet, I'm afraid -- one of the items on my agenda for the upcoming 3.2 release is to ensure that the documentation is completely up-to-date. -- Ezra On Fri, Jun 4, 2010 at 8:03 AM, Dan Wilson <[email protected]> wrote: > It works like a variable does... if you define a variable then define > another variable later on in the chain of scope and then the last one wins. > We haven't thought of using a final attribute. I'll let the team weigh in on > the merits of that. > As far as an example of using this technique... I use it in a lot of my > applications, but I don't have anything simple enough for an example. All > you have to do, however, is use the include tag to include another file. As > long as both have an event handler with the same name. > > DW > On Fri, Jun 4, 2010 at 10:52 AM, David J Henry > <[email protected]> wrote: >> >> Interesting. I see the potential value there. With great power comes >> great responsibility. This opens up the door for me to override my >> event handlers unintentionally. Maybe this won't be such a bad >> problem if I stick to a consistent naming scheme for events. I'll >> have to wait and see how frequently I sabotage myself in the future. >> >> Is there any way to mark an event-handler as "final" such that it can >> no longer be overridden? Perhaps instead an error could be added if >> an event-handler is defined more than once in the same ModelGlue.xml? >> This would be similar to how you can override a function from a cfc >> that you are extending but you cant declare the same function twice in >> the same cfc. >> >> >> Could you point me to an example of extending an application by using >> multiple ModelGlue.xml files? I'd like to add that to >> http://docs.model-glue.com/wiki >> if it isn't there somewhere already. >> >> Thanks, >> David >> >> On Jun 4, 10:23 am, Dan Wilson <[email protected]> wrote: >> > You are asking good questions. >> > >> > Event Handlers are built to override event handlers of the same name. >> > >> > This means, you can provide a set of event handlers for an application, >> > then >> > include another ModelGlue.xml file that will override the original event >> > handlers. When used effectively, this technique can really be powerful. >> > You >> > can have a Core application and then override what needs to be changed >> > in an >> > application-specific file. >> > >> > DW >> > >> > On Fri, Jun 4, 2010 at 10:16 AM, David J Henry < >> > >> > >> > >> > >> > >> > [email protected]> wrote: >> > > What is the expected outcome of two event-handlers with the same name >> > > in ModelGlue.xml? >> > >> > > Unless I am misinterpreting what I am seeing, it appears the first >> > > event-handler is completely ignored. I would have expected the second >> > > one to add/combine to the first one or both event-handlers to fire in >> > > sequence or at least an error message. >> > >> > > Is there some reason behind this or it just the way event-handlers >> > > were built? >> > >> > > -- >> > > 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]<model-glue%2bunsubscr...@googlegrou >> > > ps.com> >> > > For more options, visit this group at >> > >http://groups.google.com/group/model-glue?hl=en >> > >> > -- >> > William Osler - "We are here to add what we can to life, not to get what >> > we >> > can from life." >> >> -- >> 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 > > > -- > William Osler - "We are here to add what we can to life, not to get what we > can from life." > > -- > 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
