Page 2 of 2
Posted: Wed Sep 12, 2007 5:07 pm
by Luke
If I were to go the composite route, I don't see how I would apply it to filtering. For instance, how do I make changes to one central data source within my filters (which, by the way, can be virtually endlessly deep)? I am having a hard time figuring out how to pass the data to the filters and then get that data back into the base MC2_Input class. Any ideas?
Posted: Wed Sep 12, 2007 5:14 pm
by Christopher
Jcart wrote:You still have to pass your filter and validator objects to your input object so the benefit here is having things handled internally. By nature a chain library validator/filter involves a lot of keystroke, so I personally like to keep the interface as small as possible.
I think the difference for me is that I pass the "input object" (Request) to the validator or filter chains. I don't tend to have them run together -- filters are early in the controller, whereas rules determine the controller state so are later. For configuration I have the controller associate them with a parameter/field. Another reason I mentioned above is that filters and rules have different goals, modification and test/error messages. If it is all in one then you probably have a separate logger to gather error messages.
Posted: Wed Sep 12, 2007 6:07 pm
by wei
arborint wrote:Jcart wrote:You still have to pass your filter and validator objects to your input object so the benefit here is having things handled internally. By nature a chain library validator/filter involves a lot of keystroke, so I personally like to keep the interface as small as possible.
I think the difference for me is that I pass the "input object" (Request) to the validator or filter chains. I don't tend to have them run together -- filters are early in the controller, whereas rules determine the controller state so are later. For configuration I have the controller associate them with a parameter/field. Another reason I mentioned above is that filters and rules have different goals, modification and test/error messages. If it is all in one then you probably have a separate logger to gather error messages.
exactly, filtering and validation are orthogonal, thus they should be separate.
It is the following which complicates the interface
Code: Select all
$data->addValidator($ruleset1);
$data->addValidator($ruleset2);
$data->addValidator(new Zend_Validate_StringLength(6, 35), 'password', 'Password must be between 6 and 35 characters');
this addValidator() method is doing too many things. Moreover, it seems as though the $data object is holding the fields names and error messages (which I presume will have more than a few lines of logic to validate its validators).
And, since you already have a composite (I presume) in the form of "Validate_Set", this is all it needs to facilitate a list of validators.
also, "Zend_Validate_StringLength" seems redundent, as it can be better and easily achieved using regular expressions (to include utf8 chars). e.g. /[\s\S]{6,35}/u or /\w{6,35}/ for non white space chars.
Wei.
Posted: Fri Sep 14, 2007 1:45 pm
by Luke
I'm having a design issue. I have come to the realization that the state of being "required" in my little library is kind of a special case in that only when an element is "required" should all of the other validation rules be applied. The validation should not care about whether a date is in the correct format if it is not required. So how do you guys suggest I go about that? Here is my current use case (without treating required as a special case).
Code: Select all
$input = new MC2_Input($post);
$filter = new MC2_Input_Filter_Set();
$filter->addFilter(new MC2_Input_Filter_StringTrim());
$validate = new MC2_Input_Validate_Set();
$validate->addValidator(new MC2_Input_Validate_NotEmpty(), array( // meaning these fields are required
'vendor_name',
'code',
'contact_name',
'email_1',
'address',
'city',
'state',
'zip',
'phone'
), 'This field is required');
// This should only apply to "code" if "code" is required
$validate->addValidator(new MC2_Input_Validate_Regex('#[a-zA-Z0-9_-]+#'), 'code', 'The code may only contain letters, numbers, dashes, and underscores');
$input->addFilterSet($filter);
$input->addValidatorSet($validate);
I was thinking of maybe adding a method to MC2_Input_Validate_Set() called setRequired that would tell the validation which fields to validate against. Does this sound like a good design decision?
Posted: Sat Sep 15, 2007 7:24 pm
by wei
how about create another class, e.g Validate_Group, very similar to the set, just returns false on first validator error?
Posted: Sun Sep 16, 2007 5:56 pm
by Christopher
The Ninja Space Goat wrote:I'm having a design issue. I have come to the realization that the state of being "required" in my little library is kind of a special case in that only when an element is "required" should all of the other validation rules be applied. The validation should not care about whether a date is in the correct format if it is not required. So how do you guys suggest I go about that? Here is my current use case (without treating required as a special case).
I am a little confused about this statement. If you don't care whether a optional field is in the right format, then do not have a rule for it when validating the form. I don't put any rules on fields that are not required for validating the form. If I want to validate an optional value and keep or reject it based on its format, I would do that in a second pass.