Just a quick thought here on form data validation context in object oriented programming (OOP) and ColdFusion; As I was updating my ErrorCollection.cfc to be used by the Service Objects' Valiate() method, I realized that form validation must take into account the context, or rather the intent of the intent of the form. Form data isn't just valid or invalid; it's valid with regards to a desired action as different actions incur different business logic and rules. I don't have to deal with this in my application, as it is quite small, but take, for example, the Joint object. I don't even delete joints from the system, but if I did, I certainly wouldn't want to delete a joint that was associated with an existing exercise as this would corrupt the existing data.
So, zoom out a bit, if we were dealing with a joint, then we would have two different sets of validation logic:
Action: Update Joint
- Is name of joint set.
- Is name of joint a given length.
Action: Delete Joint
- Is joint associated with an existing exercise.
Since the context is so important, you can't just have one validation method, Validate(), as I was planning to have. You have to have a validation method for each desired mutating CRUD action. I combine Create and Update into a single Save() method, so I would need:
I feel like with every passing hour, form data validation in object oriented programming is proving to be harder and harder! Procedural programming makes this so easy, but not reusable at all (I know, I know, the payoff is there).
Looking For A New Job?
- ColdFusion & AngularJS Web Developer for rapidly growing startup - at Intuvo
- Senior Coldfusion Web Developer (UK - Kent) at EPG Health Media
- Web Developer at Bridge Catalog
- ColdFusion Developer at Company Confidential
- FT Remote Web Application Developer (ColdFusion) at Quality Matters
I think the availability of OO techniques has gotten many CFers thinking that OO is the "one true path". You can write well-encapsulated, reusable code that isn't OO.
I am a huge fan of ColdFusion custom tags, user defined functions, and general CFC-ery, but I figured, learning a new technique for something can never hurt. Clearly, there is a big learning curve for stuff like this, and maybe I will find in the end that it's just not for me; but, gosh darn it, I'm going for it :)
I'm glad you are! Well worth it just to gain the experience. I love reading about it.
I was only objecting to the line "Procedural programming makes this so easy, but not reusable at all". Procedural programming doesn't guarantee that code can't be reusable.
Agreed. Not sure what I was thinking when I wrote that :)