DEV Community: Michael Born

How to Get the Version of Any Java Package from CFML

Michael Born — Wed, 21 Sep 2022 15:18:20 +0000

The Apache POI library is an awesome tool for messing with spreadsheets. You can read spreadsheet data, get header rows, total row count, all sorts of wacky stuff. Julian Halliwell's excellent spreadsheet-cfml library uses it to great effect.

But when I try to use Apache POI standalone, I got an error that a method didn't exist:

No matching Method/Function for org.apache.poi.hssf.usermodel.HSSFSheet.getTables() found

It would seem that Lucee bundles an older version of Apache POI by default. (UPDATE: Turns out this is only present due to the Apache Tika bundle, which is shipped with Lucee. Thanks Julian Halliwell for that tip!

But what version would that be?

We could easily find out from the Lucee admin page, of course. Provided it is enabled.

But why not try to grab the POI bundle version in code? From our CFML?

Reading a Java Package Version in Lucee

It all starts with the java class:

createObject( "java", "org.apache.poi.hssf.usermodel.HSSFSheet" )

We then grab the java classloader tied to this class:

createObject( "java", "org.apache.poi.hssf.usermodel.HSSFSheet" )
                        .getClass()
                        .getClassLoader()

Once we have that, we need to grab the OSGI bundle:

createObject( "java", "org.apache.poi.hssf.usermodel.HSSFSheet" )
                        .getClass()
                        .getClassLoader()
                        .getBundle()

And finally, grab the version as a string:

var version = createObject( "java", "org.apache.poi.hssf.usermodel.HSSFSheet" )
                        .getClass()
                        .getClassLoader()
                        .getBundle()
                        .getVersion()
                        .toString()

Voila! We have our package version! It seems Lucee ships with Apache POI 2.5.1, released in November 2005. Wow.

UPDATE: Using Lucee's BundleInfo() method

Julian Halliwell (author of the awesome Spreadsheet CFML library) pointed out that Lucee has a bundleInfo() function which does the same thing:

Great post! Lucee has a BundleInfo() BIF which also returns other useful info. - Julian Halliwell, @cfsimplicity

Using bundleInfo() would look something like this:

var version = createObject( "java", "org.apache.logging.log4j.LogManager" ) ).version;

Honestly, this is much nicer than my implemen

Reading a Java Package Version from Adobe ColdFusion

However, in Adobe CF (ACF) this fails because ACF does not architecture packages via OSGI. (Not to my knowledge, that is.) We need to find another method… and it turns out reading package details is even simpler in Adobe.

First, we instantiate the Java Package library:

createObject( "java", "java.lang.Package" );

From there, we get the Apache POI package:

createObject( "java", "java.lang.Package" )
            .getPackage( "org.apache.poi" );

Once we have the POI package, we can grab the implementation version:

var version = createObject( "java", "java.lang.Package" )
                    .getPackage( "org.apache.poi" )
                    .getImplementationVersion();

And that’s it!

A Cross-Engine Solution

Sadly, neither of these solutions work in both Lucee and Adobe ColdFusion due to the differences in Java package bundling approaches between the two engines.

The best we can get would be something like this:

/**
 * Grab installed version of the bundled Apache POI library.
 */
public string function getApachePOIVersion(){
    if ( server.system.keyExists( "lucee" ) ){
        createObject( "java", "org.apache.poi.hssf.usermodel.HSSFSheet" )
            .getClass()
            .getClassLoader()
            .getBundle()
            .getVersion()
            .toString()
    } else {
        return createObject( "java", "java.lang.Package" )
                            .getPackage( "org.apache.poi" )
                            .getImplementationVersion();
    }
}

Sadly, I see little hope for a cross-engine solution that works generically on package names. In Adobe you can grab the package version by package name… but in Lucee you must search for a specific package class.

The POI Version Class

Caveat: Apache POI ships with a “Version” class in versions 3.x. So my example is a bit pointless for Apache POI v3 and newer. If you’re on ACF 10+, you can use the provided Version class to grab the version - no Java Package gymnastics required:

    createObject( "java", "org.apache.poi.Version" ).getVersion()

That’s not the point of this blog post, though. This post aims to assist you in reading the installed version of any Java package - not just those with a handy my.package.Version class.

Till next time!

Redirecting Hibernate Logs to the CommandBox Console

Michael Born — Mon, 30 Aug 2021 13:41:20 +0000

In my last blog post, I covered how to adjust the Hibernate log level with Log4j.

Michael Born

@michaelborn_me

Another quick blog post, this time about resolving a Concurrent Modification Exception in Lucee Hibernate. Kudos to @jclausen for the fix! 💪

michaelborn.me/entry/resolvin…

12:00 PM - 20 Aug 2021

This helped us avoid a concurrent modification exception due to logging certain database entities with the DEBUG logger, but it also sets us up for further interaction with log4j configuration. This week we're going a step farther to take all log4j messages emitted by the HIbernate logger and redirect them to the console. This console is what is shown when you run box server log --follow in CommandBox.

Not sure what Log4j is? Tweet at me and I'll happily cover basic Log4j usage in a blog post.

To begin, we need a Log4j "Logger" object which we can use to grab the Hibernate logger.

var Logger = createObject( "java", "org.apache.log4j.Logger" );
var hibernateLog = Logger.getLogger( "org.hibernate" );

Our log variable now contains a reference to the root hibernate logger. All log messages emitted from any class in Hibernate will pass through this logger.

We can set the logging level - for development, we may want WARN or DEBUG:

var level = createObject( "java", "org.apache.log4j.Level" );
hibernateLog.setLevel( level.DEBUG );

Note: Be aware that the DEBUG log level may cause issues on entity save - see Resolving Concurrent Exceptions in Hibernate Logger.

Now that we have the logger we can reuse one of Lucee's existing log4j appenders to configure log output. This is basically piggybacking on Lucee to pass all org.hibernate logs through the "console" appender to System.Out.

var printWriter = getPageContext().getConfig().getOutWriter();
var layout = createObject( "java", "lucee.commons.io.log.log4j.layout.ClassicLayout");
var consoleAppender = createObject( "java", "lucee.commons.io.log.log4j.appender.ConsoleAppender" ).init( printWriter, layout );

Then finally, we can tell log4j to use Lucee's console appender for all Hibernate logs:

hibernateLog.addAppender( consoleAppender );

Put it all together, and here's what you get:

public function setHibernateLogging(){
  /**
   * Resolves Hibernate ConcurrentModificationException when flushing an entity save with one-to-many relationships.
   * 
   * @see https://access.redhat.com/solutions/29774
   * @see https://michaelborn.me/entry/resolving-concurrent-exceptions-in-hibernate-logger
   */
  var Logger = createObject( "java", "org.apache.log4j.Logger" );
  var level = createObject( "java", "org.apache.log4j.Level" );
  var hibernateLog = Logger.getLogger( "org.hibernate" );
  hibernateLog.setLevel( level.WARN );

  /**
   * Redirect all Hibernate logs to system.out
   */
  if ( listFindNoCase( "Lucee", server.coldfusion.productname ) ) {
    var printWriter = getPageContext().getConfig().getOutWriter();
    var layout = createObject( "java", "lucee.commons.io.log.log4j.layout.ClassicLayout");
    var consoleAppender = createObject( "java", "lucee.commons.io.log.log4j.appender.ConsoleAppender" ).init( printWriter, layout );
    hibernateLog.addAppender( consoleAppender );
  }
}

