CustomSerializer for PDF/XLS

[Jeffrey Cookle]

Hi, I have been working with Taffy for a month with consultants we hired and really like it.  We are trying to understand what we can do with customSerializer so that we can register additional return types in the ACCEPT of the header.   We have prebuilt functions in place that I would like to use inside of getAsPDF and getAsXLS.  We would like to return the binary of the PDF after it has been built back to the API caller, but with the serializer.

We would prefer to have the PDF and XLS functions called in the customSerializers instead of each API, like we had to do it now.

This is our getAsPDF where we pass in a db query and grid configuration information on how to format the data back, but we cannot seem to get Binary to return back to the API call and get an error that Binary cannot be converted to string.  I have also tried converting the binary to string, but then we seem to loose out on the formatting of the PDF, unless the client converts it back before showing.  If I dump out the file before the return we do have a valid PDF before the return. 

<cffunction

name="getAsPDF"

output="true"

taffy:mime="application/pdf"

taffy:default="false"

hint="serializes data as PDF" returntype="any">

<cfset local.returnVal = exportGrid("application/pdf",variables.data.query,variables.data.gridConfiguration)>

  <cffile

        action="readBinary"

        file="#local.returnVal.filepath#"

        variable="strPDFData"

        />

       <cfif local.returnval.error EQ "Y">

        <cfreturn "{error:#local.returnval.message#"/>

        <cfelse>

        <cfreturn #strPDFData# />

        </cfif>

</cffunction>

API Call where ACCEPT is PDF

<cfset x.query = ResultSetData>

<cfset x.gridConfiguration = gridConfiguration>

<cfreturn representationOf(x).withStatus(200)>(I have tried .withMIME as well)

When we change it to streamFile and/or streamBinary customSerialization doesn't appear to be called and then we get error types trying to pass in the struct of our inputs to our process as it is expecting a filename and/or binary input.  Unless there is a way to use streamFile with a customSerializer that I haven't read about yet? 

Just wondering what others may have done to utilize the "ACCEPT" header for non-string data returns.   Should we keep using the streamFile and streamBinary in each of our API calls?  Thank you in advance.

[Adam Tuttle]

Hi Jeffrey,

Thanks for using Taffy! I'm glad you like it.

It's hard to say for sure without seeing more of your code but it sounds to me like what you really need is streamFile or streamBinary. However I see that you're attempting to accomplish this with a generalized solution -- which gives me the impression that various resources/queries will flow through it -- so I applaud that! Well done!

Sadly Taffy's streamFile and streamBinary aren't currently available to serializer classes. That's something that could be added, but if you need a more immediate solution I would recommend the following:

Use an intermediary class to provide a single method to all of the applicable resources which accepts the query and returns the binary PDF data, and then use streamBinary to stream it back to the client.

someResource.cfc extends pdfHelper.cfc, and pdfHelper.cfc extends taffy.core.resource. As long as taffy.core.resource is at the bottom of that inheritance chain, Taffy will work as expected.

Adam

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeffrey Cookle]

Thank you Adam for your quick response and we will look at your suggestion of using an intermediary class.   Thank you also for confirming that streamFile/Binary aren't available to the serializer classes.

Have a great day,

Jeff

Adam

To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.