>> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
>> <cfparam name="attributes.objectid" type="numeric" >> default="0"> >> >> <cfif objectid>... do stuff ...</cfif> >> >> In my case the attributes scope is a combination of form >> and >> url variables... And at a first glance this looks really >> good >> because it's nice and validated, you know the data going >> in >> is correct. But here's the problem -- if a user happens >> to be >> muddling with the url and accidentally types a >> non-numeric >> character into that url variable, instead of being >> ignored >> the cfparam produces a big ugly cf-error that the user >> won't >> want to see... and using val() in the default attribute >> is no >> help of course because it's not the default value that's >> at >> fault. (and yea, I've made the mistake of type="numeric" >> default="" >> before too). >> >> So I'm starting to think that for the base templates or >> otherwise publicly accessible templates, this structure >> is better: >> >> <cfparam name="attributes.objectid" type="string" >> default=""> >> >> <cfif val(objectid)>... do stuff ...</cfif> >> >> Although the code is only very subtly different, this >> structure will never produce the ugly cf error message as >> a >> result of a user accidentally malforming the url, because >> they can't possibly provide a value to the server in the >> url >> that CF won't interpret as a string. > Ike, > What about sticking to your original use of cfparam and > just having the > appropriate error handling mechanisms in place to deal > with someone mucking > with your values? Well the problem with that is that you don't always have control over people changing the values... Simple example, somebody who uses your site remembers a particular page and they think they remember the url but they don't have it in front of them to copy-paste, so they type it out in an email, but from memory, and they mangle one of the variables. The altered use of cfparam in that case would actually _be_ the "appropriate error handling mechansisms" is what I'm saying, because in that case, the user is going directly to a page -- there isn't any place between the user and the page to inject "appropriate error handling" like you might expect with a form for instance (which also relies on javascript anyway). I'm not actually commenting about the use of types in the <cfargument> tag for cfc methods -- although it would also apply in this case if the form submits directly to a CFC instead of to a .cfm base template. s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://macromedia.breezecentral.com/p49777853/ http://www.sys-con.com/story/?storyid=48229&DE=1 http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.sys-con.com/story/?storyid=48229&DE=1 http://www.fusiontap.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:197500 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
