CFC's and Returns

Ok, so I am working a bit more with CFC's but have more of a logistics question than anything else. Let's say that I have a function called GetUserList within my User.cfc. Ideally I would like to return a query with whatever User information I want to return. Something like a query with Username, Password, and Email. I also want to return a Boolean variable with whether or not the function was successful. And also a Message variable that contains a string with a message on why the function failed. Is the best way of handling passing back all 3 objects a struct? As I am doing it now: StructNew() Struct.ReturnQuery = My Query Struct.Result = Whether it is successful or not Struct.Message = A message in case function failed Is this a good approach? Or is there a better way to pass this information? Let's say that this IS the best way. How would I access my Query from the calling page? I've never accessed a Query within a Struct before. Ideas? Cedric

That's what I do.. return a struct that is.. I tend to think of it as a status object. status.success = true / false; status.description = "description"; status.result = result; // your expected return.. recordset, strings, etc.. If something fails along the way I capture the failure and reason behind it and attach it to the status object.  There may or may not be different access levels for the error descriptions / details... like user friendly and admin.. The UI deals with consistent status objects and knows what to do with them.  If the application fails the UI knows why and what to tell the user or what, if any, additional steps to take. I should note... all of the UI work I do is in Flash... which probably skews my perspective. ----- Excess quoted text cut - see Original Post for more -----

----- Excess quoted text cut - see Original Post for more ----- Yes, that's the approach I'd recommend. Since you can only return one thing, it would have to be a structure, query or array to contain three other things. > Let's say that this IS the best way. How would I access > my Query from the calling page? I've never accessed a > Query within a Struct before. <cfoutput query="structname.queryname"> #structname.queryname.fieldname# </cfoutput> Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444

Thanks Cedric and Dave.  Creating a structure like this is a MUCH MUCH cleaner solution to returning a recordset and/or any error messages (i've started a similar thread an hour ago). So, if I create a structure to return my target recordset, AND an error recordset/structure, then I can deal with one return type and easily handle both situations (I WAS planning on only returning a query object.) Now, to figure out the best method for accessing my DSN.. :D Shawn ----- Excess quoted text cut - see Original Post for more ----- Yes, that's the approach I'd recommend. Since you can only return one thing, it would have to be a structure, query or array to contain three other things. > Let's say that this IS the best way. How would I access > my Query from the calling page? I've never accessed a > Query within a Struct before. <cfoutput query="structname.queryname"> #structname.queryname.fieldname# </cfoutput> Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444

Well, personally, I wouldn't do it that way. You're putting the onus on the person using the CFC to always check to see if the CFC succeeded.  This reminds of good old HRESULT in the Windows world, which no one would actually bother to check. How about throwing an error in the CFC using the cfthrow tag instead?  That way, the developer's well aware of the fact that they have to do something if there's an error condition. ----- Excess quoted text cut - see Original Post for more -----

Very true. I supposed throwing an error is probably the best way of approaching this, since the user would have no choice but to trap the error and do something. Thanks. Cedric ----- Excess quoted text cut - see Original Post for more -----

I've come up with a very similar structure. I drop it into an init() that way the parameters are always there, even if I have nothing to assign them. This way I know all my CFCs will return the same thing. As for throwing errors... I'm of the tradition that there is never a good reason to throw an error. (in CF that is, where throwing an error doesn't mean handling an error). If your write you code tight enough, you will recognize any errors before they happen, and can pass that information along through your structure. If you really need to be notified, shoot yourself off an email, or start a custom error log you can append to. I think the structure idea is golden. The question I was about to post before reading this thread was "Are there any other constant variables to include other than (result, message, value)?" Dave, does Figleaf have a standard structure to be used for all CFCs? Does Fusebox 4/MX touch on this? Adam Wayne Lehman Web Systems Developer Johns Hopkins Bloomberg School of Public Health Distance Education Division Well, personally, I wouldn't do it that way. You're putting the onus on the person using the CFC to always check to see if the CFC succeeded.  This reminds of good old HRESULT in the Windows world, which no one would actually bother to check. How about throwing an error in the CFC using the cfthrow tag instead? That way, the developer's well aware of the fact that they have to do something if there's an error condition. ----- Excess quoted text cut - see Original Post for more -----