Which batfink are you looking at? The wiki doesn't even have a database, so you can't be looking at that.
BatFink makes no assumptions about whether a stored procedure will be better than a standard SQL query because that's a decision that should be made on a per project basis. Spike >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Taco Fleur >Sent: Friday, March 05, 2004 12:36 PM >To: CFAussie Mailing List >Subject: [cfaussie] Re: BatFink Released... > >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 --- 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
