In 1995, while working at the engineering firm of Clark, Richardson and Biskup, I was given the opportunity to become a Network Administrator. They were a Mac shop and I was the only person who knew anything about PCs. I learned lots of things about networking, CAT5 cabling, Novell (!), keeping users happy and the importance of daily backups. During this time I also became intrigued with the “World Wide Web” and began teaching myself HTML.

While I developed my own ‘blog’ (at the time a lot of static pages), I also volunteered for a local animal rescue group who had a static one page site and soon began making it dynamic using Perl. At work I began creating what would later be called an ‘intranet’. I was using Perl there as well but two new languages caught my eye: ASP and Cold Fusion.

Researching both I immediately gravitated to Cold Fusion. It was tag based (just like HTML) and comparing code samples it seemed like a no brainer. What took 3-4 lines in Cold Fusion was 10-15 lines in ASP. Why would anyone want to write MORE code? Armed with my fresh copy of Homesite 1.0 I was ready. I soon began doing more and more web development and less and less network administration.

I soon developed both an intranet and external site for Clark, Richardson and Biskup build on Cold Fusion. Goodbye Perl. I overhauled the pet rescue website and created tools to allow them to manage the content themselves.

Fast forward a few years and I still think I made the right choice. ColdFusion has matured nicely and I hope I have as well :)

Before we add our form we’ll setup some things for ValidateThis.  First we’ll add the necessary jQuery libraries. There are various ways to do this but here I’m using the new Asset Manager component in Model-Glue to load my .js files.

<cfset event.addJSAssetFile( "validate/jquery.validate.pack.js" ) />
<cfset event.addJSAssetFile( "validate/jquery.field.min.js"  ) />

Next we need to setup our ValidateThis service. getInitializationScript() is going to setup our client side jQuery for us – here I’m telling it not to include the requires jQuery libraries as I’m managing that manually.  In the latest ValidateThis you don’t even have to install jQuery – it can pull the necessary files from a CDN.  getValidationScript() will actually look at our rules file and create the specific jQuery validation rules for our form.

<cfset validationService = event.getModelGlue().getValidationService() />
<cfset event.addJSAssetCode(validationService.getInitializationScript(JSIncludes=false)) />
<cfset event.addJSAssetCode(validationService.getValidationScript(objectType="faq")) />

Finally we can get a list of required fields from our rules file.  Here I am passing in my object type so ValidateThis knows what rules to apply.

<cfset variables.requiredfields = validationService.getRequiredFields(objectType="faq") />

I’m using the excellent <a href=”http://cfuniform.riaforge.org/”>cfUniform library</a> for my forms.  Below we setup our form, and you can see I’m passing in my the “requiredFields” we defined earlier.  cfUniform will use this to flag the fields as required with an asterisk.

Below is my simple form.  You’ll notice there is no markup for validation rules!

<uform:form action="#commitEvent#"
 id="frmMain"
 attributecollection="#CFUniformConfig#"
 submitValue=" Save FAQ "
 requiredFields="#requiredFields#"
 cssLoadVar="uformCSS"
 jsLoadVar="uformJS">

<uform:fieldset>
<uform:field label="Question"
 name="faqquestion"
 type="text"
 value="#faqRecord.getFaqQuestion()#" />

<uform:field label="Answer"
 name="faqanswer"
 type="textarea"
 value="#faqRecord.getFaqAnswer()#" />

</uform:fieldset>
</uform:form>

But, if we load this in our browser and view source, we’ll see our jQuery libraries loaded and then some code for ValidateThis (created by getInitializationScript()):

