On Wed, Jul 18, 2012 at 11:34 AM, Jason Allen <[email protected]>wrote:
> I'm trying to decide the best way to approach returning the errors to the > requestee. > I use bean-type CFCs to model stuff like this, and I have a validate() method in the beans. This validate method knows what's valid and what isn't at that level and if there are errors, I have the validate method populate an error struct so I know what fields are in error. That way when I pass the bean CFC back to the form I have all the data they submitted, and with the error struct I have the fields that are in error so I can display visually what the problems are and output a list of problems. The error struct uses the field name as the key and a message (e.g. "The email address you provided is not valid") as the value. For things outside the context of the bean you can check those things in your controller or preferably your service layer and have that be part of the overall error struct. My other option is to just use a single 'error' variable and if any > possible errors surface, they all just set 'error = 1'. That way I only > have to include a single 'error' bit in the return versus about 20 specific > error bits. > But it's easy enough to keep track of what goes wrong so you can give better information to the user (which is what you allude to in your next paragraph). > The downside is that there'd be no way to tell the requesting app WHICH > argument caused the error. > This is vital. If you don't do this that's an absolutely horrible user experience. Just saying "something went wrong, try again!" will have your users running far and fast away from your app. -- Matthew Woodward [email protected] http://blog.mattwoodward.com identi.ca / Twitter: @mpwoodward Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en