This method should be placed in Application.cfc early in the application lifecycle. If this method is run during the page request or in onRequestStart(), then Hibernate has already initialized and you have lost a lot of valuable output.

Once this method is in place, we can take advantage of it from CommandBox:

box server log --follow

This is fantastically great for picking up better log details on, say, an invalid ORM entity.

Resolving Concurrent Exceptions in Hibernate Logger

Michael Born — Thu, 19 Aug 2021 20:55:21 +0000

Recently while working on a Hibernate ORM project, I ran into an interesting issue when an entity with relationships is saved inside a transaction.

transaction{
  var myEntity = entityLoadByPK( "Person", theEntityID );

  myEntity.setAddress( otherEntity );
  myEntity.save();

  // throws "ConcurrentModificationException" on transaction end.
}

Note this is not a complete test case - simply an example of when the issue occurs.

When the transaction completes, Lucee tries to flush the entity modifications, but this fails with the following error:

lucee.runtime.exp.NativeException: java.util.ConcurrentModificationException
at java.base/java.util.HashMap$HashIterator.nextNode(HashMap.java:1493)
at java.base/java.util.HashMap$EntryIterator.next(HashMap.java:1526)
at java.base/java.util.HashMap$EntryIterator.next(HashMap.java:1524)
at org.hibernate.internal.util.EntityPrinter.toString(EntityPrinter.java:112)
at org.hibernate.event.internal.AbstractFlushingEventListener.logFlushResults(AbstractFlushingEventListener.java:128)
at org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:104)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
at org.hibernate.event.service.internal.EventListenerGroupImpl.fireEventOnEachListener(EventListenerGroupImpl.java:93)
at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1362)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1349)
at org.lucee.extension.orm.hibernate.HibernateORMTransaction.end(HibernateORMTransaction.java:57)
at lucee.runtime.orm.ORMConnection.setAutoCommit(ORMConnection.java:213)
at lucee.runtime.orm.ORMDatasourceConnection.setAutoCommit(ORMDatasourceConnection.java:336)
at lucee.runtime.db.DatasourceManagerImpl.end(DatasourceManagerImpl.java:350)
at lucee.runtime.db.DatasourceManagerImpl.end(DatasourceManagerImpl.java:330)
at lucee.runtime.tag.Transaction.doFinally(Transaction.java:160)

It turns out this issue is related to the Hibernate debug logger. In Lucee, Hibernate's log4j logger is set to a DEBUG level by default. That's fine, but it seems the logger actually mutates the logged entities during logging. Thus we get a concurrent modification exception.

To resolve this, all we have to do is de-escalate the logging level from DEBUG to WARN.

/**
 * Resolves Hibernate ConcurrentModificationException when flushing an entity save with one-to-many relationships.
 * 
 * @see https://access.redhat.com/solutions/29774
 */
var Logger = createObject( "java", "org.apache.log4j.Logger" );
var level = createObject( "java", "org.apache.log4j.Level" );
var log = Logger.getLogger( "org.hibernate" );
log.setLevel( level.WARN );

This should be done in the Application.cfc before ORM initializes - say, just below the this.ormSettings{} configuration block.

All thanks to @jclausen for this awesome find and easy fix!

Cross-engine transaction detection in Hibernate v3+

Michael Born — Thu, 12 Aug 2021 02:38:55 +0000

UPDATE: Now with Adobe support!

