CFDocument ignoring some classes

My co-worker came across an interesting bug the other day. A class he was adding was being ignored by CFDocument. If he just output the content as HTML, there was no problem. It was only when inside CFDocument tags that the class would get ignored. We played around with it, a bit and discovered changing the order of the classes in the class attribute seemed to fix the problem. So with a workaround available we went on our merry way, but it was really bothering me and I couldn't let it go. I decided to make as simple of an example as possible and post a question on Stack Overflow but I took me awhile to even figure out how to duplicate the problem. In the process of duplicating the problem I stumbled upon exactly what the bug was.

The problem occurs when you have two class names applied to the same element, and the second class name matches the right end of the first class name case insensitively. Obviously some bad parsing happening inside the CFDocument engine.

Examples:

    <[element] class="firstClass class">Content</[element]>
    Or
    <[element] class="firstClass Class">Content</[element]>
    Or even
    <[element] class="firstClass stclass">Content</[element]>

Would produce the error, but:

    <[element] class="firstClass class2">Content</[element]>
    Or
    <[element] class="firstClass secondClass">Content</[element]>
    Or
    <[element] class="firstClass Classs">Content</[element]>

Would not. Since there is a workaround Adobe won't bother fixing this, nor would they bother publicizing this in any sort of documentation, just leave it up to their users to somehow know all the quirks of their application. I hope publishing this made your day easier.

A few things that are driving me away from ColdFusion are:

• Adobe's disinterest in fixing long standing bugs, and if there is a work-around, even if it involves their users needing to stand on their head and type with their toes, then it might as well be labeled "Won't Fix Ever"
• No documentation about what work-arounds exist for known issues, except on their bug report pages, which are a bitch to navigate in any useful way.
• The constant movement of their documentation, including live doc pages and bug reports. It's so frustrating to find a forum with a link that says, "Here's the work around" with a link to a page at Adobe that no longer exists. Couldn't you at least leave us a re-direct Adobe?
• This list could go on and on, but would mostly be re-hashes of the first point. Adobe, please fix broken things before adding more new features that less than 5% of your users care about. 

CFPDF musings

Since I've been heavily modifying PDFs lately I've discovered that CFPDF has got to be the most under-documented tag in Coldfusion. Shame really, you would think a company that does so much with PDFs would have the most top notch documentation for the manipulation functions they include in their own server application.

The good news is that it seems everything we would want to do calling in java objects and using the iText library can be accomplished with this tag, the bad news is that there is very little help as to how.

So here are some things I've learned lately that may help y'all out.

1. If you have a process that may generate multiple PDFs and you want to join them together with the merge action, there seems to be a bug that requires you to specify the pages argument if there is only one pdf in your source list. The live docs say that pages is optional, but the server throws an error if it's not included in this instance.
2. I guess this is standard when dealing with print, but it makes no sense to me. When you use the watermark action your origin is actually the bottom left instead of the top left. So when it comes to positioning things, you have to measure the height of the watermark, and calculate how much to adjust the y axis in the negative. By negative I mean that you give it a positive number to move the water mark upwards, so the opposite of how you might set a div with position:absolute
3. When you use the getinfo action it will give you a height and width, but in points instead of pixels, so be ready to do some .75 and 1.25 conversions to properly deal with pixels to points and back. And since I just mentioned watermark positioning, you position in pixels, even though the getinfo is in points, so keep that in mind when you are attempting to line things up. Sub point to this, if you have a landscape page it will still say it's 8.5x11 inches instead of 11x8.5, but also that it has a rotation of 90, so remember to take that into account when determining what your height and width actually are.
4. While cfdocument does great converting HTML to PDF, there isn't really a simple way to window one PDF inside another generated with your HTML code, but using the watermark action does a pretty good job of layering one PDF into another, so you can generate your outer PDF then use watermark to layer your inner PDF in that border. You can do this with multi-page PDFs by generating your border, then looping through the PDF you want surrounded by that border, then use the watermark feature iterating through the pages. At the end you merge them all together and you have a nifty new PDF windowed in your custom border. I also used the transform action to scale down the inner PDF to fit within my border so my output was still an 8.5x11 inch page.

That's all I have come up with so far, I'll add more as I come across them.

SVN Error Pristine text not found

Doing some work today I started having a little trouble with my working copy. For reference we use visualSVNServer over an HTTP connection on our local network, and our client tool is SmartSVN. I tried to commit some code and got an error that SVN was busy. Not really sure what that meant, I waited a second and tried again, now it tells me:

