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
