Ok, take this example.
<cffunction name="sendFax" access="remote" returntype="numeric" output="false">
Ah, but in this example, your function only returns a status code - it does not have a 'normal' numeric return so your approach is actually fine (assuming you could defeat CF's argument checking). Your function API is that it returns a status code indicating success or a variety of failures.
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.
So you can *either* return a status code (your example) *or* return a value (and throw an exception - my example).
Let's look at your example some more:
11119000: userID is not numeric 11119001: userID is not registered 11119002: faxNumber is not numeric 11119003: faxNumber is not formatted as a fax number
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"). 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...
There are also other errors you're missing: - userID not provided - faxNumber not provided
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.
Now I can test for the validity of the userID and that the faxNumber is a valid length. But I want to keep the type of the arguments both numeric in this case. The reason is that I don't want to have to write a custom documentation page for the service. I want them to be able to invoke the wsdl and see the correct type requirements.
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.
I don't know, to me this seems like such a simple request. I don't understand why it seems like it's not possible.
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.
Sean A Corfield -- http://www.corfield.org/blog/
"SOAP is not so much a means of transmitting data but a mechanism for calling COM objects over the Web."
-- not Microsoft (surprisingly!)
----------------------------------------------------------
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]