So, this is embarrassing. This article claimed to offer a one-liner with Adobe and Lucee compatibility, but I completely neglected to actually test it on ACF before I wrote the blog post. (I thought I'd tested it... evidently not.) I realized this week after attempting to use my "cross-compatible" transaction detection code that it's not cross-compatible at all!

Bottom line: I updated the article with a properly-tested, fully cross-engine-compatible snippet to detect transactional context on both Adobe CF and Lucee. You're welcome.

We do a lot of ORM work at Ortus, and recently I have been on a bit of a Hibernate binge. One of the important things to note when working with Hibernate is that ORM queries may behave differently inside a transaction block than they do outside a transaction block. More importantly, the transactional handling in, say, Lucee 5.3 begins to break down when working with nested transactions.

I digress, but let's just say it's important to know when the current code is inside a transaction context.

Previously, the best knowledge we had said to run this on Adobe:

// ADOBE ONLY!
var isInTransaction = createObject(“java”, “coldfusion.tagext.sql.TransactionTag”).getCurrent()

and something like this on Lucee:

// LUCEE ONLY!
var isInTransaction = getPageContext().getDataSourceManager().isAutoCommit() ? false : true;

But digging through the Hibernate Session docs, I found a wonderful little method called isTransactionInProgress. And just like that, here's a CFML method to wrap it and consistently detect the transactional context:

boolean function isInTransaction(){
    if ( listFindNoCase( "Lucee", server.coldfusion.productname ) ) {
        return ORMGetSession().isTransactionInProgress();
    } else {
        return ORMGetSession().getActualSession().isTransactionInProgress();
    }
}

That little beauty works

across CFML engines from Lucee to Adobe ColdFusion
across multiple Hibernate versions from v3.x through v5.x

Now, to be fair, I haven't really stress-tested this. It's possible there are a few situations where Hibernate doesn't yet know a transaction has begun. But so far... it works, and works well!

Until next time!

Five Things I'd Like To Learn in 2020

Michael Born — Mon, 13 Jan 2020 12:49:52 +0000

One: How to Debug Slow Execution Times In FusionReactor

I know what Fusion Reactor is, and I know what it does. I even know a little how it works and how to look at a slow-running request.

What I don't know is how to make it useful after that.

FR is really good at breaking down a request, method by method, to show you exactly how long each method call took. What I can't figure out is exactly what those breakdowns mean. You know, the important part of debugging.

So until I learn how to read the above breakdown, I'm only half a debugger.

Two: The Basics of ContentBox

ContentBox is awesome! I think...

See, I know nothing about it. I've tried spinning it up once just for kicks, and immediately got confused with install contentbox-site - like, shouldn't this actually create a working ContentBox site? You'd think so, from the name. But nope - you need to install the installer before you can install the site. Or something.

Regardless, I love that we have a decent option for a CFML-powered Content Management System.

I'd be happy to start developing new sites on ContentBox this year, if only I knew how to use it. The more devs and sites use ContentBox, obviously, the more love and attention ContentBox will get. If nothing else, this year I'd like to put some new site on ContentBox, learn it enough to operate and build the site, and submit a few PRs for documentation typos... one thing I'm good at!

Three: How to Configure WireBox for Vanilla CF Apps

WireBox is awesome. It powers dependency injection in ColdBox and makes it simple to instantiate a component on the fly, or share a singleton across multiple uses per request.

WireBox can also be used standalone to add dependency injection (DI) to a legacy app. In my (uneducated) opinion, this is the best first step towards modernizing your legacy / spaghetti code. Once you have DI set up it becomes easier to rename, refactor, or reorganize your app to fit an MVC framework (such as ColdBox) or simply to make improvements.

Right now, I only know how to use WireBox within the context of ColdBox. This year I'd love to dig deep into WireBox and figure out how it works and how to configure it for a vanilla CF app. If I knew that I could teach it to others.

Four: CB Streams

This one's kinda, you know... deep. Like, intellectually deep, and I confess I have no idea how to use it. I know what cbStreams is and I know vaguely what it's supposed to do:

The whole idea of streams is to enable functional-style operations on streams of elements. A stream is an abstraction, it’s not a data structure. It’s not a collection where you can store elements. The most important difference between a stream and a structure is that a stream doesn’t hold the data. For example you cannot point to a location in the stream where a certain element exists. You can only specify the functions that operate on that data. A stream is an abstraction of a non-mutable collection of functions applied in some order to the data.

quote from the cbStreams README

What I think this means, in a nutshell, is that cbStreams helps you efficiently manipulate large amounts of data in a concise, easy syntax.

To me, that sounds like a useful tool to know!

Five: Ant and Maven Build Tools

I know Ant and Maven are not strictly CF-specific tools. Regardless, the Lucee core, Lucee extensions, and many open-source CFML libraries use Ant or Maven (or both!?) for building their source code.

This is important to me because I'd like to contribute to the Lucee platform. Yet without knowing how to build and run the tests, I won't be able to do that.

And no, only knowing how to ant build fast or something is not good enough. Ideally I should know:

What ant and maven do
What the difference is between the two
How to run tasks
How to define extra tasks (e.g. for adding a test step or build step)
How to debug a failed build.

Conclusion

2020 is going to be an awesome year. I've listed out five CF-related tools I'd ideally like to learn this year - what about you?

Three ColdBox Features I Learned While Building A URL Shortener

Michael Born — Wed, 18 Dec 2019 02:40:29 +0000

Last night I did another live-stream where I finished the first draft of a URL shortener I'm calling "cfShorty". During live-streams I typically end up searching the ColdBox docs for help, but this time Gavin Pickin watched and commented with some cool tips, most of which I'd never used before.

Here are the three ColdBox features I learned while building my URL shortener last night.

Resourceful Routes

This one was cool. Rather than define and tweak my URL routes manually in /config/Router.cfc, Gavin told me how to use the resourceful routing feature to auto-generate my CRUD routes for me.

By simply adding resources( "photos" ) to my ColdBox Router config file (that's /config/Router.cfc), ColdBox will set up all the routes necessary for a CRUD management screen:

List resources page (aka table of entries with Edit/Delete button) via GET /resource
Show individual resource (aka readonly view of a single entry) via GET /resource/:id
Show "New Resource" form to create a new resource entry via GET /resource/new
Show edit form for an existing resource via GET /resource/:id/edit

As well as the three main routes necessary for creating, updating and deleting entries from the database:

Create new resource entry via POST /resource
Update an existing resource entry via PUT /resource/:id
Delete an existing resource entry via DELETE /resource/:id

Obviously, I still had to write the code to handle each event, but ColdBox even makes that party easy by offering a CommandBox CLI command which can quickly build out your event handler, HTML view files, a model object, and even base test specs in your tests/specs directory:

The "Scaffolding Resources" ColdBox docs outline this, but it's as easy as running:

coldbox create resource Users

ColdBox Route Visualizer Module

This module is super handy for debugging your ColdBox routes. Here's what I see when I browse the /route-visualizer page to debug my routes in cfShorty:

To install and use Route Visualizer, all it takes is these three steps:

Run install route-visualizer --saveDev from your CommandBox shell
Reinitialize ColdBox by browsing:
- /?fwreinit=mypass if you have a reinit password set in config/Coldbox.cfc, OR
- /?fwreinit=1 if no reinit password is configured.
Head to /route-visualizer in your ColdBox app.

One thing to note: Make sure to add the --saveDev flag when you install Route Visualizer. You might notice in the live-stream recording that I neglected to do this, causing ColdBox to (by default) install this module as a production dependency in box.json. I do not want production users viewing my ColdBox routes, so I came back later and moved the dependency to devDependencies in my box.json.

HTTP Method Spoofing

This is a small tip, but still super useful for my project. Since my cfShorty is a rough draft/prototype, I am not using any frontend JS like Vue. And since I am not using frontend JS, I have no way to edit a route via PUT /resource/:id because HTML forms do not support the PUT method. (This is something I was shocked to learn when Gavin told me. I guess I'm used to using PUT inside AJAX calls, and never actually tried it in a plain <form method="PUT"> before.) Likewise, I can't delete any resource entries via DELETE /resource/:id because HTML forms do not support the DELETE method either. (And besides - I wanted to use a link tag!)

ColdBox (and Gavin) to the rescue, once again. ColdBox supports spoofing the HTTP method. All you need to do is add a _method url or form parameter which passes your desired HTTP method as the value, like _method=delete or _method=PUT.

With HTTP method spoofing, hitting the ColdBox PUT /resource/:id route is as simple as this:

<form action="#event.buildLink( 'resource.#prc.id#')#" method="POST">
  <input type="hidden" name="_method" value="PUT" />
  <!--- my form goes here --->
</form>

Since HTML forms only support GET and POST, I opted to send the form data via POST to hide the data in the request payload (as opposed to in the URL, which is kinda ugly). Then adding a hidden input to my form which passed _method=PUT causes ColdBox to execute my PUT route, and as easy as that I'm done.

Conclusion

I learned some cool ColdBox tips this session. If you missed the live-stream, you can catch up with the recording on YouTube or simply ask me on Twitter. :)

Adobe, You Piece of Work, I'm Through

Michael Born — Mon, 23 Sep 2019 12:51:08 +0000

When in the course of human events it becomes necessary for one [developer] to dissolve the bands which have connected them with [Adobe].

Lest that title and opening surprise or scare you, let me put it simply: I am fed up with Adobe's handling of Adobe ColdFusion. The product stinks (compared to Lucee), the support and marketing stinks, and this recent "bait and switch" pricing tactic is the last straw.

Consider this camel's back broken.

Terrible Language Support

The first annoyance about Adobe ColdFusion is the poor (excuse me, terrible) language support. ACF has been largely outpaced by Lucee in ease of development. Lucee supports datasource structs, lambda expressions, a cleaner and more useful debugger, tag or function defaults, and on and on. Lucee is now the one who defines and expands the boundaries of the language, while Adobe merely plays catchup - or not.

But even if Adobe never improved the language features (and that's not off by much), the product would hold up for a long time with just a little well-managed support. Unfortunately, ACF has had nothing but the worst sort of language support for a long time now. Ask any ACF developer and they'll inform you that Adobe has a long history of ignoring bugs, declining feature requests, or mismanaging tickets in every way possible. Here is just a short sampling I found in the Adobe bugbase:

fixing tickets without documenting new behavior

The functionality is fixed, but the docs have not been updated. This needs to be an integral part of any work done to the language.

ticket CF-3941602

silently fixing tickets with no further description or notice

I notice this is marked as fixed now. When can we expect to see this fix?

ticket CF-3865461

I notice this is marked as fixed?

ticket CF-3941602

refusing to release hotfixes for obvious, blatant regressions

What is the point of adding an automated update system - with so much fanfare - if you're not going to release bug fixes throughout the year via that channel?

From ticket CF-3910529

refusing to backport bugs to "supported" versions of ColdFusion

Why is ColdFusion 11 even supported? Why not just mark it as End of Life and kill if off if you are refusing to fix bugs? It seems Adobe has a different definition of "Support" than the rest of the world.

This is why developers are getting fed up with the product.

From ticket CF-3952818

Poor Marketing and Customer Outreach

The second major concern with Adobe ColdFusion is the shoddy marketing job Adobe has done with their own product. It's as if Adobe cares more about milking the money from their existing customers than they are about acquiring new ones.

First, Adobe failed to list the Adobe ColdFusion product in the main menu of the site. This is a small thing (yet so easy to fix), but the many requests on this subject have never been addressed by any Adobe employee that I know of.

Second, take a look at the new Adobe Support Community forum. Where is ColdFusion listed? Under the "Print & Publishing" category, of course! WHAT?! This is a clear indication that Adobe does not understand their own product.

Third, any public outcry concerning these items or any others is ignored. I've never seen an official response from Adobe on pretty much anything.

Check out this little nugget from a ColdFusion Marketing blog post by Adobe:

Customer Outreach – We have been having 1:1 discussion with some of our large customers to let them know about what are the features in the new version of ColdFusion and working with them in case they have any issues.

Aha! This all makes sense now - "large customers" are heard, large customers are informed of upcoming ACF features, and large customers get bug fixes or support. Gee - now what on earth am I paying twenty-five hundred dollars for if not the privilege of Adobe support on Adobe products? This is a slap in the face to every non-large customer who has ever purchased Adobe ColdFusion.

Adobe says they listen to feedback, but their actions seem clear: You (ColdFusion folks) are not the favorite child, and only favorite children deserve attention.

You too, Adobe. You too.

The Last Straw: Alligator Pricing Tactics

It would seem that Adobe is pursuing a place in the dictionary, right under "Bait and Switch". Check this out:

We were sent a questionnaire earlier this year under the guise of getting a "better deal" for our existing 3 perpetual Enterprise licenses. As a result of what was clearly a bait and switch tactic, Adobe is now claiming we are in violation of the EULA and requiring us to sign a custom agreement that is increasing our costs nearly 10-fold. If we don’t sign it, they are threatening to sue us for years of back-license fees. Our solution does not provide coding access or delivery of ColdFusion itself. And it is not ColdFusion server dependent. (It runs in open source environment like Lucee). They say that ANY company using CF in any B2B capacity is a service bureau and subject to a custom agreement with annual auditing/repricing, using some arbitrary and unknown formula for determining the cost. Clearly they are trying to convert their perpetual licensed customers to a special license where they’ll ultimately demand a portion of their revenues. They are also bypassing their resellers by doing this. If you have dealt with this I’d like to find out what your resolution was. If you have not – just wait – they are coming for you.

You can read the full thread on the Adobe Forum, but this is not the first complaint. Adobe has always charged ridiculously high licensing fees because they can.

What's more, Adobe won't lower their prices. Ever. When the last CF customer is gone, they will simply fire their ACF employees (you know, all three of them) and focus their awful tactics on wrecking another customer-loved product, like Photoshop. Why? Because there is not a single person in Adobe management who loves ColdFusion. Not a single one who cares. Remember, Adobe did not create ColdFusion - they purchased it.

Ultimately, this is the reason for ACF's demise and my denouncement in this very blog post. No matter what Adobe did to ColdFusion, if they actually attempted to improve the product, or listen to developers, or design a sane pricing model, or show that they care in any way at all I would still be a fan.

But here I am, because Adobe couldn't care less what their own product is or does. Adobe ColdFusion is dying because Adobe. Period.

My Response

I'm not just here to rain on the parade! (Sorry for the negativity, though.) I have an Answer - a Cause - and I'm not abandoning CFML. I'm just preferring the open-source, light-weight, so-much-better, listens-to-devs implementation called Lucee.

Here's what that means:

I will assume that if there is an official stance of Adobe on any topic, it is directly contrary to the wishes and needs of the ColdFusion community.
I refuse to support any version of Adobe in my open source products.
I refuse to document ACF "gotchas" when blogging or tweeting about CFML features.
I will avoid the term "ColdFusion" in favor of prefer "CFML" going forward.
I will take great pleasure in promoting Lucee as a lighter, more secure, and more performant ACF alternative.

PS. The above list only applies to my freelance/open-source work!

Conclusion

I'm not just annoyed. I'm done. I'm not gonna throw hate at Adobe or any Adobe employee - that's both a waste of time and just not nice, but what I will do is prefer Lucee over all things ACF.

Getting Started In CFML: A Resource List for Newbies

Michael Born — Wed, 11 Sep 2019 12:57:18 +0000

If you are going to learn CFML in 2019, you need the best resources available. In this post I'll share tutorials, video channels, and even podcasts you can use to help you begin learning CFML.

I will do my best to keep this list up to date - feel free to comment or message me with links or updates.

Tutorials

These tutorials are (currently) the best way to get started with CFML. You can learn all about the syntax, see plenty of examples, and be off and running quickly.

Learn Modern CFML In 100 Minutes

This is a fantastic resource for new CFML devs, and covers the gamut from CF's underlying architecture (Java, compilation vs. interpretation, etc.) to the basic syntax , data structures, and concepts of the language.

https://modern-cfml.ortusbooks.com

LearnCFInAWeek

I did my share of reading on this website when I was first learning CFML, and I still use it for some topics now and then. While these tutorials are a little aged, they are helpful in that they focus on specific topics such as XSS protection, Caching and OOP.

http://www.learncfinaweek.com

Language References

When you're learning a language, it is vital that you be able to learn about the exact function you're using - is it arrayFind() or arraySearch()? These reference sites help you know which functions do what and exactly what the syntax is, and even provide some examples.

CFDocs.org

This is hands down the best reference website out there for CFML syntax and functionality. Every tag or function is documented with notes on engine support, deprecation notices and even some examples. These docs are entirely open-source and community supported, so if something is missing you can send in a pull request or shoot me an email and I'll update it myself.

https://cfdocs.org

Lucee Reference Docs

The Lucee docs focus on syntax for Lucee's CFML implementation and tends to be more accurate and up-to-date than CFDocs. (After all, it is maintained by the Lucee Foundation as well as open source contributions.)

https://docs.lucee.org/reference/functions.html

Communities

The CF community is awesome and always willing to help a newbie out. Check out these resources to get started learning from the community.

CFML Slack

This Slack group is the epicenter of the nicest, handiest, most helpful programming community I know of. When I can no longer bang my head against the wall, I come to this Slack chat to get help from devs whom constantly answer questions from noobs like me!

To sign up: http://cfml-slack.herokuapp.com
To log in: https://cfml.slack.com

Lucee Forum

The Lucee Forum is a great place for Lucee-specific discussions, whether that be concerning the language, the roadmap, documentation or other general issues. I've been browsing this forum a lot lately and joined fairly recently because I like to stay up on the Lucee news.

https://dev.lucee.org

Podcasts

Sometimes you don't know what you don't know. Listening to a good podcast will bring you in contact with other ideas, tools and programming techniques that you didn't know you didn't know.

Modernize Or Die Podcast

Ortus is tackling the CFML podcast space with their Modernize Or Die podcasts, and they're doing an awesome job of it. For news and tips, check out the CFML News edition. The VS Code tips are especially useful for beginners. The Soapbox edition is great for wider discussion-type stuff, and may help you keep your overall goals and focus tuned for success.

https://cfmlnews.modernizeordie.io

https://soapbox.modernizeordie.io

Video Channels

Sometimes it's just easier to learn from video. These tutorials should help you get started with CFML in 2019.

Getting Started with Adobe ColdFusion (2016 Release)

This is a great selection of video tutorials showing how to program in CFML. This tutorial focuses on programmers with very little experience, so you may find the pace a little slow in the earlier videos. Still, it is fairly comprehensive and does a good job of explaining concepts and tag syntax.

https://www.youtube.com/watch?v=9viMI8f4myM&list=PL3iywAijqFoUD31CQBLsHvJn4WAonNA7r&index=1

Adobe Coldfusion 11 Tutorials

This playlist tutorial may be useful to you, but based on its age (created in 2014), its focus on tag syntax, and its left-ear-only audio, you'll probably have more luck elsewhere.

https://www.youtube.com/watch?v=xelAelbSJqs&list=PLPZ2BdpyPMq7zRHFbNwwt4l5oOj54GYan&index=3

My Twitch Channel

Yep, this is a shameless plug for my live streaming channel. I live code every Friday evening, and I may work on anything from writing a CFML URL shortener to building a ContentBox blog. This would be a great place to see how I write CFML and ask me why I do X instead of Y.

https://www.twitch.tv/michaelborn_me

Conclusion

CFML is a very easy language to learn in terms of syntax, but there are differences in how the language is structured and configured that take time to sink in. Hopefully this big list helps you get started

Localizing Dates In Sql Server

Michael Born — Tue, 20 Aug 2019 03:13:11 +0000

Several months ago I added timezone handling to a CF app. This post is my best effort to document how to localize dates using MSSQL timezone functionality.

Retrieving Timezones from MSSQL

First, we need to know what time zones we can use. MSSQL uses the Windows timezones as stored in the registry, and they can be retrieved from the sys.time_zone_info system view.

SELECT * FROM sys.time_zone_info

Do not try to interact with these time zones using a CFML timezone - the underlying Java timezones use a different timezone format and do not match the MSSQL/Windows timezone format.

Also, you may notice that the timezone list does not include different timezones for daylight saving time. For example, there is a single timezone record for Eastern Standard Time, or EST. Eastern Daylight Time is nowhere to be found, because this view automatically updates the current_utc_offset and is_currently_dst values based on the current time in that timezone.

Retrieve Current UTC Offset From a Known Timezone

Next we use these time zones to get the current utc offset. Note I said current - do not store the UTC offset, because it will change for a given time zone twice a year at minimum. (e.g. daylight saving time.)

For this reason, we'll need to store the user's time zone and retrieve the UTC offset when you need the user's local time.

Here's a simple way to retrieve the current UTC offset for a known time zone:

SELECT current_utc_offset
FROM sys.time_zone_info
WHERE name='US Eastern Standard Time'

Obviously, in order to know which time zone to use you will need to allow the user to select their time zone so you can store that timezone with the user.

Localize Dates To a Timezone Using AT TIME ZONE

Use AT TIME ZONE if you need to indicate the UTC offset of a datetime value:

GETDATE() AT TIME ZONE 'US Eastern Standard Time'

Basically, this lets us select a date which was stored with no UTC offset and add a UTC offset to it - provided we know the original time zone. This paves the way for us to then convert the date from its original timezone - using AT TIME ZONE - to another timezone - using the SWITCHOFFSET function.

SWITCHOFFSET

Once we have a DATETIMEOFFSET value, we can use SWITCHOFFSET(DATETIMEOFFSET, time_zone) to switch that datetime to match a user's local time:

SWITCHOFFSET(
    GETDATE() AT TIME ZONE 'US Eastern Standard Time',
    (
        SELECT current_utc_offset
        FROM sys.time_zone_info
        WHERE name='Central European Standard Time'
    )
)

Conclusion

Unfortunately, this is not a full timezone localization writeup. Localization is very complex, and the more I learn the less I know. But hopefully this brief overview of timezone handling using built-in MSSQL functionality will come in useful for someone - enjoy!

Form Processing in CFScript Part Three: Sending Email Notifications

Michael Born — Wed, 14 Aug 2019 12:48:27 +0000

In this series so far, we've looked at how to validate a form entry and how to save that form entry to the database. Today we'll see how we can notify a person (usually a site admin or editor) that a new form entry has been submitted and processed by simply sending an email.

Email works well for form notifications because the entire entry will usually fit in a single email, and replying to an email can send a message to the original user who filled out the form. Contrast that with SMS messages, which are limited in content length and do not support rich formatting or reply-to functionality.

Sending Emails via Configured SMTP Server

If your web server also has an SMTP server installed (Postfix, anyone?) and configured in your ColdFusion or Lucee administrator, sending the email is as easy as specifying the to address, from address, and subject.

cfmail(
    to="admin@mysite.com",
    from="noreply@mysite.com",
    subject="New form submission from #form.name#"
){
    // email contents go here
}

Sending Emails via Mailgun SMTP

If you don't have an SMTP server installed or configured, you can use the server, port, username and password arguments to send via the Mailgun SMTP server, for example.

cfmail(
    to="admin@mysite.com",
    from="noreply@mysite.com",
    subject="New form submission from #form.name#",
    server=server.system.environment.SMTP_HOST,
    port=server.system.environment.SMTP_PORT,
    username=server.system.environment.SMTP_USERNAME,
    password=server.system.environment.SMTP_PASSWORD
){
    // email contents go here
}

Here I'm using environment variables stored in Lucee's server.system.environment struct to send via Mailgun's SMTP server. These environment variables could be set in the /env/environment file or your bash profile to look something like this:

SMTP_HOST=smtp.mailgun.org
SMTP_PORT=587
SMTP_USERNAME=postmaster@mail.mysite.com
SMTP_PASSWORD=123A923BCB6BGA7B*3

The exact functionality depends on your system, but generally these variables will be loaded into your environment on system startup or on profile startup.

Setting the Email Reply To

Setting the replyto email address will let us reply to the user who filled out the form:

cfmail(
    to="admin@mysite.com",
    replyto="#form.email#"
    from="noreply@mysite.com",
    subject="New form submission from #form.name#"
){
    // email contents go here
}

This is awesome because it allows admins to quickly respond to the original user. You simply can't do this when delivering via other mediums like SMS or Slack.

CFMail Body Output

Here's where we output (or render) the form submission in the body of the email. This is pretty simple - we use the writeOutput() function to output HTML and the form values right in the email body:

cfmail(
    to="admin@mysite.com",
    replyto="#form.email#"
    from="noreply@mysite.com",
    subject="New form submission from #form.name#"
){
    writeOutput("New form submission by #form.name#");
    writeOutput("#form.message#");
}

Note that the MIME type of the email will be text/plain by default. For rendering HTML in our email we'll need to set the mime type via type="text/html" or even just type="html":

cfmail(
    to="admin@mysite.com",
    replyto="#form.email#"
    from="noreply@mysite.com",
    subject="New form submission from #form.name#",
    type="html"
){
    writeOutput("New form submission by #form.name#");
    writeOutput("#form.message#");
}

Avoiding XSS in Emails

Please don't output user-submitted data (form variables) without encoding them! The last thing you want to do is send a spammer's script tag (think <script src="http://badwebsite.com/js/payload.js"></script> tag) to your client's email address. That's what you call Cross-Site-Scripting, and in CFML it's easy to avoid - just wrap every #form.field# with encodeForHTML():

cfmail(
    to="admin@mysite.com",
    replyto="#form.email#"
    from="noreply@mysite.com",
    subject="New form submission from #form.name#"
){
    writeOutput("New form submission by #encodeForHTML( form.name )#");
    writeOutput("#encodeForHTML( form.message )#");
}

There are a bunch of encodeFor*() functions designed for certain contexts, such as encodeForURL() and encodeForHTMLAttribute(). I can't demo all those, but I can write a more detailed XSS blog post if you'd like me to!

Note that our email templates are looking larger and more complex. Real-world code can be large, complex and messy, so let's clean it up by not using CFScript.

The Best Dang Template Syntax

Outputting HTML from a scripting language is - lets be honest - awkward. It's awkward in Javascript (though much improved lately with template literals), it's awkward in PHP and it's certainly awkward in CFScript. Template engines like Twig, Jade, and Mustache solve this for other languages, but in ColdFusion we have the best dang template syntax in the world.

So why not use it?

CFML lets us switch between script syntax and tag syntax as necessary - no libraries, no extra compiling and no need to learn a funky template syntax.

I recommend creating a views/emails/ directory for email templates. Then each new email can be a separate file named after the contact form, like views/emails/donate-thankyou.cfm or views/forms/forgotpassword.cfm.

Here's a quick example:

cfmail(
    to="admin@mysite.com",
    from="noreply@mysite.com",
    subject="New form submission from #form.name#"
){
    include "/views/forms/contact/email.cfm";
}

With this setup, our email-sending code looks much cleaner and the email template looks much better as well.

We can even create a standardized email header and footer in _head.cfm and _foot.cfm and include those from the main email template:

<cfinclude template="./_head.cfm" />
<!---

        EMAIL BODY GOES HERE

--->
<cfinclude template="./_foot_.cfm" />

Formatting Form Entries In An Email

For a quick get-er-done notification email, you can loop over form.fieldnames to dynamically output each form field:

<p>
<cfloop list="#form.fieldnames#" index="field">
    <strong>#encodeForHTML( field )#:</strong>
    #encodeForHTML( form[ field ] )#<br>
</cfloop>
</p>

If you want high quality email templates, you might want something more like this:

<h1>New form submission by #encodeForHTML( form.email )#</h1>
<p>Message: #encodeForHTML( form.message )#</p>
<p>
    Name: #encodeForHTML( form.name )#<br>
    Email: #encodeForHTML( form.email )#
</p>

Email Attachments

Let's say we have a job application form with a place to upload a resume file:

<form enctype="multipart/form-data" action="processApplication.cfm">
    <label for="resumeFile">Please add your resume in PDF format</label>
    <input type="file" id="resumeFile" name="resume">
    <!--- more form here --->
</form>

Files sent via a POST request are stored in the server's temp directory. To attach the file to the email, we first need to save the file to a semi-permanent location so it doesn't get cleaned up (i.e. deleted) before the spooled email is sent out. The fileUpload() function works well for this:

var uploadedFile = fileUpload( "/files/resume/", "resume", "application/pdf", "makeunique" );

Once we have the file saved we can attach the file to our email by using cfmailparam():

cfmail(
    to="admin@mysite.com",
    from="noreply@mysite.com",
    subject="New form submission from #form.name#"
){
    // Email body here
    cfmailparam( file="#uploadedFile.serverfile#" );
}

Conclusion

Emails are fantastic for form notifications. CFML is fantastic for emails. This guide ended up much longer than I expected - hopefully you enjoyed it and can use it as a handy reference for your first CF app!

Form Processing in CFScript Part Two: Saving Form Entries to the Database

Michael Born — Thu, 01 Aug 2019 13:02:30 +0000

If a tree falls in a woods with no one to hear, did it actually fall? Likewise, if a user submits a form but it is not persisted in some form, that form submission is worthless.

Saving Form Submissions to the Database
- Method One: Storing the Form With a Hard-Coded Table Design
- Method Two: Storing a Form as a JSON Packet
Conclusion

Today we'll go over a very important, perhaps the most important step in form processing: saving the submitted form to a database.

Saving Form Submissions to the Database

When processing form submissions, the first and most important step is to persist the data - to make sure that form data is saved and available for future reference. This post will show you how to store form data in a SQL database using two main approaches. Neither approach is difficult, but I found each useful in their own way and worthy of different use cases.

Method One: Storing the Form With a Hard-Coded Table Design

Here's the simple method - simply save each form submission to a new row with a separate column for each form field.

After you build the HTML form, create a database table with an appropriate column for each form field:

CREATE TABLE contactForm(
  id VARCHAR(35) NOT NULL UNIQUE PRIMARY KEY,
  name VARCHAR(255),
  email VARCHAR(255),
  message TEXT,
  dateSubmitted TIMESTAMP
);

Then in your form handler, it's as easy as using queryExecute() to insert the row.

var sql = "
    INSERT INTO contactForm(id, name, email, message, dateSubmitted)
    VALUES(:id, :name, :email, :message, :dateSubmitted)
";
var params = {
    id: createUUID(),
    name: form["name"],
    email: form["email"],
    message: form["message"],
    date: { value: now(), cfsqltype: "timestamp" }
};
queryExecute( sql, params );

I'm personally a fan of declaring sql and params variables like this, but if you're an inline-only kind of guy you could write it like this:

queryExecute( "
    INSERT INTO contactForm(id, name, email, message, dateSubmitted)
    VALUES(:id, :name, :email, :message, :dateSubmitted)
", {
    id: createUUID(),
    name: form["name"],
    email: form["email"],
    message: form["message"],
    date: { value: now(), cfsqltype: "timestamp" }
});

The cool thing about this approach is that Fixinator will now catch your SQLi vulnerabilities

This approach is simple and works well enough. The benefit to building a table schema to match the form is that storing and retrieving the data is simple and powerful thanks to good database integration. Basically, having our table design match the form design gives us powerful search, sort and query capabilities with no extra work.

Method Two: Storing a Form as a JSON Packet

For larger forms, creating that table schema can be a pain. If that large form changes frequently, we're talking a real pain. I can't tell you how many table schemas I've created to match a contact or donation form, just to alter those tables when the form inevitably changes.

So for larger, more complex forms, I recommend storing the form submission as a JSON string. It's still useful to have the main fields (name and email) in dedicated table columns for sorting and searching, but JSON will be more than adequate for most other fields. Saving as JSON means that we don't need to create a custom field for every form input, and we can store form submissions generically - less setup and less maintenance.

The storage table is much simpler to create:

CREATE TABLE formSubmissions(
  id VARCHAR(35) NOT NULL UNIQUE PRIMARY KEY,
  form TEXT,
  dateSubmitted TIMESTAMP
);

And inserting the form data as JSON is as simple as using serializeJSON(form). When reading the form submission out of the table, we can use deserializeJSON() to decode the JSON string back to a CF struct. On Lucee, you may need to enable "Preserve key case" in the Lucee admin. Note that Adobe ColdFusion 11 and up maintains key casing by default.

var sql = "
    INSERT INTO formSubmissions(id, form, dateSubmitted)
    VALUES(:id, :form, :dateSubmitted)
";
var params = {
    id: createUUID(),
    form: serializeJSON(form),
    date: { value: now(), cfsqltype: "timestamp" }
};
queryExecute( sql, params );

One significant downside of this approach is that sorting and searching natively in the database becomes harder - perhaps significantly harder, depending on your database software. If you're using MySQL 5.7.8 or newer, though, the JSON data type makes sorting or filtering fairly easy:

SELECT id
    , JSON_EXTRACT(data, '$.name') AS name
    , JSON_EXTRACT(data, '$.email') AS email 
FROM formSubmissions
ORDER BY name ASC

I must note that this method is not perfect. Storing data as a big old JSON string does not exactly conform to first normal form, and attempting to sort or search by an extracted JSON field will likely come with a non-negligable performance hit. Regardless, I find this method handy due to the minimal maintenance. It's generally easier to edit an HTML form than the SQL table structure, and this approach means that a change in the first does not require a change in the second.

For more info, check out How to Use JSON Data Fields in MySQL Databases.

Conclusion

Persistence is not hard. This blog post was meant to highlight an easier approach to storing form entries; if you put a little thought into your form processing you can save a lot of maintenance time through the life of the form.

Form Processing in CFScript Part One: Form Validation

Michael Born — Tue, 23 Jul 2019 13:21:38 +0000

This series will teach you how to process form submissions using ColdFusion's CFScript syntax. In Part One I'll show you the basics of validating form submissions on the backend!

Note: This article (and entire series) assumes you are not using a frontend framework like Vue or ReactJS to generate and validate the form. If you are, great, but do not rely on client-side validation as it is too easily bypassed. See section on backend vs. frontend validation.

Intro to Form Validation
Form Validation: Backend Vs. Frontend
Validating Field Length (Required Fields)
Validating Field Type
- Static Type Checking
- Iterative Type Checking
Dealing with Validation Errors
Conclusion

Intro to Form Validation

When validating form submissions, there are two main things to keep in mind which should guide your overall validation strategy.

First, the main point of form validation is 1) to helpfully notify the user when they mistype a value, and 2) to prevent backend errors. (e.g. cfmail() will throw an error for some badly misformed email addresses). Besides that, validation should be used as sparingly as possible. This is because it's easy to be too strict and unintentionally exclude users with different zip codes, email addresses and phone numbers than we might expect.