<script type="text/javascript" src="/modelglueextensions/jQuery/validate/jquery.field.min.js"></script>
<script type="text/javascript">
 jQuery(document).ready(function() {
 jQuery.validator.addMethod("patterns", function(value,element,options){
 var minMatches = 1;
 var complexity = 0;
...
 , jQuery.format("")); jQuery.validator.addMethod("futuredate", function(value,element,options) { var dToday = new Date(); var dValue = new Date(value); if (options.after) { dToday = new Date(options.after); } return (dToday < dValue); } , jQuery.format(""));
 });
</script>

If we keep scrolling we’ll see our form specific validation code:

<script type="text/javascript">
jQuery(document).ready(function() {
$form_frmMain = jQuery("#frmMain");
$form_frmMain.validate();
if ($form_frmMain.find(":input[name='faqquestion']").length) {
 $form_frmMain.find(":input[name='faqquestion']").rules(
 "add", { required : true, messages: {required: "The question is required."}
 });
 ...
</script>

And if we examine the form itself we’ll see our required fields (which we told cfUniform about) have been flagged with a ‘required’ class:

<input name="faqquestion" id="faqquestion" type="text" class="required" />

Checking out the form itself we can see our required fields are marked:

Required fields

And submitting the form with empty values gives us nice, user friendly error messages:

Friendly errors

In the next post we will look at server side validations and adding some additional constraints to our rules file. We’ll  also explore the power of ‘contexts’ which allow you greater control over what gets validated and when.

ValidateThis is a framework that allows you to define validation rules for your ColdFusion objects in a single place (either an XML file, a JSON file or in ColdFusion code) and will then generate client-side and server-side validations for you.

Hopefully you are doing server side validations for all your forms and with the various Javascript libraries making client side tasks much easier there should be no excuse there either.

But if you are like me you usually end up with two sets of rules, one for the server side, and one for the client.  Maintenance quickly becomes a chore, validation rules become complicated and eventually something will break or worse yet, slip through your code.

ValidateThis eliminates all those headaches. With a single, simple XML file you define your rules in ONE place and magically your server side AND client side validations are generated.  Business rules change? Update the XML file and you are done. Easy.

Installation

Getting started is easy too.  Head over to RIAForge and download ValidateThis.

Installation is well documented on the ValidateThis wiki (the documentation in general is outstanding) but in a nutshell:

1. Download the framework.
2. Unzip.  Either into the webroot, or elsewhere and create a ColdFusion mapping called ValidateThis.
3. Copy the JavaScript files from /client/jQuery/js/ into a folder that will be accessible by your web pages (e.g., /js/ off your web root).

Follow The Rules

Next you need to define your validation rules.  Head over to the wiki and check out the Sample Rules Definition File.   While the rules can get quite complicated doing simple validation is easy as this:

<property name="faqanswer" desc="answer">
  <rule type="required"/>
</property>

Connect Everything

Once you have your rules defined integrating ValidateThis into your application is easy.  There is documentation covering the major frameworks.  You can also pass ValidateThis a simple struct for validation. See the docs for details.

I’m using Model-Glue and ColdSpring. In my ColdSpring.xml file I define my service, configuration and validateThis beans like so:

<bean id="modelglue.ValidationService" class="ValidateThis.extras.ModelGlueValidationService">
	<constructor-arg name="ValidateThisConfig"><ref bean="ValidateThisConfig" /></constructor-arg>
</bean>
<bean id="ValidateThisConfig" class="coldspring.beans.factory.config.MapFactoryBean">
	<property name="sourceMap">
		<map>
			<entry key="JSRoot"><value>/modelglueextensions/jquery/validate/</value></entry>
			<entry key="definitionPath"><value>../model/</value></entry>
		</map>
	</property>
</bean>
<bean id="ValidateThis" class="ValidateThis.ValidateThis">
	<constructor-arg name="ValidateThisConfig"><ref bean="ValidateThisConfig" /></constructor-arg>
</bean>

I’m also using ColdFusion 9 ORM so validating my objects is as easy as creating my object, populating it and passing it to ValidateThis:

<cfset local.faq = EntityNew('faq') />
<cfset local.faq.setFaqQuestion( Trim(arguments.event.getValue('faqQuestion')) )  />
<cfset local.faq.setFaqAnswer( Trim(arguments.event.getValue('faqAnswer')) )  />
<cfset local.result = beans.validateThis.validate( theObject=local.faq ) />

Now we can simply check local.result.hasErrors() and proceed with either saving our object or returning to our form with out errors.

This was a quick introduction… in our next post we’ll look at what we need to add to our form to get client side validation.

But I thought I’d post it to help others who may run into this issue.

I was writing some new ValidateThis rules and one was not firing…  I assumed I was doing something wrong in my rules file so I was trying all sorts of iterations with no success.

My rules looked like:

<property name="PID" desc="PID">
<rule type="required"
contexts="Coordinator"
failureMessage="A PID is required if the provider is a university employee.">
<param name="DependentPropertyName" value="employeeTypeId" />
<param name="DependentPropertyValue" value="1" />
</rule>
</property>

What I should have remembered  is:

1. That ValidateThis writes both your server and client side validations (which is sooo nice!)
2. The client side is done with jQuery
3. And JavaScript is… case sensitive!

So if we revisit my ValidateThis rule I had:

<property name="PID" desc="PID">

But in my markup (I’m using cfUniForm) I had:

<uform:field label="PID" name="pid" type="text" ...

Doh! Despite my best efforts PID != pid in JavaScript.

I was tinkering with Notepad++ ( a great text editor ) and noticed it had a plugin to sort text…

TextFX > TextFX Tools > Sort lines case sensitive (at column)

This will turn

<cfproperty name="submitURL" ...
<cfproperty name="date_applicant_signed" ...
<cfproperty name="special_conditions_limitations"  ...
<cfproperty name="chair_signature" ...
<cfproperty name="special_privileges" ...
<cfproperty name="applicant_signature_confirm" ...

Into an much easier to scan:

<cfproperty name="applicant_signature_confirm" ...
<cfproperty name="chair_signature" ...
<cfproperty name="date_applicant_signed" ...
<cfproperty name="special_conditions_limitations"  ...
<cfproperty name="special_privileges" ...
<cfproperty name="submitURL" ...

But going back and forth from CFEclipse to Notepad++ was a pain. A quick search turned up the Sort-It plugin for Eclipse.  After installing it you should have a new menu item on the Edit menu > Sort.

I’ve found this is really handy for sorting properties, variable declarations, CSS, etc.

On the client side it uses the excellent jQuery validation plugin, and one issue I’ve run into was error message placement when using radio or checkbox fields.

By default the plugin puts the error message in an awkward location:

This is fairly easy to fix however…

The validation plugin has a LOT of options (documentation) one of them being errorPlacement.

There are a few tweaks we have to make in our file for ValidateThis to make use of this new code.

First lets create a new jQuery script for our errorPlacement and wrap it in a cfsavecontent:

<cfsavecontent variable="validateCode">
<script type="text/javascript">
$(document).ready(function() {
$("#frmMain").validate({
 errorPlacement: function(error, element) {
 if ( element.is(":radio") )
 error.insertBefore( element.parents('div.ctrlHolder') );
 else if ( element.is(":checkbox") )
 error.insertBefore( element.parents('fieldset').children('div.ctrlHolder').first() );
 else
 error.insertAfter(element);
 }
 });
});
</script>
</cfsavecontent>

This defines our errorPlacement and puts a few checks in place to see if we are dealing with a checkbox, radio or normal form field.  We can then define where we want the message placed using normal jQuery syntax.   This will probably require some experimentation depending on your form layout.

To get ValidateThis to use our new errorPlacement we need to load our scripts in a particular order.

1. First we load the jQuery validation plugin script
2. With our script in a cfsavecontent we load it next
3. Followed by ValidateThis code to load it’s rules

<cfset event.addJSAssetFile( "validate/jquery.validate.pack.js" ) /> 

<cfset event.addJSAssetCode(validateCode) /> 

<cfset event.addJSAssetCode(event.getModelGlue().getValidationService().getInitializationScript(JSIncludes=false)) />
<cfset event.addJSAssetCode(event.getModelGlue().getValidationService().getValidationScript(objectType="Form")) />

Here I am using some new features in the latest Model-Glue alpha to load my JS scripts. You could easily replace this with normal script calls.  The important thing to note is we need to load our errorPlacement script before we load the ValidateThis scripts.

If we reload our form now we can see the error message has moved to a better location:

If you are done with your turkey I’d encourage you to go read that, I’ll wait.

I’d like to clarify a few things about my post from yesterday:

1. My blog post was meant to reflect my opinion. I was not speaking for CFEclipse or I’d have blogged about it there (did you know we now have a blog?)  And I wasn’t attacking or slamming anyone. I apologize if it came across that way.
2. I do diddly squat on the CFEclipse project compared to the hard work folks like Denny do under the hood.  When I feel that work is being belittled  I’m going to speak up about it. More on that below.
3. I never mentioned anything about price. I have no problems with Adobe charging for CFBuilder.  We’ve already had that discussion.

After re-reading Adam’s blog post and the white paper my only real gripe is with some of the wording and tone in the blog post.  What irked me (again this is my opinion) were statements like:

In just one version, ColdFusion Builder didn’t just catch up to CFEclipse, it took many steps beyond it.

That is to be expected with a large team of developers and a budget. :)

Professionals who make their living writing code … will also prefer ColdFusion Builder.

I think the paper could have focused more on the positives – CFBuilder is a great tool that should sell itself:  CFBuilder extension (which was a brilliant idea), RDS support, debugging, etc.

There was a lot of discussion which cropped up yesterday. Some of it was negative but overall there was some great insight which I’m going to be thinking about moving forward (and before  I blog again) :)

Today’s a day of thanks and I’d like to thank anyone who uses, or contributes to CFEclipse!

I’d also like to thank Adobe for supporting our beloved CFML language. Everyday I’m thankful I go to work and write ColdFusion instead of .NET.

And next time I see Adam I’ll buy him a beer. No wait – we’re the open source project – he can buy me a beer! :)

Happy Thanksgiving!

Think ColdFusion Builder v.1 and CFEclipse are the same? Think again. Adobe just published a new whitepaper comparing the two CFML development tools to set the record straight. In just one version, ColdFusion Builder didn’t just catch up to CFEclipse, it took many steps beyond it.

I’ve been a avid supporter of CFEclipse for awhile and when Adobe announced they were developing their own IDE – I never saw them as a competitor. There are only two of us – why fight?  But apparently Adobe needs to bash someone and have set their sites on the geeky kid on the playground.

A whitepaper? Really? You could have donated the money you spent on creating that to the CFEclipse project! :)

