Archive for category Programming
ColdFusion Preserve POST variable name case
Posted by Eric in ColdFusion, Programming on April 1st, 2008
ColdFusion provides access to POSTed data via the FORM structure. Unfortunately ColdFusion always upper-cases the names of these variables. Recently a chunk of code I was working on needed to know the original case of these keys. At first I worked on passing a hidden form field with the original field name text, but this bothered me as way too much of a work-around.
This chunk of code will give you a structure called FormContent where the case of the field names is preserved.
Unfortunately this code will not distinguish between two fields with the same name but different case. To do that, you’ll want to use a case-sensitive StructNew() alternative. I recommend CreateObject(”java”, “java.util.LinkedHashMap”).init(). This has the added value of preserving the order that the fields appeared in the calling form when you iterate over it for output. It has the disadvantage that you’ll have to properly match case of the keys when you retrieve them in your code.
ColdFusion REMatchAll
Posted by Eric in ColdFusion, Programming on April 1st, 2008
This ColdFusion method offers functionality similar to PHP’s preg_match_all function. It searches for the supplied regular expression in the supplied text. The return value is an array with one entry for each time the pattern matches the string. The array entries are structs with a numbered element for each parenthesized sub-expression within the match, and a zero-entry for the whole match.
It’s probably easier to see example data.
As you can see, it returns every match, position, and full text of the match, as well as each parenthesized subexpression. The example pattern basically matches {foo|bar|baz}, {foo|bar}, or {foo}, and returns the alphabetical sub-components as the sub-expressions.
Here is the code.
Spry Email Validation
Posted by Brian in Programming on March 31st, 2008
First you have to include the js and css files for the spry framework. In this example taken from the spry demos we have two files. Both are designed for text fields.
The actual form field will be wrapped in a div or span tag with an id. Any messaging then gets its own span class within the div.
Below the form on the page, the following scripting is added. This will validate that there is a correct email typed into the text field. Validating on change checks the field on each character entered. For emails it would be better to validate on blur. The user will not get constant reminders as they type.
Notice that there's no Regex on the screen. I didn't need any, the Spry framework took care of it.
Regular Expression for Validating Email Addresses
Posted by Eric in Programming, Regular Expressions on March 27th, 2008
This is the regular expression I use to validate email addresses:
Thought it might be useful to some folks. Most email validation regular expressions fail to allow all the valid characters before the @ sign (for example, you can have a +, an & slashes, a single quote, =, ?, ^, _, {, }, ~, *).
In ColdFusion, you can test an address with:
In Javascript, you can test with:
In PHP, you can test with:
Real Time Command Execution Feedback
Posted by Eric in ColdFusion, Programming on March 27th, 2008
Did you ever write a utility ColdFusion script which uses <cfexecute> to run a command and send output back to the browser? It makes for convenient and monitorable remote execution of certain repetitive tasks. My most common use for this sort of thing is for example an rsync process which can be invoked from anywhere in the world, and most recently I’ve been working with Selenium-RC to set up regression test scenarios which can be initiated by business users and business analysts without having to have Selenium IDE installed or know how to use it.
I’ve always found it frustrating though when the task is long-running, and potentially error-prone to not know the success or failure, until the entire command has been executed, and even more frustrating not knowing if it has hung up for some reason today, or does it just have a lot more work to do today than normal?
This little snippet will use Java runtime to capture and pipe the output of the program back to the browser in real time. There’s a couple of caveats surrounding needing to not be used inside a forced-buffer area (like <cfsavecontent>), but otherwise this should work just fine. That means you can’t really use it inside most modern CF frameworks which depend heavily on <cfsavecontent> and the like.
Standard input (stdin) is shut down right at the start of execution; if you wanted to interact with the program in some way (such as to script some responses to prompts), you could undo that and write to it. Standard output (stdout) and standard error (stderr) are sent to the browser and flushed in nearly real time (stderr outputs in red to boot). I use a non-busy sleep via a Java thread to check in on the running program once a second for new output. Return value is a structure containing the elements exitValue, stdOut, and stdErr, so you can do further processing with it after the fact.
Anyway, enough blather, here is the code. This is not hyper-efficient (too many string concatenations and HTMLEditFormats), so I don’t recommend you use it in any high volume situations, especially if there’s a lot of output expected from your command, but it’s been sufficient for my needs.
Example usage:
Book Review: Mastering Regular Expressions, 2nd Ed
Posted by Eric in Regular Expressions, books on March 26th, 2008
Mastering Regular Expressions, 2nd Edition
Author: Jeffrey E. F. Friedl
Publisher: O’Reilly
ISBN: 0-596-0289-0
Pages: 432
This book is one of those books that absolutely every developer of almost any language should own a copy of. If you were to take every technical book away from me but one, this is the one I would choose to keep.
When I picked up this book a few years back in Borders, I figured I’d glance through it and see if it had any syntax tables. I felt pretty confident in my regular expression skills, figured I knew most of what there is to know, but sometimes stumbled on syntax. More importantly periodically I encountered a bizarre construct in someone else’s regular expression, and these things are incredibly difficult to Google. Have you ever searched for (?<!? It doesn’t work out so well.
What I found inside when I first opened it was a well-explained, easy to follow, and fairly in-depth discussion of various regular expression engine types, and the relative strengths and weaknesses of each. Digging further, I found that Friedl went into substantial depth on each engine type, giving examples of the sorts of regular expression which would trip it up, and explaining the performance of that regular expression in this engine compared to that engine. This was Chapter 2.
So in reality, are you going to need to know that sort of detail on a day-to-day basis while working with regular expressions? It’s not very likely. You’ll test your regular expression in the engine available to you and discover that it’s fast or that it’s slow, and tune it accordingly. Usually you don’t get the chance to choose which regexp engine you’re going to use. However it demonstrates the absolutely astounding level of knowledge and detail that Friedl gets into with this book.
This sort of background knowledge helps assimilate the concepts he communicates in later chapters, though he’s such an excellent communicator that you can easily understand what he says in later chapters, even if you don’t understand the background of why it is so.
This is the first technology book I ever sat and just read. I can’t profess to have retained all or maybe even most of what I read, the information is simply too dense, but it fundamentally changed my understanding of regular expressions.
Snippet
Lookahead (?=•••), (?!•••); Lookbehind, (?<=•••), (?<!•••)
Lookahead and lookbehind constructs (collectively, lookaround) are discussed with an extended example in the previous chapter’s “Adding Commas to a Number with Lookaround” (p 59). One important issue not discussed there relates to what kind of expression can appear within either of the lookbehind constructs. Most implementations have restrictions about the length of the text matchable within lookbehind (but not within lookahead, which is unrestricted).The most restrictive rule exists in Perl and Python, where the lookbehind can match only fixed-length strings. For example, (?<!\w) and (?<!this|that) are allowed, but (?<!books?) and (?<!^\w+:) are not, as they can match a variable amount of text. In some cases, such as with (?<!books?), you can accomplish the same thing by rewriting the expression, as with (?<!book)(?<!books), although that’s certainly not easy to read at first glance.
The next level of support allows alternatives of different lengths within the lookbehind, so (?<!books?) can be written as (?<!book|books). PCRE (and the pcre routines in PHP) allow this.
The next level allows for regular expressions that match a variable amount of text, but only if it’s of a finite length. This allows (?<!books?) directly, but still disallows (?<!^\w+:) since the \w+ is open-ended. Sun’s Java regex package supports this level.
When it comes down to it, these first three levels of support are really equivalent, since they can all be expressed, although perhaps somewhat clumsily, with the most restrictive fixed-length matching level of support. The intermediate levels are just “syntactic sugar” to allow you to express the same thing in a more pleasing way. The fourth level, however, allows the subexpression within lookbehind to match any amount of text, including the (?<!^\w+:) example. This level, supported by Microsoft’s .NET languages, is truly superior to the others, but does carry a potentially huge efficiency penalty if used unwisely. (When faced with lookbehind that can match any amount of text, the engine is forced to check the look-behind subexpression from the start of the string, which may mean a lot of wasted effort when requested from near the end of a long string.)
Recent Comments