Skip to main content

Coldfusion 11: Printing the Contents of a Specific DIV

Recently, we upgraded (where I work) from CF9 to CF11.  We could have simply moved all the code as it was to the new servers, but I decided to make the process even more challenging by moving away from custom CSS to Bootstrap and begin using AngularJS as the front end Javascript framework.  During this process, some of the features, like printing, were missed and didn't make it to the new version of the system. Feedback from a few end users was that they had to have printing.  Where is the printing?!

My hope was that printing could be accomplished by printing via the browser.  But different browsers yielded different results.  Printing the page in general wasn't a good option anyway because of the header menu and various options for controlling the content (and by content I mean college class lists, advisee lists, etc.).  Enter a thought and CFHTMLTOPDF, a little Javascript (jQuery) and a page.

I will preempt the following by saying I am likely never to win any awards for style or best practices.  So if you're reading this and have a simpler way of doing this, please do share - I don't take criticism of my development skills [too] personally and I always enjoy learning new techniques.

Ultimately, my goal was to print the contents of a specified DIV.  This would create the best option for the end user so they don't have nonsensical items on their print outs.  And I wanted the print out to be a PDF - simply because PDFs are understood by the major browsers. There's not much code involved here - it's more about process than anything else.

The first step was to give the DIV an ID.  For a class list,
 <div id="contentClass">my content is in here</div>  
was used.  Outside the DIV, there is a button
 <button onclick="printContent('contentClass')">Print</button>  
The onclick event of the button is going to call the following JavaScript function:
 var printContent = function(_contentDiv){
   var _content = $('#'&nbsp;+ _contentDiv).html();  
   var _setContent = _cfc.setContent(_content);  
   window.location.href = 'printPage.cfm';  
 }  
Pretty simple, right?  Of course, there are some caveats here.  The first line in the function is a simple jQuery call to get the html content of the div.  The _cfc is a component page that's called via a cfajaxproxy.  That's just how I choose to do things.  Otherwise, you'd use an AJAX request to the CFC.  The _cfc function contains a function named setContent.  It does two things, sets a session variable to the value of the content; and returns something - in this case whatever you want.  The function would look something like following:
 <cfcomponent>  
    <cffunction access="remote" name="setContent" returntype="string">  
      <cfargument name="_content" required="yes" type="string">  
      <cfset session.content = _content>  
      <cfreturn "whateveryouwant">  
    </cffunction>  
 </cfcomponent>  
That's it for that part.  Very simple.

Now finally, we need to create the printPage.cfm.  This really only few lines as well and would look something like:
 <cfhtmltopdf>  
    <cfoutput>#session.content#</cfoutput>  
 </cfhtmltopdf>  
To maintain styling, you need to include any style sheets you may be using prior to the output.  In my case, I am using Bootstrap so my print page would look like following:
 <cfhtmltopdf>  
   <link href="css/bootstrap.css" rel="Stylesheet" type="text/css"></link>  
   <cfoutput>#session.content#</cfoutput>  
 </cfhtmltopdf>  
And that's it.  Whatever is in the DIV will be printed as a PDF.  I am sure there are caveats with CF PDF generation, but for simple stuff like images and tables with standard text, this process seems to work well.  It's light weight and easy to maintain.  I am also sure there are ways to make it better and I would love to here about them or any other comments you may have.

Thanks for stopping by!

All the best,
Terry

Comments

Popular posts from this blog

The Conversion: MAIN.CFM

Within the current development pattern I have for our portal system, the main.cfm is the starting point for an application. For the most part, this is really boilerplate and serves to get the application off the ground. The way the portal works is that the user lands on the main menu page and provide with a menu of options. Each option is called a function and is assigned a unique id. When the user clicks on a menu option, the page is reloaded with the function id. The process checks to see if the user is actually allowed to have access to the function. It then accordingly looks up the path and displays the page via a . In the case of the TRIPS application, the included file is the main.cfm page for the application. So far the project looks like this: we have the folder structure defined with no files aside from the main.cfm. The main.cfm contains a few javascript includes, the overarching controller for the application as well as the route viewer. The next blog post will foc

The Conversion: Trips for Keeps - Part 2

Ack! A few days off work and then updates to other applications that needed to be made has delayed more work on TRIPS. But we're back and ready to continue. In the last post , we started to build out the trip.html template and it's corresponding controller. The dataService was updated with an abstraction that would allow a CFC method to be called and data to be passed.  This post will focus on retrieving that data from the dataService to the CFC method. Before we get started, I thought it would be kind of cool to keep a count of the number of lines of code for the project.  I'm not sure if it will provide any insight, but it might be nice to compare the line count to the number of lines in the Flex application.  Rather than posting the counts on each blog post, I have created a separate post tracking the line count per post . In review, let's take a look at the dataService code that's going to call the Coldfusion function to save the trip information. this.p

The Conversion: Introduction

While working as the senior level developer for a small liberal arts college, I've had the luxury of deciding the technology to be used internally for custom applications. When I first started, the college was using Coldfusion 7, HTML, and many MS Access databases. Over the course of the past 11 years, we've moved to Oracle, are on CF11, and utilizing AngularJS / Angular for our front ends.  Coldfusion is still doing the heavy lifting in interfacing with Oracle. During those 11 years, we also found ourselves developing Adobe (now Apache) Flex applications.  Flex was a great tool - easy to develop in and fairly easy to deploy when Flash was ubiquitous. But Flex was not great on mobile platforms.  Hence our move to Angular due to the idea that we wanted to give our users a rich web experience. So over the course of the past two years, we've been either retiring Flex applications altogether due to the direction that some departments have taken (read outside vendor); or ret