But clearly we are talking about a two different endeavors here and for Adobe to whip out white papers and comparison charts is a little unfair I think.

CFBuilder is built by a large team of developers.  Their full time job is to develop CFBuilder.  I met several of them at CFUnited and they are a great group who I have no doubt are passionate about their product.  But at the end of the day they are developing a commercial product for Adobe.

CFEclipse on the other hand is a free, open source tool that has been developed over the years by a small, passionate group of people. Many people have worked on CFEclipse over the years but over the years there is usually only one or two people actually cranking out code.

Currently Denny is our main programmer and he has done a tremendous job fixing bugs and adding features.  He’s done that while supporting his family, working a regular job, contributing to other projects and dealing with all the other ‘distractions’ of every day life.  He does that for free.

So why does Adobe feel the need to pick on CFEclipse?

Is ColdFusion Builder a better product?

I don’t think a white paper is going to answer that question. CFEclipse is available to download and install for free. CFBuilder also has a 30 60 day trial version.

Download them both. Try them. Write code. Then make your decision.

And if you like CFEclipse please consider joining our community and help us make it better.

But please don’t take our lunch money.

The community weighs in:

• Charlie Griefer – “On ColdFusion Builder vs CFEclipse and the Sky Falling“
• Nicholas Tunney “Adobe can have my lunch money”
• Stephen Moretti  “ColdFusion Community Rumbles in the Jungle”
• Lola J. Lee Beno  “A Comment on the Recent Controversy” (this is a good one)
  

