We had a discussion in the virtual office earlier today when we were working together to change a report in one of our applications. The report output used Portable Document File (PDF) format and we use a library called fPDF that allows use to create PDF documents via PHP for web based application and one of our developers asked:
Why not use a library that can convert the HTML output into PDF?
It’s a good question and can certainly be done, relatively easily, when the HTML is well structured and created using HMTL5 / CSS3, but it has it’s limitations.
Using a PDF Library like fPDF allows developers the control to output and allows them manage virtually any aspect of the document, where as a conversation of HTML to PDF doesn’t.
Taking the high / low road
I said that we need the control of the output and using a pre-built component or library to manage the conversion would take away functionality. I went on to explain the differences …
Using a low level approach, you have to define and create the universe in order to build anything, but allows you to define the laws of physics within the universe.
Using a high level approach, you use a universe that someone else has created and are constrained by decisions the previous programmer made, when defining his laws of physics within his universe.
So whilst low level takes longer – after all, according to Genius it took God seven days – it allows you to define the laws of physics (or rules), rather than using someone else’s. It reminded me of a project I developed back in 2009; we chose Java J2EE to create a desktop application for creating cash flow scenarios, using data extracted from various accounting software. We need to create a user interface that worked like a spreadsheet, using pivot tables and all sorts of wizardry that chartered accountants like to use for projecting cash flow, enabling business managers to make informed decisions.
We made an important decision, early in the development, to create a custom model that extended the Abstract Table Model used by Java Swing Tables (which, whilst would take longer to develop) and would give us more flexibility and enable us to create custom functionality that extended that native behaviour. It was a good decision and saved time in the long run.
Conclusion
Development decisions can sometimes seem innocuous, but development teams have to consider how a solution might be used and / or extended over time, so great care should be taken when making decisions of using pre-built code or libraries. Short cuts will often come back to bite you in the arse!