A Validation Framework for ColdFusion Objects
ValidateThis is a framework that allows you to define validation rules for your ColdFusion objects (or simple structs) 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.
- Download the ValidateThis current stable release, which includes the framework and all demo code.
- Check out the ValidateThis Quick-Start Guide (archived on web.archive.org)
- Refer to the following useful resources.
- Documentation (archived on web.archive.org)
- API Documentation (JavaDoc style)
Live Demo(archived; broken)- Bob Silverberg's ValidateThis blog posts
- Questions and Discussion
- ValidateThis.org Project Home Page
You are encouraged to contribute to ValidateThis, and there are a variety of ways to help:
- Discuss ideas and help answer questions on the ValidateThis discussion list
- Report bugs or feature requests to the issue tracker
Help improve the documentation(wiki is dead)- Help test new features and releases
- Contribute to the discussion on developing the framework on the ValidateThis development list
- Submit bug fixes or help code new features (see Code Contributions and Git Workflow, below)
The ValidateThis development list is a good place to ask questions or discuss large changes before coding. Please also review the following sections concerning Git configuration to deal with line endings and the Git workflow model used by this project.
As recommended by this GitHub Help page, we ask that all ValidateThis developers set their Git core.autocrlf setting accordingly.
Linux and Mac OS X:
git config --global core.autocrlf input
Windows:
git config --global core.autocrlf true
If you do not want to set core.autocrlf globally, you can set it as a repository option by changing to your ValidateThis clone directory and running one of the above commands without the --global option. For example:
cd ~/Projects/ValidateThis
git config core.autocrlf input
The git repo's develop branch is used as the primary development branch. The master branch will always be the current stable release. When finalizing a release, a release branch will be used (e.g., release-0.99). The Git workflow employed for ValidateThis development is nicely detailed in this blog series, by Bob Silverberg, A Git Workflow for Open Source Collaboration:
- Part I - Introduction
- Part II - Getting Started
- Part III - Developing Code
- Part IV - Submitting Contributions
Here's a very brief look at the git commands used for an example code contribution:
# Fork [ValidateThis](https://github.com/ValidateThis/ValidateThis) (if not already done).
# Clone your fork (if not already done):
git clone git@github.com:myGitHubAccount/ValidateThis.git
# Add main repo as "upstream" remote:
git remote add upstream git://github.com/ValidateThis/ValidateThis.git
# Create/checkout a local feature branch:
git checkout -b myFeatureBranch develop
# Hack, commit, squash (if needed), etc.
# Rebase on upstream "develop" branch before merging:
git pull --rebase upstream develop
# Merge your change and push to your fork:
git checkout develop
git merge --no-ff myFeatureBranch
git push origin develop
# Delete your feature branch:
git branch -d myFeatureBranch
# Send pull request.
ValidateThis is released under the Apache License, Version 2.