ColdFusion 11: Confusion as to why <cfhtmltopdf> is not simply an adjunct to <cfdocument>

G'day:
I had a look at <cfhtmltopdf> a week or so ago in "ColdFusion 11: <cfhtmltopdf> is pretty good!". And as I say in the article title: it works really well (other than a coupla bugs I raised). However one thing I can't work out is why we now have two tags that do the same thing: <cfdocument> and <cfhtmltopdf>.

They might - under the hood - use different mechanisms to arrive at the same goal, but surely the whole thing about having a tab abstraction layer is that the underlying mechanism ought to be irrelevant: the tags - and indeed the CFML language as a whole - is supposed to abstract the minutiae away from the developer.

A coupla things that are different about <cfhtmltopdf> are:

1. it only works on Windows;
2. it is enterprise only.

Both of these are a bit shitty (or a lot shitty, really), but they do not - in my mind - justify why <cfhtmltopdf> is a separate tag.

So, anyway, I asked on Twitter for some sort of explanation:

@ColdFusion, can you pls explain why <cfhtml2pdf> is a new tag,not just an upgrade to <cfdocument>? They do the same thing,yes? #ColdFusion
— Adam Cameron (@dacCfml) March 9, 2014

And this morning I got a response from Rakshith (well I am presuming he's still the man behind the curtain of the @ColdFusion account?)

@gamesover @dacCfml The new PDF engine service can be installed as a seperate service on a remotely. You can chose to disable it as well.
— Adobe ColdFusion (@coldfusion) March 12, 2014

@dacCfml So rather than force fitting the available functionality, a new htmltopdf was introduced. Much easier for CFers to comprehend.
— Adobe ColdFusion (@coldfusion) March 12, 2014

My initial reaction here is in response to this bit "Much easier for CFer to comprehend". And my reaction is "you patronising f***" (this was close to being the title of this article, but I thought better of it).

Not only is Rakshith being patronising the basis for his tone seems fairly facile to me.

Let's accept that the purpose of <cfdocument> and <cfhtmltopdf> is the same: generating a PDF from mark-up. And let's also accept that the reason they're doing this work is that <cfdocument> wasn't that good at what it set out to do. It can be used to create moderately straight forward PDFs, but as soon as the document structure or design got more than superficially complex, it was no good. Fair enough: it was the first iteration of the functionality (although it perhaps should not have taken close to ten years for the second iteration of it to present itself, but hey).

Let's also accept that there's some differences in approach (the two points I raise above) too.

This can all still be achieved with a single tag, surely? We already have a precedent set for this with <cfchart>, which not only has two separate engines, but one of them is server-side and one of them is client-side!

So with <cfdocument>, how come it cannot work like this:

• if the new engine is disabled, then processing falls back to the original mechanism;
• if the licence is a standard one, it falls back to the original mechanism;
• if the box is not a Windows one... it falls back.... etc;
• if an "engine" attribute is set to "classic" or "pants" or something, it also falls back;
• otherwise it uses the new engine.

This also negates a curious "feature" <cfhtmltopdf> has... the underlying engine can be disabled. How is this actually a feature? And... how is this a good thing? What happens if the engine is off and someone tries to use <cfhtmltopdf>? I presume it just errors? Would it not be better to have it fall back to the original mechanism?

And the same applies to the observation Rakshith made that the new engine can be installed as a separate service. So what? Why does that mean it needs to be a new tag? It doesn't.

Another thing Rakshith has posted that I just noticed whilst writing this is:

@dacCfml The ability to add dynamic header and footer along with support for basic authentication is not available via the new engine.
— Adobe ColdFusion (@coldfusion) March 12, 2014

Right. So there's two observations to make here:

1. So that's a step backwards, innit? I suppose you've got some work to do in that case, so as to facilitate this.
2. [shrug]. One can't do everything with the old <cfchart> engine that one can with the new one, and vice-versa.

Neither of these are good rationalisations as to why this is not an augmentation (or a backwards step, in the case of the first one) of <cfdocument>.

All adding yet another PDF-generating tag to the language is achieving is demonstrating a lack of thought / planning on the part of Adobe, and cluttering up an already cluttered language.

I think this needs a bit of a rethink before go-live.

--
Adam