Commit failed: Pristine text not found

Again, not sure what that means, lets try to update, same error. OK, obviously something borked in my working copy, clean-up usually fixes that. Again: "Pristine text not found" What does google have to say about it? Not a whole lot, just that other people have seen that error, and no real clues on how to fix it.

Since we upgraded to subversion 1.7 I have noticed that periodically SmartSVN tells me I should validate my admin area. When it's done this in the past I've noticed status messages saying something about pristine somethings or other, so I run the validate admin area command, and low and behold we seem to be getting somewhere. I get a warning that my pristine copy isn't correct and that SVN is going to try and fix it, but if it doesn't I should do a fresh checkout. I let it do it's thing and it makes a few notes that it's removing some items from the pristine table, and warns me that it installed some new pristine files and even downloads a copy of one of my files from the repo to restore my pristine copy.

Interestingly the file it gets is a revision number higher than my current working copy. What's this? It appears that somehow my commit succeeded to the repo, but my client didn't seem to realize it. So in the end, simple client error resulted in a working copy that was out of sync, and validating the admin area was able to clear it up. I'm now able to update my working copy and commit code with no problems again.

Dreamweaver not closing cfquery

We recently upgraded to Coldfusion 9 here at the office, and most of us are using Dreamweaver CS3 as our text editor of choice for CFML, which very has a nice little upgrade that will make code complete work for the new tags and the changes to the existing ones. If you didn't know about it, you can download the patch here.

After I applied the patch I started noticing that the code complete would not auto close a cfquery tag, and would in fact, auto close the parent tag. This was highly annoying behavior that easily goes unnoticed during rapid fire coding and results in instantaneous bugs. I have Dreamweaver set to auto close a tag as soon as I type </ which made this even more annoying as a quick attempt to properly close the cfquery tag, would just result in another wrong close tag being inserted. So I would have to carefully highlight everything after </cf and type in the rest. Fatal bug? No, but after three or four times, annoying enough to need immediate change.

Of course it's not obvious what the bug is, so I have to sort through a lot of results thrown back from the search engine before finally finding a forum post from someone going by the name 'Krakajap' who figured it out. He got me pointed in the right direction, but his solution was a little excessive and I figured out a simpler way to do it.

The problem is a typo in the config files for Dreamweaver. You can find all the xml files that tell Dreamweaver what to do with tags at approximately:
C:\Users\[you]\AppData\Roaming\Adobe\Dreamweaver 9\Configuration\TagLibraries\cfml
or wherever in your OS Adobe sticks these folders. You will see a htm and vtm file for all your cfml tags. You want to edit the vtm for cfquery. You'll see the problem right away on line two. Just change:

<tag endtag="no" name="CFQUERY">

to:

<tag endtag="yes" name="CFQUERY">

Restart Dreamweaver and away you go.

Coldfusion 9 Fails to send mail when using cfMailParam to set the content type to text/html

We recently upgraded to ColdFusion 9 and have had our share of migration pains. Today I discovered a new one. We have a newletter that goes out on a fairly irregular basis and today was the first one since the migration. Hours after it was scheduled to be released I got notified that no-one has received it yet. So I check the undelivered mail and yup, there are almost 4k messages that ColdFusion refused to send to the mail server.

As Sherlock would say, the game is afoot. First, let's rule out the most likely suspects. Looking at the mail log, I see errors for them all, but the error message is blank. I check the mail server connection, it's fine. I try dropping a few back into the spool, but they just get kicked back to undeliverable. I check the SVN logs and see that no code changes have been made to the file involved. Great, not going to be an quick and easy bug hunt.

Interestingly, while looking at the undeliverables, I was still able to see messages hitting the spool and processing normally. Thinking to myself, "what makes them different" I manage to open one before it processes out and start to compare it to the ones that won't. Fortunately the difference was on line one: the ones that won't sent say "type: text/html" the ones that will say "type: text/html; charset=UTF-8". So I change that line on one of the failures, send it back over to the spool, and it processes normally. Great! Fix it in all of them, send the batch over to the spool and we are in business.

But why did this happen?

I pull up the code for the mail that went through fine, and for the one that didn't and look at the cfMail tag. and here is the big difference:

Good:

  <cfMail [typical settings] type="html">
    Mail Message
  </cfmail>

