No, this is what i meant when I offered to create a filter iterator.
See the SPL class FilterIterator. I'd propose that a Filter_Filter_Iterator
would be the correct way to do this, not as a default iteration.
A Zend_Filter_Iterator class would work like this
$filter = new Zend_Filter_Input($data);
$iterator = new Zend_Filter_Iterator($filter, array('Zend_Filter',
'methodofyourchoice')); <-- note that this would be typical array callback
syntax
foreach($iterator as $k=$v) {
... all entries here would have to match the filters true/false. A
read-writer iterator could also leave keys alone and modify the values for
test* functionality
}
Now that I think of it though, this might be a better addition to spl itself
as a CallbackFilterIterator; I'll talk to marcus about this.
Kevin
----- Original Message -----
From: "Nico Edtinger" <[EMAIL PROTECTED]>
To: "Kevin McArthur" <[EMAIL PROTECTED]>
Cc: <[email protected]>; "Bill Karwin" <[EMAIL PROTECTED]>
Sent: Monday, November 27, 2006 4:35 PM
Subject: Re: [fw-general] Patch for ZF-170. No Karma to Zend_Filter == no
direct commit =P
[27.11.2006 23:27] Kevin McArthur wrote:
+ public function offsetGet($offset) {
+ return $this->getRaw($offset);
+ }
Wouldn't it be better to have a default method that can be set and is
used for these interfaces? Like
protected $_defaultMethod = 'getAlpha';
public function setDefaultMethod($method) {
if(!method_exists($this, $method)) {
throw ...;
}
$this->_defaultMethod = $method;
}
public function offsetGet($offset) {
return $this->$method($offset);
}
Of course the default method should also be used in the iterator, which
means Zend_Filter_Input should implement Iterator instead of
IteratorAggregate. But it's not that hard to implement - just a bunch of
additional methods.
nico
PS: somehow this feels like a deja vu. I think there was a discussion
about something like this already.
