Sean A Corfield wrote:
> Consider this example instead:
>
> <cffunction name="multiply" access="remote" returntype="numeric" output="false">
> <cfargument name="x" type="numeric" required="yes"/>
> <cfargument name="y" type="numeric" required="yes"/>
> ...
> <cfreturn x * y />
> </cffunction>
>
> Now, this function returns a 'useful' numeric result for which there are no out-of-band values. You cannot overlay an error code return on this function.
You could in this example.
<cffunction name="multiply" access="remote" returntype="numeric" output="false">
<cfargument name="x" type="numeric" required="yes"/>
<cfargument name="y" type="numeric" required="yes"/>
<cfset var multiplyReturn=(x*y)>
<cfreturn multiplyReturn> </cffunction>
> Numerics are just numbers - they are not formatted. This highlights that what you really want here is a string that you validate inside the function (since CF doesn't have a built-in type="phone").
Wrong, I do not want a string, I want the documentation to say that it is numeric. And return an error code if they pass it in as a string, leave it out, etc. Not a string and then me telling them it's numeric in the hint attribute value.
Reading on in
> your example it seems you don't really allow formatted fax numbers, you just require numbers to be at least 11 characters long and begin with a valid international prefix...
This is not an actual service, this was an example.
> There are also other errors you're missing: > - userID not provided > - faxNumber not provided
That's because it's an example. Please don't assume that I'm an a**.
> Furthermore, you're not trapping all errors which means a user can't fix all of their problems in one step: they have to test, change, test, change, test, change until they get past all of your checks.
>
> Here's your examples:
>
>> <cfdump var="#sendFax(userID='test', faxNumber='one')#">
>
>
>
> This should really return 11119000 and 11119002.
>
>> <cfdump var="#sendFax(userID=123, faxNumber='one')#">
>
>
>
> This should really return 11119001 and 11119002.
>
> What about these:
>
> <cfdump var="#sendFax()#">
> <cfdump var="#sendFax(userID='1234')#">
> <cfdump var="#sendFax(faxNumber='15553334444')#">
>
> Those are all invalid as well.
Yes they are, see my comments above.
> The WSDL will not show all native CF types in an intuitive way so I don't think that's the best form of documentation for this problem. The CFC Explorer output is easier for CFers to read - and there you *can* take advantage of the hint= attribute to describe the arguments in detail.
Forget the CF people, the hint is fine for them. What about the Flash people?
> CF generates the WSDL based on the actual code signature. The WSDL doesn't have to match the code, of course, and I suspect that's how some of the web services you've looked at handle this. Here's how you'd do that for CF:
> - write your CFC with all the exact types you want
> - generate the WSDL and save it as an XML file
> - modify the CFC to use type="any" (and required="false") and add all of the manual argument validation code
> - distribute the URL of your saved XML file (*NOT* the dynamic ?WSDL URL)
>
> Pros: users looking at WSDL see exactly what you want; you can handle errors however you want (because your code is more generic than the WSDL).
> Cons: code doesn't match WSDL so if you change any method signatures, you either need to manually update the WSDL or change the methods signatures (back to the strict form) and regenerate the WSDL.
Sounds retarded to me. This takes it back to my original question. Can I catch type errors. The answer is no, and that sucks. Because if I could catch them, everything would be fine.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