Secondly, you can never force a user to input their personal information if they do not wish to! Requiring an address field, for example, will generate a significant amount of falsified info, like "1600 Pennsylvania Ave NW".

With that out of the way, let's take a look at a basic HTML form we're going to validate. Nothing fancy here, just a small contact form. Donation forms are much larger and require much stricter validation (and if you are processing payments through your server, I pray for you!)

<form action="contact.cfm">
    <div class="field">
        <label for="name">Your Name</label>
        <input type="text" name="name" id="name" value="" />
    </div>
    <div class="field">
        <label for="email">Your Email</label>
        <input type="text" name="email" id="email" value="" />
    </div>
    <div class="field">
        <label for="message">Message</label>
        <textarea name="message" id="message"></textarea>
    </div>
    <div class="submit">
        <input type="submit" class="button button-primary" value="Send">
    </div>
</form>

Later on, we'll tweak this form to support the particular "flow" I prefer for backend validation.

Form Validation: Backend Vs. Frontend

Form validation at the frontend level is far superior than equivalent validation at the backend level. Think of the User Experience - with frontend validation, you can get immediate feedback and avoid sending bad data in the first place. Backend validation is only necessary when the frontend is broken, disabled (Noscript mode) or purposely skirted around via some bot or hacker submitting HTTP requests to your backend.