Bad:

  <cfMail [typical settings] [no type attribute]>
    <cfmailparam name="content-type" value="text/html">
    Mail Message
  </cfmail>

The bad code here worked fine in CF7, but just results in undeliverable mail in CF9. I can't tell you why, but hopefully my investigations help save someone out there some time.

WTF Users?

So today I was again reminded that users will do things that I, as a developer, would never think of doing. And of course they either don't remember how they got into their predicament, or refuse to tell. Today's conversation went something like this:

User: It's broke.
Me: Which browser?
User: IE.
Me: (internally: Noooooooooooooooo!) Seems to work okay on my end, which version of IE?
... insert some back and forth while I guide the user into determining the version, and which browser mode and document mode is currently active...
Me: Still seems to work fine, see what happens in another browser.
User: How do I open the page in another browser?
Me: Open browser, copy address from IE into other browser.
User: When I copy the address, it looks like it has a lot of question marks in it.
Me: Interesting, IM that over to me.
User: "http://www.webaddress.com/folder??x=y?x=a?x=z"

So now I'm trying to figure out how the user made this happen, and between the server log and that IM I have determined that the user made a selection, hit back, selected the null item of "please select something" before making another selection. While I couldn't believe that someone would take these steps, it did teach me to take better care what I do with my Javascript. instead of writing:

window.location += "?x=y";

I changed it to more correctly be

window.location.search = "?x=y";

Arguably I should have done that in the first place, but it took a user doing something I would never expect any user to do in order to show me the error of my ways.

The moral of the story is get the worst possible users (I'm talking about the ones that need a new PC from IT every 3 months because they have 10 browser tool-bars and a bajillion viruses and other malware installed, or they somehow accidentally deleted windows.) testing your work at the earliest possible stage. It's really the only way to fool-proof your code.

Customer Service, and customer friendliness.

So what do you use to share images? Me, as a long-time redditor I use imgur. It's decently light-weight and give you several link options to access your images, including direct linking. But I have one major problem with imgur, and really with almost any service such as bit.ly and goo.gl that takes your input and spits out a random string of characters that now represent your item. They are almost never clean of visually ambiguous characters. So I can easily share a link via e-mail, reddit, twitter, face-book, and when I'm feeling especially masochistic, google plus. But I can't easily look at the link, write it down and hand it to my mother.

This became especially apparent at a recent family get-together when I took some pictures on my phone, uploaded them to imgur with their app and wrote down the album address on a post-it so my grandmother could look at them. I had three indistinct characters out of five, needless to say I screwed one of them up and grandma did not get to see her pictures. And considering what kinds of images get posted on imgur, very well could have been looking at some sort of porn.

Now, I know that having the shortened string being case sensitive means that we will have shorter string longer, but would it really be that difficult to reject certain characters from your algorithm? We can do without having I and l both, O and 0, and whatever else looks rather similar in standard fonts.

As developers, we should try to keep in mind that a friendly URL is going to be more easily shared, and not just via the crude and barbaric pen and paper, but also in cases where some email and message board services post links as straight text. If I only have 5 characters to worry about, I'm going to find it easier to just type them in the address bar than to copy and paste, but using characters I have to really look close at to determine what they are, ruins my flow, and maybe that picture or link just isn't really worth following all of the sudden.

So if you're generating anything like this for your users, make it friendly for your customers, and make sure it's easy for them to read, not force them to rely on copy/paste.

So that's the customer friendliness portion of today's bit, but what about the service?

Well since imgur is my favorite photo sharing site, I decided to suggest that they filter out those unfriendly characters from URLs they generate in the future. I made my suggestion, and it even got a few up-votes in their suggestion/bug system. In less than 24 hours it was marked declined and I was give no response as to why. What was troubling to me about this is that others had basically suggested that the crew at imgur go f#$% themselves since their site had some minor bug. This rather rude bug report got a kindly worded reply from the same user that rejected my suggestion.

So now imgur has publicly shown that being a bag of douche gets you treated nicely and making an honest suggestion gets the cold shoulder. Maybe the people over at min.us know how to treat customers a bit better.

Being a developer I know that it's sometimes hard to interact with customers. You never know their technical acumen and quite delicately have to walk the boarder between communicating good information, and insulting them with condescension. But no matter what, it's never a good thing thing to ignore them completely. That's almost a guaranteed way to loose a customer.