Fussing with Forms (Part 3)

Often we want to use "rich" form fields that aren't provided for in HTML such as date pickers and WYSIWYG editors. We also often want to add client side validations to our forms. For a lot of common use cases, ColdFusion already has built in tags for implementing these. However, I have three problems with using the ColdFusion tags in my view markup.

Firstly, I'd really love to make my views scripting language independent so I could port my views between back end scripting languages automatically (yeah, I know, probably not too many people interested in that use case!). Secondly I'd like to be able to vary the implementation of my rich field controls. I may want to use the default ColdFusion implementation out of the gate, but I want to be able to change my implementation without having to edit all of my view screens - why should the interface (the tag or method call syntax) be tied to a specific implementation which may not meet my needs in the future? Finally, I'd like a consistent interface for describing all of my rich field controls irrespective of whether they're available in ColdFusion or whether they are something I want to add myself.

It seems to me that it might be nice to have a very simple wrapper around all of my fields allowing me to vary my implementations of each field type without having to change all of the calls to the interface (whether tag or method based). Similarly I'd like to be able to have a method for describing validations that I could then choose my preferred implementation for and where I could experiment with (for instance) different JavaScript libraries without having to make any changes to my view code.

I'm still not absolutely convinced that I'm going to get an ROI here, but I think I'm willing to spend a little time providing myself with my own templating language and generator to allow me to be able to vary the implementation of my views without having to change the templates.

There are some other potential benefits too. I could add simple tags for things like paging and even method calls, so I could replace my #Product.display("Title")# with just %Product.Title% so if I ever decided to go back to cfoutputting from queries, moved from generic to specific methods (from Product.display("Title") to Product.displayTitle()) or made other major architectural changes (which may be unlikely within a single project but much more likely across a software product line) I'd be set. I can also implement my own simple syntax for loops and hide variations into my controller API by abstracting that into the view generator and pulling it out of the templates. Yes, I have a feeling this extra step of indirection might fit quite well for my use case.