Model Glue Salesman - Dan Wilson

Over the years I have tinkered with several frameworks. My first was Fusebox. I wrote an entire site for Red Storm Entertainment using the first Fusebox only to have it mothballed before it went live when they were bought by Ubisoft.

Later it was Mach-II, Fusebox 4/5 and recently I’ve dabbled with FW/1 but over the last few years I have been doing a lot of maintenance work on existing sites so there was little opportunity to create an entire site using a new framework from scratch.

And then there is Dan Wilson.

As you may know I co-manage our local ColdFusion user group with Dan and we have organized a few ColdFusion conferences in the past as well.

And Dan owns a framework*. And he likes talking about his framework.

How many hours did I sit in the car driving to CFUnited listening to Dan ramble on about scaffolding, events, view mappings, ColdSpring, content caching, yada, yada, yada?

At CFLunch… bean injection, generic database messages, typed events, helpers…. geez does this guy ever shut up?

CFBeer…  formats, remoting, ses urls, copyToScope…

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh…

But…

I also know Dan is a very smart guy.

So when I started this new project and had carte blanche to do what I wanted I decided to use a framework.

Dan’s framework.  Model-Glue.

So far I really enjoy it working with it.  They took the best bits of Fusebox and threw the rest away. Then they added a bunch of really cool stuff.  I’ve tinkered with scaffolding and along with ORM this allows you to whip together fully functional forms very easily while writing little code.  The documentation is thorough.  They have a ‘quick start’ guide to get you up and running and then a more in depth ‘training’ course.

