tracker issue : CF-3039143

select a category, or use search below
(searches all categories and all time range)
Title:

Bug 78547:(Watson Migration Closure)I love cfqueryparam

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): David McGuigan / David McGuigan (David McGuigan)

Created: 07/05/2009

Components: Database, CFQuery

Versions: 9.0

Failure Type: Unspecified

Found In Build/Fixed In Build: 0000 /

Priority/Frequency: Normal / Unknown

Locale/System: English / Platforms All

Vote Count: 8

Problem:

I love cfqueryparam. But I do not love its syntax.

I’d like to be able to ( optionally ) use a cleaner, more-readable "shorthand" that parallels the current one for cfsqltype and its options.

Instead of cfsqltype the attribute syntax "type" could be used and all of its values would be identical minus the cf_sql_ prefix.

So

<cfqueryparam cfsqltype="cf_sql_varchar" value="#trim( etc )#" />

could also be coded:

<cfqueryparam type="varchar" value="#trim( etc )#" />

It seems like this would be super easy to add to the language and would accelerate the coding of each cfqp significantly ( currently you have to type "cf_sql_[ first letter of your desired type ]" to get code hinting to suggest what you want. With the new syntax it would be a single keystroke. This is the major reason for this enhancement request, rapider application development ( though it’s also measurably easier to read ).
Method:


Result:

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3039143

External Customer Info:
External Company:  
External Customer Name: David McGuigan
External Customer Email: 5E0D54C04462BF5E992016B6
External Test Config: 07/05/2009

Attachments:

Comments:

+1, I've always thought the <cfqueryparam /> tag was too verbose. When suggesting to someone that they should use the <cfqueryparam /> tag, it can be kind of a shocker when it is realized how much extra typing is involved (I'm referring to the combination of adding the tags + the "verbose-ness" of the tags). When I say "verbose", I'm really referring to the combination of the "cfsqltype" attribute, and its values. I think this increases barrier-to-entry (to varying degrees). There was an ER#60636 (from 2005) which suggested syntax for the script-version of cfqueryparam. The example eliminated the "cf_sql_" and didn't need the "cfsqltype". However, the new script-based version of cfqueryparam (example code from docs below) did not honor these suggestions. It has respectfully been noted (in the related thread below), that "type" may not be appropriate, as there may be a reason to reserve it for future use. If "cfsqltype" cannot be shortened to "type", I'm asking that this ER not be dismissed in whole - but *at least* drop requirement for the "cf_sql_" in the values. I'm just not seeing any need for "cf_sql_". Related thread: https://prerelease.adobe.com/r/?6cd30a11f09840fba4b7d11b942ed83d Example code from docs, which uses new script-based version of cfqueryparam: <cfscript> q = new query(); q.setDatasource("cfartgallery"); q.setSQL("select * from art where artid = :artid and artistid = ? and description like 'vams?%' and largeimage like '%:jpg"); q.addParam(name="artid",value="56",CFSQLType='CF_SQL_INTEGER'); q.addParam(value="1",CFSQLType='CF_SQL_INTEGER'); result = q.execute(); </cfscript>
Vote by External U.
23559 | November 10, 2011 06:56:34 PM GMT
Sounds like a good efficiency improvement to me.
Vote by External U.
23560 | November 10, 2011 06:56:35 PM GMT
+1 vote. I disagree with the potential concern that at some stage in some imaginary future there might be the need for some other usage of the TYPE attribute with <cfqueryparam>. That's a very tenuous "what if". -- Adam
Vote by External U.
23561 | November 10, 2011 06:56:36 PM GMT
+10 It shoudl be noted that making this change would also make cfqueryparam more consistent with the wealth of other cf tags that use a simple "type" syntax. cfargument, cfparam, cfinput, cflock, cfmail, cferror, cfcontent, cfcatch, cflog, CFHTTPPARAM, etc.
Vote by External U.
23562 | November 10, 2011 06:56:37 PM GMT
Please implement this change.
Vote by External U.
23563 | November 10, 2011 06:56:38 PM GMT
definitely agree that this will improve the ease of use of cfqueryparam and hopefully encourage more people to use it
Vote by External U.
23564 | November 10, 2011 06:56:39 PM GMT
I agree with Adam and David. type="varchar" is much nicer to read (and remember) than cfsqltype="cf_sql_varchar" and would be more consistent with other tags.
Vote by External U.
23565 | November 10, 2011 06:56:40 PM GMT
so rather than dropping, it's just adding another range of supported values.. optional automatic type detection would rock i filed a similar bug in 78911 about autodecting nulls NULL="AUTO" the main problem is the length of the tag, CFBIND would be a great alias tag name <CFBIND value="#STR#"> versus <cfquerypararm value="#str#" type="cf_sql_varchar" null="#yesnoformat(len(str))#">
Vote by External U.
23566 | November 10, 2011 06:56:41 PM GMT
So - to be very clear - you have implemented this syntax: type="varchar" I believe you had already implement the values without the "CF_SQL_" prefix, but have you now done the same with the attribute name too?
Comment by External U.
23557 | August 19, 2015 12:20:12 AM GMT
Yeah, curious myself to see this in action. Please give me access to the current pre-release, thanks.
Comment by External U.
23558 | August 19, 2015 10:22:41 AM GMT