I’ve been playing with some form validation stuff for CF. I had been usign , but I wanted the HTML interface to act a bit more like the Flash interface, but I don’t really want to use Flash. I’ve also been doing a lot more work with some of the DHTML libraries that AJAX has made popular, so I figured there had to be a relatively elegent way to do form validations with something like Ajaxian about easy form validation and decided to give it a try. The article on Dexagogo shows how they created a library to handle form-validations that doesn’t require any other work than creating a form. This was just what I was looking for!

Basically, you just need the latest files from script.aclo.us with the latest prototype version (the 1.5 release candidate is included in the latest script.aculo.us lib folder), and the validation library. Convienently, they’re all included in the demo file on the site.

To use this, you really only need prototype and the validation library (script.aculo.us adds a nice effect – much like the Flash format in cfform). For me, I made these calls:

This is slightly different than the example on their page; they load the effects.js file directly, I’m calling the library via script.aculo.us with the load parameter. This isn’t really a big deal for one library, but it is convenient when you want to use several, but not all, of the libraries (e.g. scriptaculous.js?load=effects,dragdrop,slider).

Anyway, to actually use this, you need to create a form with an id attribute:

Now, we add some fields and use the class attribute to call the validator:

There are 11 options for use in the validation library (this is directly off their page):

• required (not blank)
• validate-number (a valid number)
• validate-digits (digits only)
• validate-alpha (letters only)
• validate-alphanum (only letters and numbers)
• validate-date (a valid date value)
• validate-email (a valid email address)
• validate-url (a valid URL)
• validate-date-au (a date formatted as; dd/mm/yyyy)
• validate-currency-dollar (a valid dollar value)
• validate-one-required (At least one textbox/radio element must be selected in a group)

This is really nice, because if you want to allow an optional field, but validate it, you can do:

There’s one more piece of the pie…to call the validation library. At the bottom of your page add:

The first argument is the id attribute of the form you’re wanting to validate. The second tells the Validator object what to do. This particular example enables validation on each field as you leave it (which I find useful). Some of the other options are:

• stopOnFirst (boolean): Stop on the first validation failure; default: false
• onSubmit (boolean): Override the default behavior of adding an even listener to the onsubmit event (set to false if you want to make sure your onsubmit method gets called no matter what); default: true
• immediate (boolean): validate when the cursor leaves the field; default: false
• focusOnError (boolean): place the focus on the first field with an error; default: true
• useTitles (boolean): make field validators use form element title attributes as error advice message; default: false
• onFormValidate (string function): call a function when the form is validated
• onElementValidate (string function): call a function when an element is validated

What I thought was really cool was the ability to add custom validation types via an API. Say you only want folks to use capital letters for their names, you simply add a new validation type like:

Want to add several? You can do that too:

This should be all of the normal items included in (plus a couple extra for good measure). Now the only thing left is to make it look pretty. One of the nice things about the Flash format in is that it color codes required fields with the different halo effects. To obtain a similar effect in the forms, we’ll use style sheets instead.

This is a rather light stylesheet, but it’ll give you something to start with (based on the default haloGreen skin):

I made a short example of some of the validations at http://swem.wm.edu/blogs/waynegraham/examples/validation/. I have to say that I’ve found this to be a bit better solution (at least for my needs) than using ! ]]> http://www.liquidfoot.com/2006/09/21/form-validation/feed/ 0 http://www.liquidfoot.com/2006/08/23/real-life-xslt-20-transformations/ http://www.liquidfoot.com/2006/08/23/real-life-xslt-20-transformations/#comments Wed, 23 Aug 2006 18:56:31 +0000 Wayne http://www.liquidfoot.com/?p=208

I ran into a bit of a situation that was really blowing my mind. I have a rather large XML file (around 20,000+ lines) marked up in TEI that I wanted to do some transformations on (a day book and ledger from the 1850s). Essentially the code follows the format

What I wanted to accomplish was group all this together in separate divs for HTML output (ok, I actually need to write each page to its own file, but this is pretty much just one more step).

I just could not find a way to group this info this way using XSLT 1 without wrapping each page within its own div structure. I didn’t really want to go back and do this, so I asked the TEI-L list. David Sewell pinged me back with some XQuery code that recursively recalls the document structure for a given node.

He also mentioned that it would be pretty easy to write an XSLT 2 transformation that groups these nodes together. I did a little bit of digging and came up with

This transformed the pages to what I was wanting

The XSLT processor for ColdFusion doesn’t support XSLT 2.0 (it’s still a draft spec). However, Saxon does (specifically Saxon 8). For more on doing XSLT transformations, see XSLT 2.0 in ColdFusion. ]]> http://www.liquidfoot.com/2006/08/23/real-life-xslt-20-transformations/feed/ 0 http://www.liquidfoot.com/2006/06/23/mg-unity/ http://www.liquidfoot.com/2006/06/23/mg-unity/#comments Fri, 23 Jun 2006 21:27:46 +0000 Wayne http://www.liquidfoot.com/?p=216

It’s been a while since I’ve written on this blog…I’m attempting to keep this one on CF. Anyway, MG Unity has come out and I have to admit that I’m REALLY glad it has.

I’ve been working on a project with five academics from four different institutions looking at the vernacular architecture of the Colonial Chesapeake to 1720 for an article in the William and Mary Quarterly for the 2007 celebration of Jamestown. The objective was to write an scholarly article that looks at everything that has been excavated and see if the arguments of past scholars still hold. Not only were the scholars looking at individual sites as an aggregate, but wanted to track changes to the structures over time (additions, fireplaces, cellars, etc.).

I knew this was going to be a challenging project from the beginning, so I attempted to set the expectations early for the application development cycle. I thought it a fluke that I actually got them all to aggree on a set of important fields and tables before I started coding anything (a first for me). However, as I got into the project a bit more, requests for additional fields here, moving this data to this table, all while attempting to support constant input into the application got to be a bit more than was really feasible for a “spare-time” project.

I had set out to use as good of coding practices as I could. Each table had its own DAO, gateway, TOs, validators, etc. However, each change to these fields made me keep mucking around in these files and the forms calling the objects. After a while of making constant changes, I fell back on some old “bad” practices and kind of strong-armed some of the solution with spaghetti code…and I hated myself for it because I knew that I would have to come back at a later date to fix it.

About this time Joe started doing some work with Arf! And Doug Hughes started work on Reactor. I continued to code in my bad style, but since I knew what I had done, I just kept doing it.

After the project members presented their paper, I set the project down for a while since my daughter had just been born. Since Joe brought out Unity, I decided now was as good a time as any to pick up the refactoring of the project.

All I can say is that what I’ve done in half-a-day with Unity would take me three- to four-times longer my old way. The scaffolds (once I figured out how they were working) have been an absolute godsend for the rather complex relationships between phases of construction and the overall archaeological and architectural record. The Reactor syntax is so easy (especially since ColdSpring seperates all the configuration) that everything just clicks.

The entire framework is just so intuitive (at least compared to my previous experiences with frameworks). The ability to not have to worry any more about building the basic web pages, forms, CRUD, and displays makes Unity a pleasure. Also, changes will be a breeze compared to what they entailed a couple of months ago, which will allow me to do some of the cool stuff I had planned with Google Maps and Google Earth to map out the locations of these archeaological/historical sites!