I  would never recommend one framework over another.  But if you aren’t using a framework – you should be.

And I’d give Model-Glue a look.

Stay tuned – I’ll try to blog about some of my experiences getting started with Model-Glue over the next few weeks.

* Yeah I know it’s not really Dan’s framework -  humor me will ya.  Kudos to all the people who do put in a lot of hard work on the Model-Glue team!!!

Remember your first cfquery?

I can still remember my first. It was the early 90′s and I was tasked with creating an “Intranet”.

Surfing around I found two solutions: Cold Fusion (yes it was originally spelled as two words) and Microsoft’s ASP.

ASP was free!  ASP ran on our Microsoft servers!  But then I looked to see what was involved with creating a query:

ASP *

<%
Dim strname
strname=request("option")
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.ConnectionString="DRIVER={Microsoft Access Driver (*.mdb)};" & _
"DBQ=c:\Documents and Settings\sarvesh\My Documents\db5.mdb"
objConn.Open

dim selectsql
selectsql = "SELECT * FROM first WHERE name = '" &  request("fname") & "' " & strname & " method = '" &  request("method")&"' "

Dim objRS
Set objRS = objConn.Execute(selectSQL)

Do while not objRS.EOF

Response.Write "<U><H3>Name -</H3></U>"  & objRS("name") & " - " & objRS("method")

objRS.movenext
loop
objRS.close
set objRS=nothing
objConn.close
set objConn=nothing
%>

Cold Fusion

<cfquery name="Books" datasource="cfbookclub">
select BookID, Title from Books
where BookID = <cfqueryparam value="#url.BookID#" cfsqltype="cf_sql_integer">
</cfquery>

The choice was easy for me! Less code to write = less work!

On my current project I finally have the opportunity to work with ColdFusion 9 and one of the new features I was most excited to work with was ORM, and it took me back to my first cfQuery.

Make a few simple changes to Application.cfc. Define some properties and then simple do:  EntityLoad(user)

ColdFusion 9 ORM

EntityLoad(user)

It’s just like the first time.  You smile. One line!  I’ve just gotten started and I know you can do so much more with ORM but just this simple one liner brings back the same simplicity that originally drew me towards ColdFusion.

* Please don’t email me and say that’s a bogus ASP script – just trying to make an example  :)