Hi, I might be off track here - but I agree with steve. As a webservice you can't and don't want to implement the same vaidation code all over the shop! Even if it isn't 'pure' OO, which we could debate. There are validations other than simple datatypes anyway, bounds, patterns etc. and its nice to handle it there. by all means do it in your calling code too, to save even making the cfc call if you want. It really is more encapsulated you could say because you have to know even less about calling it right, and when you call it wrong it tells you why.
My 1 cent worth Elliot "Mark M" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > ---8<------ > I have a CFC. This CFC required an argument called UserID. The UserID > MUST > be a Number. The UserID is passed in but is blank. > ---8<------ > > I would say in this example the UserID should be handled in some way to > give the method a value it can handle. Make it zero if you will. This > should be handled outside the method. The method is not an all powerful > being that handles everything. It is only there to do one thing, and one > thing only. > > ---8<------ > Lets say the above example was actually being used for a web service. > If > you were the one using this web service, would you want to be handling > the > catch code or would you prefer that if it errored, to return to you a > specific error code or something to tell you that something has gone > wrong? > ---8<------ > > If that was the case - the person invoking the webservice DESERVES to > get an error message. > > If I tell you to give me a number, and you give me anything but, what do > you EXPECT to happen? :oP > > It's like saying 'hey, if you jump off that rooftop, you are going to > get hurt', and then someone jumps off the rooftop and break their leg, > they are wondering why they are lying there in agony. > > If I tell you to pass me a number, pass me a number damnit! :o) > > Mark > -- > [EMAIL PROTECTED] > ICQ: 3094740 > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve > Onnis > Sent: Monday, 3 March 2003 1:12 AM > To: CFAussie Mailing List > Subject: [cfaussie] Re: CFC sprung doing naughty things > > ok > > take this for example > > I have a CFC. This CFC required an argument called UserID. The UserID > MUST > be a Number. The UserID is passed in but is blank. > > What do you want to do? Display the CFML error template or handle the > error > from within the CFC in some way, for example returning nothing back to > the > caller. > > Unless you try and handle it in the code calling the CFC, there is no > way of > doing it. > > Lets say the above example was actually being used for a web service. > If > you were the one using this web service, would you want to be handling > the > catch code or would you prefer that if it errored, to return to you a > specific error code or something to tell you that something has gone > wrong? > > Steve > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mark M > Sent: Monday, March 03, 2003 1:00 AM > To: CFAussie Mailing List > Subject: [cfaussie] Re: CFC sprung doing naughty things > > > Steve - > > I need to ask - > > In what instance would you have a CFC that requires a string to run... > and you would pass in an array? > > Methods should do one thing and one thing only, by good software design > standards. (Cohesion and Coupling... remember these things?) > > Making a method take multiple types goes against these basic principles. > > CFArguement is the ColdFusion way to ensure that types remain the way > they should be. Unfortunately we can't compile our code and test it > that way. > > I don't want someone passing in a number, when really what I want is an > array. Its going to stuff my whole method. > > Presto. Cfarguement. Why would I use anything else? > > I hope this makes sense :o) > > Mark > > -- > [EMAIL PROTECTED] > ICQ: 3094740 > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve > Onnis > Sent: Sunday, 2 March 2003 10:06 PM > To: CFAussie Mailing List > Subject: [cfaussie] Re: CFC sprung doing naughty things > > Geoff > > "If there is any chance that the call to the CFC will pass incorrect > data > types (eg, from some sort of user input) the input validation should be > performed upstream -- ie. not in the component." > > If this is the case, then what is thr purpose of CFARGUMENT then apart > from > populating the CFC with metadata? If I have to validate the data and > catch > the exeption before it goes into the CFC, then why even bother using > CFARGUMENT? To me this would be just doubling up on code cause you are > validating the data before it goes into the CFC, then using CFARGUMENT > to > once again validate the data being received by the CFC. > > "In any event, once you have trapped the error in your CF_ARGUMENT tag, > what then? Don't you still have to return a result to the script > calling your object, and presumably that script has to do something with > the error?" > > When I trap the error, then I am free to deal with it as I see fit. If > I > want to display an error to the screen, then I can. If I need to write > the > error information to a log file, then I can, or even if I just want to > return nothing from the CFC, then I can do that also. Using CFARGUMENT > gives you no control what so ever on how you want to deal with the error > from within the component. Once again, I see dealing with the error > from > within the CFC essential. > > Take for example, calling the CFC from flash. Wouldnt it be easier to > handle the exeptions from within the CFC and pass back to flash the > error, > rather than, as I would imagine would happen, the code would error and > flash > would die. Yes I know you can see all this information from within the > netDebug pannel, but once the application is live, and it errors, what > can > you do? > > For me, pesonally, I feel that CFARGUMENT, as a data validation tool > need to > have some sort of capcity to let the developer handle the errors > produced by > bad data, rather than just displaying the CF error template. > > Steve Onnis > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Geoff > Bowers > Sent: Sunday, March 02, 2003 5:37 PM > To: CFAussie Mailing List > Subject: [cfaussie] Re: CFC sprung doing naughty things > > > Steve Onnis wrote: > > It just makes more sense to handle this kind of thing in the cfc than > > outside. Catch it once inside the cfc for all calls or write error > handling > > code every time you call the function in your code. Which would you > prefer? > > I would, and I guess most developers would choose the handle it once > option. > > Not really. CFARGUMENT is performaing data type validation. The > application making calls on the CFC should *always* be passing in the > right variable types -- CFARGUMENT acts to protect the integrity of the > function it finds itself in. > > If there is any chance that the call to the CFC will pass incorrect data > types (eg, from some sort of user input) the input validation should be > performed upstream -- ie. not in the component. The component should > not have to worry about anything except itself. For example, trapping a > database execution error within the function itself is appropriate -- > the component should know how to communicate with the database if that > is its job -- but it should not have to contend with incorrect > data-types other than to refuse to cooperate ;) > > In any event, once you have trapped the error in your CF_ARGUMENT tag, > what then? Don't you still have to return a result to the script > calling your object, and presumably that script has to do something with > the error? > > Also, CFARGUMENT populates the CFC metadata with information which is > essential for the construction of self documentation and WSDL > generation. > > I love CFARGUMENT. I don't think anyone should be giving it up in a > hurry :) > > -- geoff > http://www.daemon.com.au/ > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
