Just curious, but why is BatFink based on using CFQUERY and no Stored Procedures?
Also why are there no queryparams used? Hey, maybe there is a valid reason, if so, I'd like to know ;-)) Taco Fleur Blog http://www.tacofleur.com/index/blog/ Methodology http://www.tacofleur.com/index/methodology/ Tell me and I will forget Show me and I will remember Teach me and I will learn > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Sean A Corfield > Sent: Saturday, 6 March 2004 3:05 AM > To: CFAussie Mailing List > Subject: [cfaussie] Re: BatFink Released... > > > On Mar 3, 2004, at 6:21 PM, Stephen Milligan wrote: > > Having spent the last couple hours puzzling over it, I've > decided that > > the > > current approach of throwing exceptions of type validation > just isn't > > good > > enough. > > On the grounds that input validation is 'expected' to fail because > users enter garbage? :) > > > I'm currently leaning towards creating a validator service in the > > model that > > allows you to pass in form data and returns a validation > > object/structure > > that contains a key telling you if the validation succeeded > as a whole > > and a > > struct containing message and errorcode for each field that > failed. The > > presenter can then re-route back to the original form and the view > > layer can > > decide whether to use the message from the model or use a > custom one > > based > > on the error code. > > Sounds pretty good but don't forget i18n which would require your > messages to be driven by locale... > > > The validation service can be called by the form action > method in the > > presenter layer before passing the data to the model to update the > > database. > > Yes. > > > The question is whether or not the validation service should check > > whether > > say a username already exists in the database, or only if > the username > > submitted has a valid length and characters. > > I think that's a slippery slope. You don't really want to mix > knowledge > about the persistence mechanism (which in general might not be a > database) with the input data validation routine. Besides, in a > multi-threaded environment, checking the username exists prior to > updating the database isn't guaranteed to produce unique > entries in the > database(**) so you still need a constraint on the database > and you'll > still have to deal with exceptions thrown for constraint violations. > > ** Consider two form submissions from different users for the same > username. They press submit at the same time and both requests are > being processed. Both check the username and find it is not > present in > the database. Both attempt to insert their respective record. Either > (a) both will succeed if there is no DB constraint or (b) one will > succeed and the other will violate the constraint and throw an > exception. > > > There are also edge conditions where two users > simultaneously sign up > > with > > the same username and they both pass the validation check, but only > > one of > > them gets added to the database. The other gets a data > integrity error. > > Ah, yes, we're on the same page :) > > > I think I can live with the edge conditions and I'm thinking that > > checking > > for existing values in the database is probably the best way to go, > > but I'm > > open to suggestions if anyone has a better idea. > > I would be inclined to keep the lookup of the username out of the > validation itself, but perform a lookup ahead of the validation and > pass the result into the validation - or pass a user gateway object > into the validation. That way the validator does not need to > know about > persistence. > > Regards, > Sean > > > --- > You are currently subscribed to cfaussie as: > [EMAIL PROTECTED] To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004 --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
