Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at cf.Objective() 2013 (Bloomington, MN) with:

WooHoo! My Code Coloring Finally Works!

By Ben Nadel on
Tags: ColdFusion

For months and months (on and off) I have been trying to color code my code snippets. It's been very hard for several reasons:

  1. I use UL to display my code (not PRE tags or TEXTAREA tags). This gives me superior control of indenting and code exportation. I CANNOT stand it when people use four spaces to "tab" in their code. (breathe, breathe, let it go).
  2. I want to create clean code. That means using SPAN tags with my own custom classes rather than using inline STYLE attributes to define text colors and style (not to mention this is not XHTML compliant and that is something I am really aiming for).
  3. Lastly, I kept trying to format my code snippets on the fly. This was just taking too long.

I don't have time to go into how I do it. I will cover that later today. But rest assured, all code snippets going forward will be color coded. I might also write a script to update all previous blogs as well. It is not 100% perfect in terms of what it color-codes, but I now have a foundation on which it will be easy to build.

  • <!---
  • This is just a test to desmonstrate that my color coding
  • works in conjuction with UL / LI and multiple lines.
  • --->
  •  
  • <!--- Get Ray's birthday. --->
  • <cfset dtBirthday = CreateDate( 2007, 4, 8 ) />
  •  
  • <!--- Check to see if this is the day. --->
  • <cfif (Fix( Now() ) EQ dtBirthday)>
  •  
  • <!---
  • DUDE! It's ray's birthday, send yourself a reminder
  • so that you can get him something nice.
  • --->
  • <cfmail
  • to="xxx@yyyyyy.com"
  • from="xxx@yyyyyy.com"
  • subject="Ray's Birthday Reminder"
  • type="html">
  •  
  • Today is Ray's birthday. Get him something nice.<br />
  • <br />
  •  
  • <em class="note">
  • PS. He is married and has kids - do not send over
  • any call girls that would just be inappropriate.
  • </em>
  •  
  • </cfmail>
  •  
  • </cfif>
Tweet This Groovy post by @BenNadel - WooHoo! My Code Coloring Finally Works! Thanks my man — you rock the party that rocks the body!



Reader Comments

I'm noticing something odd in the text output. Instead of your simple cfml comment, I get:

<--- --------------------------------------------------------------------------------------- ----

See all the extra dashes? I get the same at the end of the header as well. I do not see these extra dashes in the normal code view.

FYI, I might "innovate" this into BlogCFC.

Reply to this Comment

I think that is part of his header. I only get that in the .txt file that is produced when clicking the download code and it's only around the header which has the blog entry info. All of the other comments are ok.

Reply to this Comment

Boyan, the code coloring on my blog, while nice, is very old. It was made by Doug Cain I believe, many years ago.

I DID try the code you mentioned, dp.SyntaxHighlighter, but it was buggy with CF. RIAForge still uses I think and I need to rip it out soon.

Reply to this Comment

@Ray,

Yeah, I put CFML comments in the TXT download. It just contains a link back to the blog so that if someone ever downloads the code and then has no idea where it came from... it's all right there in the header.

If you are only getting the comment though, something is wrong.

Oh, and feel free to innovate anything you want. My code is your code. I have the code both for the color coding AND the TXT file download posted somewhere on the site. If you want to look at it, just search, or shoot me a comment.

@Kain,

Thanks dude :)

Reply to this Comment

@Ben - no, I'm not getting just the comments. Please reread my comment. When I view your code on the blog, I see simple comments like so:

<!--
..
-->

But the text download is different. it is more like this:

<!-- (lots and lots of dashes)
..
(lots and lots of dashes) -->

So the main concern is - what I see in the browser is not what I see in the download.

Reply to this Comment

@Ray,

I added the header comments for some extra information about the code and where it came from. Do you think it's more confusing that it's worth? When I code, I generally have comments at the top of my files, so for me, it's a matter of habit. But if people are not used to that, I can see that it might be confusing - hey, what the heck is this? This is not what I clicked on?

Reply to this Comment

So I'm confused. Are you saying then that the download should NOT be the same as what a person sees on screen? I'm not complaining about your comments on top. It kind of sounds like you are explaining why you have comments and that is _not_ my problem. Again - my problem is that the code view seems to be different from the download view.

Reply to this Comment

@Ray,

I too am confused :) I think it stems from the fact that these features have been built over time and there are things to consider (and I am sure there are inconsistencies). So here's a basic run down.

In my Database, I have two field for the blog entry:

- content
- formatted_content

The content holds the plain HTML and code snippets (one TEXT field). Yesterday, I added the formatted_content field. This field has the same content as "content" but it has color coded code snippets. I do this so that I do not have to do the color coding on the fly and do I don't have a lot of extra noise in the "content" that is used for other things.

When I enter the blog entry in my admin, it stores it in "content" and then color codes it and stores that value in formatted_content. This lets me do the heavy lifting of color coding on input, not output.

Ok, so then there are ways to access the code. In the standard view page (this one), I check to see if there is formatted_content. If there is a grab that one, else I grab the content. So this page might be pulling from one or the other.

Then, there is the "view code" pop-up that has the cut-n-paste functionality:

http://www.bennadel.com/index.cfm?dax=blog:602.viewcode&start=1094

This page ONLY uses the "content" field. The color coding in the page IS done on the fly and is, in fact, my very first color coding exploration from months ago.

Then, there is the "download code" prompt. This also uses the "content" field, NOT the formatted_content. After all, no color coding needed here. This process is explained here:

