Lucee 4.5.2 cfpdfparam difference with Adobe ColdFusion

Suppose the following on Lucee 4.5.2:

<cfset x = 1>
<cfdocument format="pdf" pagetype="A4" name="myVar#x#">
<cfdocumentsection>
Hi there
</cfdocumentsection>
</cfdocument>

<cfpdf action="merge" destination="RAM:///myPDF.pdf" overwrite="yes">
    <cfpdfparam source="#evaluate("myVar#x#")#" />
</cfpdf>

<cfcontent file="RAM:///myPDF.pdf" type="application/pdf">

then to check it also runs on Adobe Cf; you'd actually end up with:

"ByteArray objects cannot be converted to strings."
 
The original code for Adobe CF ran with the paramater like so: 

<cfpdfparam source="myVar#x#" />


Both sets of documentation list source defined as follows:
"Source PDF file to merge. You can specify a PDF variable, a cfdocument variable, or the pathname to a file."

This would indicate it is just a pointed type and that in Lucee it is not evaluating the string properly.

Just as an aside, while very messy, this will work:
<cfif server.coldfusion.productname eq "Lucee">
<cfpdfparam source="#evaluate("myVar#x#")#"">
<cfelse>
<cfpdfparam source="myVar#x#"">
</cfif>


As an aside, Lucee throws an error if the parameter syntax is like so:
<cfpdfparam source="#evaluate("myVar#x#")#""></cfpdfparam>

Comments

Post a Comment

Popular posts from this blog

Global SQL Procedure, System Objects and sp_ms_marksystemobject

You may come across a need to have a database of utils full of generic procedures which work on indvidual databases (say client databases). You can't pass the database name into the procedure as a parameter and say "use @dbname" in the procedure and dynamic sql sucks. One workaround is to create the procedure in the master database and then mark it as a system object. eg use [master] create procedure sp_doThis // note the sp_ prefix is required begin // etc etc end go exec sp_ms_marksystemobject 'sp_doThis' // second note, this procedure is undocumented, so I wouldn't be relying on this for life or death. use [myotherdb] exec sp_doThis go All done!
Read more

cf_sql_timestamp vs cf_sql_date vs getdate()

If there's one thing I don't like it is people confusing a date with a timestamp, and how a lazy bit of development can ruin a load of data. Here is a simple query inserting data to a timestamp I found in a system where all the created dates were truncated because of the incorrect syntax. Bad one which was in use: insert into testdate values (<cfqueryparam cfsqltype="cf_sql_date" value="#createodbcdatetime(now())#">); Result :  2015-09-29 00:00:00.000 Best One (easiest to read) insert into testdate values(getdate() ); Result : 2015-09-29 10:10:09.880 Not great (no binding) insert into testdate values(#createodbcdatetime(now())#); Result :  2015-09-29 10:14:44.000 What the bad one should have been insert into testdate values(<cfqueryparam cfsqltype=" cf_sql_timestamp " value="#createodbcdatetime(now())#">)
Read more