For this reason, you could probably dispense with the pleasantries and ignore the need for decent UX when validating via the backend. I say "probably" - I still like to provide a nice UX for those legitimate users browsing with javascript disabled.

Validating Field Length (Required Fields)

Validating a form field is not exactly nuclear science. For many fields(not all, but many), it is enough to ensure that the field value is not empty. When validating required fields, I use a variable to store a simple list of field names deemed "required", and if any of those fields are indeed empty we halt the processing and display an error to the user.

Note: I use member functions throughout this blog post. Member functions can be great as long as they are relatively short and importantly, achieve only a single purpose. Larger blocks of code, in my opinion, probably belong in a for loop - not a member function.

Here's what I'd use to validate required fields using some clever* member functions.

*Cleverness is useful but dangerous; please use carefully. (And see note on member functions above.)

var requiredFields = "email,phone,message";
var invalidFields = "";
form.fieldnames.each((fieldname) => {
    if ( requiredFields.find(fieldname) && isEmpty(form[fieldname]) ) {
        writeOutput('<p class="alert alert-danger">Please fill out #fieldname#</p>');
        invalidFields.listAppend(fieldname);
    }
});
if ( invalidFields.len() ) {
    // halt processing and re-render the form.
    cfabort();
}

Fairly straightforward CFML here - iterate through all form fields, see if it is required, and if it is not provided spit out an error and halt processing. This is rather simplistic, but perfectly workable - skip down to "Dealing with Validation Errors" for an improved way to handle error messages.

