QR Code Generator Update
November 29, 2011 5 Comments
I’ve just found a bug in the way I wrote the original code for my QR Code Generator
Update 2: Thanks to a comment from Michael, I’ve found another way to fix the issue by adding encodeURIComponent to the JS function. See the comments for details. Now you have 2 ways to do it 🙂
The problem is that by using the url scope you can only get one url parameter to pass to the Chart API from the variable #url.siteurl#.
If you enter
http://www.testserv.com?foo=1&bar=2
as the input value of the text box, the value of url.siteurl becomes http://www.testserv.com?foo=1 and then CF creates -another- URL variable called bar with a value of 2.
This had me stumped for a while. but what is happening is that the url being passed as
dsp_qrcodeGen.cfm?siteurl=http://www.testserv.com?foo=string1&bar=string2
What we get when we do a <cfdump var=”#url#”> is
param1 (siteurl) = http://www.testserv.com?foo=string1
param2 (bar) = string2
See what happened there? Everything after the first ? (dsp_qrcodeGen.cfm?) up to the first & (&bar) becomes a param pair and then everything after the & becomes a pair. Problem is we don’t -want- to pass 2 url params. as we’d have to handle them by doing something like
<cfhttp url="http://chart.apis.google.com/chart?chs=200x200&cht=qr&chl=#url.siteurl#&someparamname=#url.someparamname#" result="qrcode" getasbinary="yes">
This gives us the proper string to pass but it requires us to hand code the cfhttp call making it very inflexible. It becomes even more difficult as we need to pass additional params. You could probably code up a parsing loop of some kind but there is a much simpler method.
CF does not parse form variables in the same way it does URL params, so by using the form scope, CF doesn’t break apart the string that we feed it.
<cfoutput> <div style="margin:auto; width: 700px; height:450px;padding:25px;text-align:center;border:1px solid;"> <form method="post" action="dsp_qrcodegen.cfm"> <h3>QR Code Generator</h3> <hr> Input URL <input type="text" name="siteurl" id="siteurl" style="width:500px;margin:50px 0 50px 0;"><br> <input type="submit"> </form> <cfif structkeyexists(form, "siteurl")> <div style="margin:auto;"> <cfhttp url="http://chart.apis.google.com/chart?chs=200x200&cht=qr&chl=#urlencodedformat(form.siteurl)#&chld=H|0" result="qrcode" getasbinary="yes"> <cfimage action="writeToBrowser" source="#qrcode.filecontent#" /> <br> #form.siteurl# </div> </cfif> </div> </cfoutput>
#form.siteurl# stays siteurl=http://www.testserv.com?foo=string1&bar=string2 so all our params get passed and you can add as many additional params as you like.
Pingback: Quick & Dirty QR Code Generator Using Coldfusion & cfimage tag « Sid’s FishNet
Thank you for this. We are just starting to put QR Codes here and there, and it is nice to have one I can run on our CF server in house.
You can do it using URL vars. You just have to urlencodedformat(url.siteurl) again on the receiving page before shooting to google.
Michael – I tried that (first thing actually) but it does not work with the original code. Trying to create a URL with multiple params, with or without, results in errors. For example, using the code from my original post, submitting
http://myserver/test/dsp_qrcodeGen.cfm?siteurl=http://myserver/dsp/qrlanding.cfm?src=package&upc=999999999&ctry=ca
Fails when I scan the QR code with error Element UPC is undefined in URL
Looking at Firebug to see what is being passed we get
ctry ca
siteurl http://myserver/dsp/qrlanding.cfm?src=package
upc 62013300044
and the only thing google processes is siteurl, ignoring the other 2 params
Ah, wait, no – you are correct – sort of.
urlencodedformat(url.siteurl) in the cfhttp call was not the issue. The problem was in the JS function which was
function doIT(){
self.location = ‘dsp_qrcodeGen.cfm?siteurl=’+document.getElementById(‘siteurl’).value
}
By encoding -that-,
function doIT(){
self.location = ‘dsp_qrcodeGen.cfm?siteurl=’+encodeURIComponent(document.getElementById(‘siteurl’).value) }
it works and passes the complete url as a single param. The cfhttp call did not need to be encoded (although it won’t hurt)
Thanks for the input!