I won’t be able to make it again this year but that doesn’t mean you can’t go! :)

For a whopping $72 you get not one, not two, but three days of open source, CFML goodness…

• OpenBD? Check.
• Railo? Check.
• Mura? Check.
• The opportunity to discuss open source CFML with the people who are building it! Check.

I haven’t looked at either the schedule or speakers (I don’t want to get depressed) but I don’t have to.

Why? Because of the fantastic team who is organizing OpenCF Summit. Organizing a conference is a lot of work but I know folks like Matt, Kurt and Peter are passionate about what they are doing and the sessions and speakers they have lined up are going to be great.

I blogged about open source CFML back in 2009 and I think it’s great to see open source CFML thriving!

No longer are these merely fancy product titles floating around behind an open source idealogy. Now we have some big community members throwing their support behind the concepts! And I know these people will not let these products wither and die. They are all passionate people who have the best in mind for CFML and I’m so excited to come along for the ride!

OpenCF Summit is taking place on Feburary 24 – 26, 2012, at the Special Events Center in Garland, Texas.

Register today!

Someone on Twitter recently mentioned the Sublime Text editor and I’ve been trying it out for the last week or so. Currently I’ve been switching between Gedit (Linux) and Notepad++ (Windows). Sublime Text runs on both so that is a huge benefit for me.

Next question – can you write CFML with it… Doing a quick Google search turns up two solutions:

• https://github.com/justincarter/CFML-SublimeText
• https://github.com/indynagpal/coldfusion-sublime-text-2

I went with Justin’s solution for no other reason than it was the first one I hit. It took me a few minutes to figure out how to ‘install’ this but it’s a few simple steps (there might be an easier way to do this but it worked for me)

1. Download .zip file from github
2. Unzip
3. You’ll end up with a ColdFusion.sublime-package file
4. Rename this to ColdFusion.sublime-package.zip and unzip that
5. Rename the parent directory to just ‘ColdFusion’
6. Then copy this to where your Sublime editor has it’s other language files. On Windows for me this was: C:\Users\jim\AppData\Roaming\Sublime Text 2\Packages\ColdFusion

Crank open a .cfm page and you should see the language switch to ColdFusion and get some basic color coding.

You can explore some of the tags in the unzipped package. I’m still learning my way around Sublime but it appears it supports some ‘auto complete’ like features…

In a .cfm file type ‘cfargument’. Don’t include the opening ‘<'

Immediately after the last letter hit the TAB key. This will add the opening and closing '<>‘ and fill in the available options.

<cfargument name="" type="" required="" default="" displayname="" hint="" />

Subsequent TAB presses will cycle through each attribute. You can easily delete them or fill in their values.

It appears you can also write your own snippets – check out Indy’s download for examples of user defined snippets for ColdFusion.

If you try Sublime please post your comments below – I would love to learn more tips and tricks about this editor.

Update: I’ve setup a wiki page to track Sublime resources (esp those related to CFML).

They include slides, code, a ‘handout’ document, and a readme.txt for instructions.

• ColdFusion and PDF
• Digging Into The Developer Toolbox

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.

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)
  

But I understand the rest of you have to deal with those glitches, typos and other bugs that cause your apps to crash.

I think the vast majority of people either do two things:

• Nothing
• Have the app email you the error message

I’ve done both with vary degrees of success. Nothing is easy.  Emailing errors usually works until you app goes into an endless loop and fills up your mailbox.  Oops.

For my new application I decided to check out BugLogHQ.

BugLogHQ is a tool to centralize the handling of automated bug reports from multiple applications. BugLogHQ provides a unified view of error messages sent from any number of applications, allowing the developer to search, graph, forward, and explore the bug reports submitted by the applications. All bug reports received by BugLogHQ are stored on a normalized database, thus providing the option to the developers to further extend the application to leverage this information.

BugLogHQ has an excellent interface

Setup was a simple matter of creating a database and dumping the app on my server.  Since it is a ColdFusion app it provides a CFC to easily integrate into your application and if you have other apps that don’t support CFCs it also supports SOAP and REST so you can use it with just about everything.

BugLogHQ is a great solution for dealing with errors.  And you can even configure it to send you an email :)

It was my second year attending and first year presenting!

I’d like to thank a few people:

• The folks at CFUnited for selecting me to speak!
• Dan Wilson for giving me a ride
• Anant Pradhan for volunteering (go TACFUG!)
• Everyone who attended my session :)

There was certainly a different vibe this year. Online there was a commotion about the demise of CFUnited and what it meant for ColdFusion.   Dead? Dying?

Who cares!  At the conference I only overheard great things about:

• The ColdFusion community
• The ColdFusion conference scene (NCDevCon anyone?) :)
• The open source trends (RIAForge projects, frameworks, CFML engines, etc)

I don’t think CFUnited coming to an end has any reflection at all on our community.  There will be already are conferences to take it’s place.

They are not  as big and extravagant as CFUnited…

And moving forward maybe that’s a good thing.

For more reading:

• Dee Sadler’s:  The Last CFUnited
• Brian Rinaldi’s: The Final CFUnited – Conference Review

OpenCF Summit is a community gathering focused exclusively on promoting free and open source software in the CFML community.

If you’re interested in getting into the free software CFML engines, enhancing CFML engines through plugins or outright hacking, and socializing with people doing cutting-edge things with CFML, this is the place for you.

Dates: Feburary 21 – 23, 2011, Garland, TX

http://www.opencfsummit.org/

This should be a great opportunity to learn more about the open-source alternatives to ColdFusion!