Validating Field Type

Validating the type of data is much more difficult than validating the presence of data.

Static Type Checking

The simple way to do this is to use isValid() to check email, phone, zip or other standard inputs.

if ( !isValid("email", form["email"]) ) {
    writeOutput('<p class="alert alert-danger">Please enter a valid email</p>');
}
if ( !isValid("telephone", form["phone"]) ) {
    writeOutput('<p class="alert alert-danger">Please enter a valid phone number</p>');
}

I say the simple way for a reason: I personally do not recommend this option. Why? Because IsValid is not accurate for email validation, and the only way to guarantee that an email address is truly valid is to send the user an email. This is common practice in signup forms, for example.

I would avoid stringent validation for any localization-specific formats such as postal codes or phone numbers - there are simply too many variants. For any validation regex, there will almost certainly be issues with certain "valid" formats. That is my opinion - you are free to use or reject it!

For simpler values like numerics, floats or strings, isValid() is fine. For example, we could validate a donation form's "amount" field to make sure it is a dollar value.

if ( !isValid("float", form["amount"]) ) {
    writeOutput('<p class="alert alert-danger">Please enter a valid donation amount</p>');
}

Iterative Type Checking

Now, instead of hard-coded field type checking, we could loop over an array of field names with type info:

var formFields = [{
    name: "amount",
    type: "float"
},{
    name: "name",
    type: "string"
}];
formFields.each((field) => {
    if ( form[field.name] != "" && !isValid(field.type, form[field.name]) ) {
        writeOutput('<p class="alert alert-error">#field.name# must be a valid #field.type#</p>');
    }
});

