Encode HTML Characters in JavaScript using jQuery

Here's a quick post on how to encode and decode HTML characters in JavaScript using jQuery. I didn't come up with the solution, but I thought it was pretty clever.

function htmlEncode(value){
    return $('<div/>').text(value).html();
}

function htmlDecode(value){
    return $('<div/>').html(value).text();
}

Courtesy of http://stackoverflow.com/questions/1219860/javascript-jquery-html-encoding

jQuery Naming Conventions: Don't Prefix Variables With $

When working with jQuery, I hate it when developers prefix their variables with dollar signs. For example, var $buttons = $('.button');. In my opinion the dollar sign really hurts the readability of the code.

Some developers claim that adding the dollar sign is a good naming convention because it shows that the value represents a jQuery object. If that's the case, then everybody should start using Hungarian notation all of the time. Gross.

The one exception I might make is for var $this = $(this);, although even then I would rather prefer something like var me = $(this);.

Long story short, don't prefix your variables with a dollar sign. Besides, it's not like you're working with PHP or anything.

ColdMVC Updates 1.3.7

Here's a quick post describing some small but relatively cool updates to ColdMVC in version 1.3.7: http://bit.ly/ColdMVC-Updates-1_3_7

ColdMVC Documentation Updates

I recently added some more documentation for ColdMVC:

* An overview of models in ColdMVC: http://www.coldmvc.com/guide/models

* Query operators in ColdMVC: http://www.coldmvc.com/guide/operators

* Building complex queries in ColdMVC: http://www.coldmvc.com/guide/queries

* Getters and setters in ColdMVC: http://www.coldmvc.com/guide/getters-and-setters

* Specify required params for an action: http://www.coldmvc.com/annotations/params

* Specify allowed request methods for an action: http://www.coldmvc.com/annotations/methods

Advanced INI Parsing in ColdFusion

At work, I've been using the Zend Framework for PHP a lot. One of the best features in my opinion is how you're able to manage your configuration settings between different environments within a project.

I've always been a fan of using INI files for storing configuration settings, but the Zend_Config_Ini class that Zend Framework comes with takes INI files to a whole new level by adding section inheritance and nested properties.

After a couple hours, I was able to take the same powerful functionality that Zend Framework provides and port it to ColdFusion, mainly for the purpose of adding it to my ColdMVC framework.

Why do I think this is cool? Let's look at a sample INI file that you might see on a project:


; Settings for the production environment
[production]
autoReload = false
development = false
reminderService.sendReminders = true
facebook.api.username = prod@mycompany.com
facebook.api.password = 90ujlc890$f

; Settings for the staging environment
[staging : production]
reminderService.sendReminders = false
facebook.api.username = staging@mycompany.com
facebook.api.password = 879kjasdf!

; Basic settings for the development environment.
; Each developer should create their own environment that extends this one.
[development : staging]
development = true
autoReload = true

; Settings for Tony's development environment
[development-tony : development]
emailService.options.forceTo = [ "tony@mycompany.com", "tony@gmail.com" ]
facebook.api.username = tony@mycompany.com
facebook.api.password = w1nn1ng

; Settings for Ryan's development environment
[development-ryan : development]
emailService.options.forceTo = ryan@mycompany.com
facebook.api.username = ryan@mycompany.com
facebook.api.password = govikes

; Settings for Joe's development environment
[development-joe : development]
emailService.options.forceTo = joe@mycompany.com
facebook.api.username = joe@mycompany.com
facebook.api.password = welcome


Pretty straightforward settings file. Each environment has its own section, but now it comes with a twist.

See the colons in the section names? That's inheritance in action. If you look at the development-tony environment, you'll see that it extends the development environment, which extends the staging environment, which extends the production environment.

Also, notice the periods in the property names. Those are nested properties, which will be automatically converted to ColdFusion structs at runtime.

So how does this work? Pretty simple:

var ini = new Ini("/path/to/config.ini");
var config = ini.getSection("development-tnelson");

If I were to now dump the config variable that was returned, I'd see the following output:



Pretty sweet if you ask me.

You can find all of the code on GitHub at https://github.com/tonynelson19/ini/, which also includes 26 green unit tests.

Also, I've included the new INI parser in the latest version of ColdMVC, which you should definitely check out if you haven't yet.

