I did a site for a client several months ago who needed PDFs created. The easiest path I found was to create the PDFs directly using PDF::API2::Simple with a few calls to the underlying PDF::API2 object it uses and exposes

Generating a PDF can take quite some time in a web-serving time scale. Rather than doing so on every request, I set up a simple caching system. It serves the PDF as a file from disk.

On every PDF request, it checks the age of the PDF file requested against the age of the latest DB entry that would be relevant to the particular PDF's content. If the file needs to be updated, it updates the file then serves it. That web user sees a delay for the file being generated. Additional users who download the file before any changes are made to it get the file already generated.

One could do the generation at the time of the change so there's never a delay for the download. In this client's case changes to the DB are much more common than the finished document being downloaded. I decided to put the delay where it would be least frequent rather than where it would in every case be a burden to the maintainer and never on the receiver, but your needs may be different.

You might even have the people updating the database choose when to generate a new version of the final PDF document. This could be really nice if the changes they make are not always self-contained. A "Generate New PDF" button could be a nice feature. It could also be a slight and unneeded burden that people would need to remember to do if that's not the usage model that best suits them.

Another thing to consider when you're writing a document management system is how many versions of each document you need to keep. Will it be just the newest of each? Do you need the newest and the most recent older version (whether for comparison or in case a change needs to be backed out)? Do you need to have a full revision history so you can see which version of the document was in effect at any particular date? You may want a system that pulls from the DB, generates a PDF, and checks the PDF into a full-blown revision control system like CVS or Subversion. You may find it's better to keep the older data in the DB instead and have an administrative function to pull PDFs according to the old data on the fly.

Is it necessary in this case to serve the PDF files from the web at all? It was in my case, because it was commissioned specifically as a web application. If your users have a common file share, though, you might want to consider having only the DB and file generation actually on the web. The files themselves could be generated and saved to the share for everyone to pull in using native OS functions.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.