Roy, I think I understand what you are saying. I want to think more on this because what you are saying is interesting.
I must say though, as you pointed out, you've brought this issue sort of on yourself by choosing very generic names like 'class'. I assume there is a very good reason why you've chosen to use class in both the message being broadcast and the included template, and why those values are different. I'd like to hear more specific use cases if you please. DW On Wed, Jul 8, 2009 at 4:33 PM, Roy Martin <[email protected]> wrote: > We use arguments pretty extensively within our model-glue applications to > make broadcasts and includes as generic as possible. We even have cases > where the event-handlers are automatically generated which pass in set > arguments as flags for options. The problem we run into quite often is when > an argument that is specified for the message has the same argument as the > one in the include. For example, notice the use of class for the message and > the view in the example below. I understand why this is, both of the values > share the same scope, values, and when the view in rendered it effectively > overwrites the value when the function is actually run. This has been a > major hurdle for us and we're constantly having to rename, or make > exceptions to accommodate for this, which is usually in the form of. > arguments.event.getValue(arguments.event.getValue('className', 'class')) - > get the value for the passed in name of the value your trying to get (dumb) > > One resolution that I would propose is that the arguments that are passed > to specific broadcasts or view are stored within a scope relative to the > name. So that when I specify an argument within the message name ( ex: > argument class with broadcast 'getNavigationByStaticId') it stores it as > something to the effect of getNavigationByStaticId.class, and then the > arguments.event.getValue looks to see what event broadcast triggered the > call and looks for that scope, in additional to the standard scope. > Likewise, the viewstate.getValue would collapse this as well on the > front-end. This would keep it from breaking existing functionality, but > prevent this overlap. If not this, then what are some other ways to solve > this? > > If perhaps some of this was addressed in MG3, please just point me to it as > this is a specific thing I've noticed from MG1-2. > > Thanks, > Roy > > > Example problem with class overwriting: > <event-handler name="page.main.static"> > <broadcasts> > <message name="getNavigationByStaticId"> > ........ > * <argument name="class" value="" overwrite="true" />* > </message> > </broadcasts> > <views> > <include name="sidebarNav" > template="/navigation/dspNavigationMenu.cfm"> > ..... > * <argument name="class" value="vlist" overwrite="true" />* > </include> > <include name="body" template="/static/dspStatic.cfm" /> > </views> > <results> > <result do="view.template" /> > </results> > </event-handler> > > > > -- “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 --~--~---------~--~----~------------~-------~--~----~ 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 For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