ColdMVC Quick Start Tutorial

I recently wrote a Quick Start tutorial for ColdMVC, my convention-based MVC framework for ColdFusion 9. Check it out and let me know what you think.

http://www.coldmvc.com/quickstart

Code Formatting and New Lines

Last week I had a healthy debate with some co-workers about code formatting, which to a lot of developers can be a pretty religious subject. While you could argue that coding style should be a personal preference, I believe it's more important to use consistent coding practices when working in a team environment.

One formatting style we discussed was the use of new lines in code blocks. Here are three common formatting styles for the same code:

Style 1

if (true) {
    console.log('yay!');
} else {
    console.log('boo!');
}

Style 2

if (true) {
    console.log('yay!');
}
else {
    console.log('boo!');
}

Style 3

if (true)
{
    console.log('yay!');
}
else
{
    console.log('boo!');
}

When I first starting coding, I preferred Style 3, since it provides more visual separation. Currently I prefer Style 2, although it's not even a formatting option at http://jsbeautifier.org/, which makes me question my choice a little. Douglas Crockford seems to prefer Style 1, so maybe I should consider making the switch.

Which do you prefer?

Don't Mix Tags and Script in the Same Component

Every now and then, I'll see some code in an open source ColdFusion project that mixes tag syntax and script syntax in the same component. Personally, I find it really annoying when people jump in and out of cfscript blocks. If the component isn't written entirely in script, then don't use any script - stick with tags.

Some people think that since writing in script is cleaner, it's cleaner to write part of the function in script than write it using tags. However, if you're declaring your component and functions in tags, switching to script inside the function actually decreases your code readability in my opinion. Take the following hypothetical example, which is sadly all-too-common in certain open source projects:

<cffunction name="setFoo" access="public" output="false" returntype="void">
 <cfargument name="foo" required="true" type="string" />

 <cfscript>
  variables.foo = arguments.foo;
 </cfscript>


</cffunction>

<cffunction name="getFoo" access="public" output="false" returntype="string">

 <cfscript>
  return variables.foo;
 </cfscript>

</cffunction>

I find this style of coding ridiculous.

Amazon Order Arrival Date

I expected better from you, Amazon...

Fail.

Using Markdown in ColdFusion

Markdown is "a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML)."

Here's a quick post describing how you can use Markdown in ColdFusion.

First, download MarkdownJ, a Java port of the Markdown conversion utility originally written in Perl. Here's a direct link to the download site: http://code.google.com/p/markdownj/.

Next, either put the markdownj.jar file in the ColdFusion classpath or download JavaLoader. I prefer using JavaLoader, so that's what my example will show.

Finally, some code:

<cfset paths = [ expandPath("markdownj-1.0.2b4-0.3.0.jar") ] />

<cfset javaLoader = new javaloader.JavaLoader(paths, true) />

<cfset markdownProcessor = javaLoader.create("com.petebevin.markdown.MarkdownProcessor").init() />

<cfset html = markdownProcessor.markdown("This is a *simple* example") />

<cfoutput>
#html#
</cfoutput>

The above code will produce the following HTML output:

<p>This is a <em>simple</em> example</p>

OK. So if that's the simple example, what about a more complex example?

# This is an h1

## This is an h2

This is a normal paragraph. Lorem ipsum dolor sit amet,
consectetur adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua.

*  This is a unordered list. Hanging indents allow
 you to wrap a list item onto multiple lines
* List item 2
* List item 3

---
These are horizontal rules
***

This is how to *italicize* something. This is _another way_ to italicize something.

This is how to **bold** something. This is __another way__ to bold something.

1. This is an ordered list
2. List item 2
3. List item 3

This is [an example](http://example.com/ "Title") inline link.

[This link](http://example.net/) has no title attribute.

> This is a block quote. Lorem ipsum dolor sit amet,
> consectetur adipisicing elit, sed do eiusmod tempor
> incididunt ut labore et dolore magna aliqua.

 This is a code block.
 To produce a code block in Markdown, simply
 indent every line of the block by at least
 4 spaces or 1 tab

And that's the basics of Markdown. Here's a full set of syntax rules: http://daringfireball.net/projects/markdown/syntax. Pretty sweet if you ask me.