http://coldfusion.com logo
Join SlackCommunities
Powered by
Thread to discuss my solution
# box-products
r
Thread to discuss my solution
This is my solution. On 
BaseEntity.cfc
i have defined this method
Copy code
private function defineConstraints(struct constraints){
		if(isDefined('super.constraints')){
			structAppend(this.constraints, arguments.constraints);
		}else{
			this.constraints = arguments.constraints;
		}
	}
And in each child i have to define cbValidation constraints this way
Copy code
function init(){
		super.init();

		defineConstraints({
			quantity: { required:true, type:"numeric" }
		});
	}
Feels a bit hacky. What do you guys think?
d
Hi Ryan, I don't have any production experience with cbValidation. but I do have a refactoring branch where I'm implementing it. So anyways I really like Gavin's example code here: https://github.com/gpickin/itb2020-fluentAPI/blob/master/modules_app/api/modules_app/v6/models/BaseEntity.cfc
notice its v6, he starts off with v1 and refactors it step by step until v6. its a nice example for beginners. which in this case i'm a cbvalidation beginner.
hope this helps.
r
Hi Daniel, I think I have followed this tutorial before (@gpickin is great!) but unfortunatley, this does not deal with inheritance. Gavin is defining 
this.constraints
on the object instance which is the problem I am having.
s
I think I'd use getters instead of referencing 
this.constraints
directly
Put a 
this.constraints
on the parent with 
getConstraints()
, then on 
Trade.cfc
I'd have 
getConstraints()
which does 
return SUPER.getConstraints().append({ someNewConstraints }, true );
and then the same thing on 
Forward.cfc
that seems like the fewest number of 'things' to get you where you want to be. otherwise you're doing 
this.someMoreConstraints
and still using getters anyway
d
I don't know cbvalidation but I would stay away from creating public variables on your objects. Really is a no no for encapsulation.
It looks like you are trying to implement a decorator pattern. Normally you don't want multi inherit in that case but have your objects be able to wrap and implement a single interface to bubble down and then back out. But for your example why do you want each subclass to have a separate array of constraints wouldn't you want them all to just have the constraints?
On your base entity I would create a private variable called constraints, add a getConstraints function and a appendConstraints function, both public. Then any object that extends baseClass can call get constraints to get your constraint array and also call append constraint. Then in your baseClass in your init you initialize the array. In your first subclass’a init you append the rules for that and then your sub sub class you do the same. Making sure to call super.init as the first line in each init function.
Sorry not at an editor so can't really toss out an example code but
r
@deactivateduser I get what you mean and I will try implement it. Also 100% agree not to make public variables but cbvalidation internally checks for a public constraints variable on the object.
🤢 1
s
It only does that if you don't provide it with constraints when you invoke it.
validate( target = someObject, constraints = someObject.getADifferentSetOfConstraints() )
đź‘Ť 1
It's only if you leave out the 
constraints
argument that it goes looking for 
this.constraints
Open in Slack
PreviousNext
Powered by