I know that CB has a helper function for validating emails somewhere
(IsEmail). How would I go about calling it from within my model as a
best practice?
Judah
I'll let other more experienced speak about best practices. The simple
way I currently use is to inject the plugin into my model using the
"cfproperty" option. I can then reference something like
"instance.cbutilities.isEmail()" in my model.
You can inject a bunch of stuff using the cfproperty option.
http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbModelGuide#DependenciesDSL
- Gabriel
I'm using dependency injection of my models into my services and then
my services into my handlers and that works brilliantly. I'd
considered this method and it sounds good to me but I was curious what
people felt about the separation of the model from the framework. With
DI we at least keep it clean, there is one point that the utility is
injected, but it does then make the model dependent on the framework.
If I moved my model to a different framework I'd need to change the DI
for that object. Not the biggest concern in the world but I like to
think these things through and see if others have better suggestions
or things I haven't thought of.
Thanks,
Judah
In the (extremely) rare case that I use a ColdBox plugin/utility object in my model, I have the object defined in my ColdSpring XML, and allow CS to inject it (either by constructor-arg or property). In 99.999999% of my use cases, I do not use anything from the framework in my model at all, but I may have my own “helper” UDFs and/or objects that are either a) injected by CS in the same manner, or b) are mixed-in via a standard .
HTH
Whoa, what's this talk of "moving" to a "different framework"? Don't listen to him Luis, that's just the late nights talkin'. ColdBox is the last framework you'll ever need, ok? 
Seriously though, this probably makes me a bad person but I never worry too much about doing something that ties me to a particular framework. For me, it would be pretty darn unlikely to ever move frameworks unless ColdBox started magically sucking or something. That being said, I DON'T make it any habit of coding stuff that ties me to my framework-- I would be far more concerned with doing something like modifying the core files in a way that made it hard to upgrade to the latest version of your favorite framework. (Like my last job where we bastardized Fusebox 4 to the point where we could never upgrade without rewriting the whole app.)
~Brad
...I was curious what
I agree with you Brad.
How many times in your history have you had to move entire set of apps (written in oo fashion) to another methodology. IN my experience, I have done this ONCE!!
And the transition for my model was actually a breeze. Thanks to Dependency injection you can really switch implementations like plugins, cache, etc, without constricting yourself to coldbox.
Now, I would not suggest you wire up your model objects with the coldbox controller.
Anyways, those are my .02 cents. If you want to recreate tools that are already written because of coupling, go for it. Also remember you can interface them and base your tools on the core framework also. Then you have no excuse.