I considered making a more feature-rich wildcard syntax in Zend_Filter_Input, and I saw what Bryce did in his Zend_Validate_Builder solution. But I decided to favor simplicity.
One of the goals of Zend Framework from the beginning was explicitly _not_ to solve all possible use cases, but to solve 80% of the use cases and so make the usage simple. Where possible, classes should be extensible to allow people to make their own solutions that solve their custom cases. But in this case, I do understand that Zend_Filter_Input doesn't support this kind of extensibility. Regards, Bill Karwin > -----Original Message----- > From: Mark Maynereid [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 15, 2007 3:49 AM > To: [email protected] > Subject: [fw-general] Zend_Filter_Input: extending the > wildcard feature > > Hi, > > I'm interested in seeing Zend_Filter_Input's wildcard feature > extended to support wildcard expressions similar to file > globbing eg. 'someRule*whatever*bla*'.' I've added a code > snippet below that seems to provide it. > > I see the manual supports only '*' as a wildcard in > filter/validator chains but I'm finding myself in a situation > where I want to create a rule like > this: 'searchFilter*' whereby all variable names beginning > with 'searchFilter...' are caught by the rule expression. > > My use case is that I have a form where the application user > is allowed to tailor the presence of fields by using, for > example an 'Add filter' droplist in combination with one or > more addfilter attribute droplists. > > To illustrate, as the user builds the form I might find > myself with this form variable to process: > searchfilter_height_max = '5' > searchfilter (telling me it's a search filtering type of form > variable) height (telling me the actual field name to work > on) max (telling me the filter should compare using the value > as an upper limit) > 5 (the actual value the user desires to use) > > Why so compacted like this? My form needs to use the GET > method and I'm already looking at ong urls. Splitting this > info up in the form would massively complicate the HTML side. > > An alternative might be to dynamically manage the rule naming > so I don't need wildcard expressions, and so it might look like: > > $staticValidators = array( > 'title' => 'Alnum', > 'someOtherStaticRule' => 'Alnum', > ); > // Now the ones I have to build dynamically build by snooping on > $request->getParams() > $validatorSearchFilters = array( > 'searchFilter_height_max' => array('Alnum', > 'allowEmpty' => true), > 'searchFilter_country_negate' => array('Alnum', > 'allowEmpty' => true), ); $validators = > array_merge($staticValidators, $validatorSearchFilters); > > > But this seems messy to me. I think I would prefer: > > $validators = array( > 'title' => 'Alnum', > 'someOtherStaticRule' => 'Alnum', > 'searchFilter*' => array('Alnum', 'allowEmpty' => true), > ); > > > Looking at the Zend_Filter_Input code, the validator part > dealing with > wildcards looks like this in _validate(): > > if ($ruleName == self::RULE_WILDCARD) { > foreach (array_keys($this->_data) as $field) { > - > - > - > > By overriding the method with the code like this I seem to be > able to get > wildcard expression support: > > if (false !== strstr($ruleName, self::RULE_WILDCARD)) { > $rulePregex = '/' . str_replace(self::RULE_WILDCARD, '.*?', > $ruleName) . '/'; > foreach (array_keys($this->_data) as $field) { > - > - > - > > As both _filter() and _validate() methods are quite big, if I > privately > override them I might come unstuck with future ZF released > modifications to > these methods. > > So if you are still reading this :) any views on the subject? > Is there a > better way? Or is this a reasonable code suggestion? Should I > raise an issue > ticket as a feature request? > > Regards, > Mark Maynereid > >
