These three Coldfusion frameworks though – they are amazing, and make me want to program just so I can use them/learn to use them. Forgive the intro-amazement-wow-that’s-so-cool post, but Model-Glue: Unity is pretty slick stuff, just check out the 8 minute video . It’s a ways off in my radar for now, but it’ll be next on the list of new-things-to-learn after Reactor and Coldspring. To start though, it’s definitely Reactor . After watching the Breeze presentation about it , and implementing it in a fusebox 5 application with Coldspring, the fun began as did the code cleanup. Hard not to be impressed by something when it works right after the download, and integrates into your application simplifying things within an hour.
I’m still mapping out the different objects- – gateways, records, to (transfer objects), dao (data access objects) and meta-data- – so it’ll take a little while before I can harness the full power of Reactor. To start with today, I was looking for a way of handling validation such that it goes off whenever an object is saved to the database. Usually for something like this I’d just call some validation functions, then if there’s not an error save it — easy enough. But with reactor there are quite a few possibilities (surely more that I don’t know).
For example: say there is a product. You’ve set everything on it and you want to save it to the database. This executes some code that is created by Reactor that handles the entire save for you, so if you don’t need validation that’s your insert/update/sql/transaction(?) call in one. But in the case you want to do validation, I saw a few options. in your / datafolder /Record/ProductRecord.cfc file (i think that’s it; don’t have reactor here so my paths may be off), you can just define a few methods in that reactor created file. One way, and probably the most obvious way, would be to replace the save() method: [CFM] [/CFM] Easy enough? Not the best way by any means though. Sometime around here I saw there is also a validate() method which, I presume, validates the types of each field against the database required values- – is it an integer, is it NOT NULL, etc. It returns some kind of reactor.util.ErrorCollection object, which is probably what I’ll be reading up on tomorrow. It can be similarly extended, with a call to super.validate() to do the basic validation while your custom validate() method would check for anything it may miss. But still is there a better way to call this? Turns out in addition to save() there is a beforesave() and an aftersave() function, just because Doug Hughes is a nice guy. I take it beforesave() could be scripted along the lines of… [CFM] [/CFM] Still not using validate, but its there and it works. I think tomorrow I’ll see if something along the lines of this would work… [CFM] [/CFM] … That’s a little incomplete, but so is how much you can learn in a day. The idea at that point would be that the ErrorCollection has all the errors that are from the database, and also all errors that you want to output (added with ErrorCollection.addError()). Slick stuff; just have to figure out the next step — getting those errors back to the user somehow. Haven’t been looking forward to working with new stuff as much as this in quite a while!