That's what I get for hacking at midnight. For some reason I just assumed that the code inside the executeEvent method was returning a result to the browser and therefore in order to override it one had to duplicate the entire method in the local RemoteService. That's what I was doing, after which I realized that it would be better to refactor the AbstractRemotingService.
Your approach is much easier. Thanks! Cheers, Bob On Wed, May 19, 2010 at 6:17 AM, Ezra Parker <[email protected]> wrote: > Hey Bob, > > Yeah, I've run into this as well, and the last time I hooked up a > remote rule for the jQuery validation plugin I bypassed MG entirely > and hit a ColdSpring remote service proxy instead. > > Now that you've mentioned it, though, it looks to me like it wouldn't > be too tricky to accomplish this goal by modifying just the > executeEvent method in the default RemotingService -- I believe that > this works: > > <cffunction name="executeEvent" output="false" access="remote" > returntype="any"> > <cfargument name="eventName" type="string" required="true" /> > <cfargument name="values" type="struct" required="true" > default="#structNew()#" > > <cfargument name="returnValues" type="string" required="false" > default="" /> > > <cfset var eventValues = super.executeEvent(arguments.eventName, > arguments.values, arguments.returnValues) /> > <cfset var valuesList = "" /> > <cfset var value = "" /> > > <cfif isDefined("returnFormat") and returnFormat is "plain"> > <cfloop collection="#eventValues#" item="value"> > <cfif isSimpleValue(value)> > <cfset valuesList = listAppend(valuesList, > eventValues[value]) /> > </cfif> > </cfloop> > > <cfreturn valuesList /> > <cfelse> > <cfreturn eventValues /> > </cfif> > </cffunction> > > (And obviously this could be easily refactored to move the value > formatting into a separate method if desired.) > > It would be easy enough to do something similar in the > AbstractRemotingService -- if we did implement this, I would assume > that the necessary functionality would be added to the > AbstractRemotingService directly rather than using a methodology > whereby it would need to be defined in the child RemotingService. > > This seems like a useful enhancement to me, as at the present time one > cannot use a plain returnFormat with the RemotingService. > > -- > Ezra > > > On Tue, May 18, 2010 at 9:00 PM, BobS <[email protected]> wrote: >> Hmm, I just looked at that code again, which was untested (my own code >> was actually uglier than that and I realized I could improve upon it >> while writing the email) and realized that it probably won't work, as >> the createResultPlain method won't be available from the parent's >> executeEvent method. >> >> The idea is what is important, however, which is that it would be nice >> to be able to override the format of the data that is returned from >> the RemotingService. >> >> Cheers, >> Bob >> >> On May 18, 11:35 pm, Bob Silverberg <[email protected]> wrote: >>> I'm working with the jQuery validation plugin, and it has a feature >>> where you can define a "remote" validation rule. This allows you to >>> specify a url to call via ajax, and also allows you to pass arguments >>> with the call. The limitation of the way this feature is implemented >>> is that it expects a single word as a response, either "true" or >>> "false". I was able to wire things up between this plugin and my MG >>> app using the remoting service, but the remoting service is returning >>> json data, which won't work with the plugin. There is no opportunity >>> to intercept the data and massage it before the plugin attempts to >>> interpret the response. I don't really care for that fact, and >>> perhaps the best solution would be to fork the plugin and patch it so >>> that it can interpret json data, but I wasn't feeling up to that >>> today. ;-) >>> >>> So instead I wanted to get MG to return a simple string to me. I >>> suppose one route is to go "old school" and create an MG event with a >>> view that only returns the single string, and maybe that is the best >>> route. Maybe the RemotingService is really only meant to be used in >>> situations in which you do need to receive complex data from an MG >>> app? Maybe. But I figured that I'd try to work with the existing >>> RemoteService infrastructure and see if I could get it to do what I >>> wanted. It was actually fairly simple to do, but it did require a bit >>> of refactoring in the AbstractRemotingService. >>> >>> The problem with the current implementation of the >>> AbstractRemotingService is that the creation of the returned data is >>> embedded in the executeEvent method. I refactored it to look like >>> this:http://cfm.pastebin.com/z495z61q >>> >>> Then I was able to create my local RemotingService that looks like >>> this:http://cfm.pastebin.com/By5WwSMx >>> >>> To get it to return plain data I simply add a returnFormat=plain >>> argument to my request. I freely admit that it's not the most >>> beautiful piece of code ever written, and it's value may be >>> questionable, but I think adding the flexibility into the >>> AstractRemotingService to allow for a developer to override the format >>> of the data that is returned might be a nice feature. >>> >>> I also realize that another option would be to bypass MG entirely and >>> simply call a cfc directly, but I wanted to see what would be done >>> with what MG has to offer. >>> >>> Does anyone have any suggestions for other ways to achieve my goal, or >>> any comments on the changes that I made to the >>> AbstractRemotingService? >>> >>> Cheers, >>> Bob >>> >>> -- >>> Bob Silverbergwww.silverwareconsulting.com >>> >>> Hands-on ColdFusion ORM Trainingwww.ColdFusionOrmTraining.com >>> >>> -- >>> 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 >>> athttp://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 >> > > -- > 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 -- Bob Silverberg www.silverwareconsulting.com Hands-on ColdFusion ORM Training www.ColdFusionOrmTraining.com -- 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