I prefer this approach if I'm going to generate the form dynamically via CFML, because I'll probably already have metadata about each field. For most smaller/non-generated HTML forms, who really cares if my code is a little repetitive?

Dealing with Validation Errors

Most of the examples shown above display a Bootstrap alert immediately and abort or exit the form processing to show the message to the user. That is more than adequate as long as we trust our frontend validation. Validating on the frontend will filter out most real users from submitting invalid data in the first place.

However, we can improve on this model if we have the ability to generate the HTML form. Halting the request, displaying an error, and asking the user to click the back button is inconvenient and may clear the form, causing the user to lose all progress made. For a better flow, I usually stuff an errors array with error messages, then render the form with errors at the top (if the submission is invalid):

var requiredFields = "email,phone,message";
var errors = [];
form.fieldnames.each((fieldname) => {
    if ( requiredFields.find(fieldname) && isEmpty(form[fieldname]) ) {
        errors.append("#fieldname# is required.");
    }
});
if ( errors.len() ) {
    // don't process the form; display it instead.
    include "form.cfm";
}

Once we have that array of error messages, we can easily display a Bootstrap alert for each error at the top of form.cfm like so:

<cfif errors.len() >
    <cfloop list="#error#" index="error">
       <p class="alert alert-error">#error#</p>
    </cfloop>
