Welcome to ValidateThis
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
- Refer to the following useful resources.
- Documentation (near complete)
- API Documentation (JavaDoc style)
- Live Demo
- 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
- 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.
Dealing with Line Endings
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
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 email@example.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.