http://www.bennadel.com/index.cfm?dax=blog:520.view

That process adds a CFML comment to the top of the file (with the title of the blog and link to the code download) just to give a bit more information for when the code is viewed later on (on your machine).

Now, both the "code view" and the "download code" features strip out all the the UL/LI from the code snippets on the fly, so there might be some room for error there ;)

But, theoretically, the code in the content and the formatted_content fields are exactly the same (when there is data in the formatted_content field). But yes, some of the outputs change depending on the "feature" you are using.

Does that help clear up some of the madness :)

Here is how I do my "view code" pop-up:

http://www.bennadel.com/index.cfm?dax=blog:320.view

Reply to this Comment

I'm very disappointed. I never release software that has bugs or missing features in it. I spend hours with my QA team going over every single facet of the application and ensure it is perfect. I simply do not understand why you cannot do the same. Shame. Shame on you Ben Nadel. May the mouths of a thousand toads bite the hidden parts of your body!

So - um - seriously - sounds like you get me then. So just fix it then. ;) It is a minor nit - but seeing something different, even as simple as extra dashes, really threw me for a loop.

Reply to this Comment

@Ray,

Trust me, that is excellent feedback. Like I said, I am used to having comments at the top of all my files, so it never phased me or even crossed my mind that it would phase others. But if you are not used to it, and that is what pops up on the text file - Above the Fold for that matter - it can certainly be disorienting.

On this note, I will probably remove the comment at the top. It really serves no higher purpose other than to point back to this blog.

I guess that was the week my User Experience Testing room with recording web cam and double-sided mirror was fully booked by someone else ;)

Reply to this Comment

Woah. Dude. Ok, seriously, I don't we are on the same track here. You said,

"Trust me, that is excellent feedback. Like I said, I am used to having comments at the top of all my files, so it never phased me or even crossed my mind that it would phase others. But if you are not used to it, and that is what pops up on the text file - Above the Fold for that matter - it can certainly be disorienting."

Let me be absolutely clear. There is NOTHING wrong with your comments on top. I do the same thing. My ONLY complaint is that what I see in the browser is NOT the same as what I see in the download.

Is that not making sense? It's like I saw:

Hi

in the browser, and

Bye

when i downloaded. THAT is what I'm talking about. The _fact_ that you used comments on top is fine, and again, is what I do as well.

Reply to this Comment

@Ray,

I am not talking about changing the way I code. I was only talking about removing the content form the download-code feature. The comments in my standard files will remain the same.

Maybe I misunderstanding what you mean. If you were me, how would improve the "work flow"?

Reply to this Comment

Heh, we should get on the phone. ;) So you don't understand what I mean? I'll try again. What I see in the browser is NOT what I see in the download.

That's it. Does that not make sense?

Did my HTML example in the last comment make sense?

Reply to this Comment

@Ray,

Is the only difference the CFML comment at the top? If so, would you suggest I remove that from the download?

Reply to this Comment

@Ray, not to beat a dead horse... but would you like me to change my download code thing? Or were you just confused that it was different (and now that you know, it's not an issue)?

Reply to this Comment

I don't think we are still on the same page though. I didn't see a response as to why download != web page. Or did you answer that and I missed it?

Reply to this Comment

I just put the comment at the top of the download file to tie it back into the website. It's like a mini-readMe built into the download. It was just an arbitrary decision.

Reply to this Comment

"I DID try the code you mentioned, dp.SyntaxHighlighter, but it was buggy with CF." --Raymond Camden

Since dp.SyntaxHighlighter does not come packaged with a CFML "brush," I'm not sure what implementation you're referring to, but the library has good enough groundwork laid in the core file that it should be quite possible to make it work nicely with CFML.

Reply to this Comment

I used either the XML or HTTP brush - I forget which. I spoke with the author of the project, and he did help me a bit. I found a bug where words were duplicated, and I reported it, but I did not hear back. Now I don't blame him for that - I know how hard it is to support OS projects, but the bug was enough for me to remove it from my site, since it made my code blocks harder to read.

Reply to this Comment

I found some bugs in it too... for example, the XML brush (probably among the others) doesn't really support multi-line comments, even though the documentation specifically claims it does (and gives a very simple example that works).

That was very easy to fix (it's a simple matter of replacing "this.GetMatches(new RegExp('<!--\\s*.*\\s*?-->', 'gm'), 'comments');" with "this.GetMatches(new RegExp('<!--[\\S\\s]*?-->', 'g'), 'comments');"), but it made me think there was very limited testing (it should have been easy to discover that the "m" flag doesn't work as advertised in most browsers). Other errors in the brushes (I think I encountered your double-word bug at one point, and a corner case with spacing that was really nasty) showed me that the library could indeed use a little work.

Still, I really like the ease of adding new brushes and some of the library's concepts and implementation, so here's hoping that the author gets a chance to improve it further.

Reply to this Comment

"(it should have been easy to discover that the "m" flag doesn't work as advertised in most browsers)" --Me

To clarify, it actually does work "as advertised" in browsers which support it (JavaScript 1.5+), but the meaning is different than that which I think the author of dp.SyntaxHighlighter intended, based on the regex for multi-line comments shown above, and others throughout the various brushes. The m flag stands for Multiline Input, which makes "^" and "$" match at the beginning and end (respectively) of each line. However, it seems as if it was being used to mean "dot matches newline," which is certainly not what it does (and some of the regexes are flawed as a result).

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.