I updated the git repository last night with a new sample application. This example is how to use Hyrule in a ColdMVC application. If you have never had a chance to check out the ColdMVC framework by my friend Tony Nelson I suggest you give it a look. From the sample application you will see how clean and separated the code is and how Grails like it feels.
I just wanted to throw out a quick question to anyone still actually reading this blog ;) I am working on updating my Hyrule Validation framework and I came across an interesting scenario. I never supported rules on collections so I am struggling with what I should do here.
Say we have a product class and a product has a collection of categories. The product could have one category or it could belong to many. I have a @Min constraint which I use for things like string lengths, numbers and dates. It just seems strange to place a min constraint on a collection. For collections I have a size constraint. It will allow you to pass the size min and max in the form of n..n where n is a valid number or -1 for no max. In the example we talked about earlier I could do something like this. It just seems weird to support collections with the @Min constraint, what are your thoughts?
I am not going to go on a rant here about how ColdFusion absolutely needs static variables. Instead I would like to present a use case from a recent experience and I would like to get your thoughts on it. I was working on a personal open source project called Hyrule. This project allows you to do validation on business objects (beans/ORM Entities/etc) by describing constraints in your objects.
Currently you can describe these constraints using annotations. I found out in a recent project though that this can get very messy. Having played around with Grails before I really enjoy being able to define my constraints like this. I thought why not create a similar way to describe constraints for Hyrule, so I set out on my mission
My first attempt went pretty well. I created a new Validator to handle constraints based settings and ended up with a model that looked like this. I was really happy with this and it seems like a much cleaner implementation than having a million annotations running around. Then a friend pointed out something that I totally overlooked. This method would not support inheritance. You can not access the this scope from a parent object. So if we had an employee object that defined its own constraints and extended User we would never be able to get the user constraints. This obviously brings up a huge issue and killed any dreams I had of implementing this.
So here is my use case for static variables in ColdFusion. In case your not quite sure what static variables lets review. A static variable can be accessed from a class without instantiating that class. So going back to our example say we have 2 components here, person and employee. Employee Person
Now when if create an instance of the employee object we can use meta data to find out if the component extends any other components (inheritance) and if it does we would have the full name of the component. From there it would simply be a matter of accessing the variable constraints. I am not sure how the implementation would be that would be the basic idea behind it. So that is my case let know your thoughts on static variables/methods in general. I would also be all ears in figuring out a different solution to my little problem here.
Last night I released v 0.71 of Hyrule I thought I would take a couple minutes to walk through a couple of the changes that were made.
So first off we have a bug with the display property. IF you have been paying attention you should of seen a bunch of examples that look kind of like this. When we get an error it will display an error message based on the default message template which looks like "notempty=The field {display} must contain a value.". In the case above it will replace {display} with the @display property. This is all great but what if you don't have a display property. Well what it should do is use the property name. It was not doing this so I fixed that part. Then my friend Tony said why not just humanize the property name. Great idea so thats what we are going to do now. The following will do the same as the example above.
The next problem I came across on my own. Take the following example. Now if you fill nothing in for all 3 properties your going to get back 3 errors. The first 2 because they are still empty and the 3rd because your empty string does not follow the rules of a phone number
This was obviously a problem. What if you just wanted to validate that if the user did enter a phone number that it was valid. It was because of this for validators like phone,ssn,credit card,etc... that we now check to make sure the property is not empty before we validate it. If you want to make sure the phone number has something in it and that its a phone number then you can do the following.
There were some other minor changes but that was the bulk of it. All of the unit tests were also updated to contain a testIsBlankReturnsTrue method. Let me know your thoughts on all of this and feel free to join the Google Group.
I thought I would take a few minutes and walk through my open source validation framework for ColdFusion. Below is a video that gives you a brief overview on the framework and I also walk though a couple examples. If you have any feedback on the framework, please let me know.