</cfif>
<!--- render form --->

And finally, make sure to tweak the form by filling each input with the submitted form.field value. This allows the user to seamlessly pick up after an invalid submission, letting them easily fill out a required field or correct an email typo.

<form action="contact.cfm">
    <div class="field">
        <label for="name">Your Name</label>
        <input type="text" name="name" id="name" value="#encodeForHTMLAttribute(form.name)#" />
    </div>
    <div class="field">
        <label for="email">Your Email</label>
        <input type="text" name="email" id="email" value="#encodeForHTMLAttribute(form.email)#" />
    </div>
    <div class="field">
        <label for="message">Message</label>
        <textarea name="message" id="message">#encodeForHTMLAttribute(form.message)#</textarea>
    </div>
    <div class="submit">
        <input type="submit" class="button button-primary" value="Send">
    </div>
</form>

PS. Make sure to encode all user-submitted data to prevent Cross-Site Scripting (XSS)!

Conclusion

Form validation is not hard, just tedious. Hopefully this helps you understand the basics of validation. When in doubt, be more permissive than you need to be, but never trust user input!

That wraps up Part One of Form Processing in CFScript. If you liked this or hated this, please comment below. :)

DEV Community: Michael Born

How to Get the Version of Any Java Package from CFML

Reading a Java Package Version in Lucee

UPDATE: Using Lucee's BundleInfo() method

Reading a Java Package Version from Adobe ColdFusion

A Cross-Engine Solution

The POI Version Class

Redirecting Hibernate Logs to the CommandBox Console

Resolving Concurrent Exceptions in Hibernate Logger

Cross-engine transaction detection in Hibernate v3+

UPDATE: Now with Adobe support!

Five Things I'd Like To Learn in 2020

One: How to Debug Slow Execution Times In FusionReactor

Two: The Basics of ContentBox

Three: How to Configure WireBox for Vanilla CF Apps

Four: CB Streams

Five: Ant and Maven Build Tools

Conclusion

Three ColdBox Features I Learned While Building A URL Shortener

Resourceful Routes

ColdBox Route Visualizer Module

HTTP Method Spoofing

Conclusion

Adobe, You Piece of Work, I'm Through

Terrible Language Support

fixing tickets without documenting new behavior

silently fixing tickets with no further description or notice

refusing to release hotfixes for obvious, blatant regressions

refusing to backport bugs to "supported" versions of ColdFusion

Poor Marketing and Customer Outreach

The Last Straw: Alligator Pricing Tactics

My Response

Conclusion

Getting Started In CFML: A Resource List for Newbies

Tutorials

Learn Modern CFML In 100 Minutes

LearnCFInAWeek

Language References

CFDocs.org

Lucee Reference Docs

Communities

CFML Slack

Lucee Forum

Podcasts

Modernize Or Die Podcast

Video Channels

Getting Started with Adobe ColdFusion (2016 Release)

Adobe Coldfusion 11 Tutorials

My Twitch Channel

Conclusion

Localizing Dates In Sql Server

Retrieving Timezones from MSSQL

Retrieve Current UTC Offset From a Known Timezone

Localize Dates To a Timezone Using AT TIME ZONE

SWITCHOFFSET

Conclusion

Form Processing in CFScript Part Three: Sending Email Notifications

Sending Emails via Configured SMTP Server

Sending Emails via Mailgun SMTP

Setting the Email Reply To

CFMail Body Output

Avoiding XSS in Emails

The Best Dang Template Syntax

Formatting Form Entries In An Email

Email Attachments

Conclusion

Form Processing in CFScript Part Two: Saving Form Entries to the Database

Saving Form Submissions to the Database

Method One: Storing the Form With a Hard-Coded Table Design

Method Two: Storing a Form as a JSON Packet

Conclusion

Form Processing in CFScript Part One: Form Validation

Table of Contents

Intro to Form Validation

Form Validation: Backend Vs. Frontend

Validating Field Length (Required Fields)

Validating Field Type

Static Type Checking

Iterative Type Checking

Dealing with Validation Errors