Comments on: Zend_Filter Reviewed, Blacklist / Whitelist Filters

By: Anonymous

Anonymous — Fri, 21 Jul 2006 21:28:21 +0000

screw Zend’s framework, Im using PHPonTrax

By: amperspective » Link Filter

amperspective » Link Filter — Sun, 16 Jul 2006 09:33:54 +0000

[…] Maarten Manders has a review of the Zend Framework Zend_Filter class, basically a set of methods for validating untrusted data. […]

By: Paul M. Jones » Blog Archive » Solar 0.15.0 alpha released

Paul M. Jones » Blog Archive » Solar 0.15.0 alpha released — Wed, 05 Apr 2006 16:03:50 +0000

[…] Speaking of Solar_Filter, it probably bears comparison with Zend_Filter and Zend_InputFilter, seeing as they were recently reviewed at SitePoint. Solar actually has two separate classes for these functions: Solar_Valid, to check if input matches a particular format, and Solar_Filter, to force input to match a particular format. (Solar_Filter was contributed by Matthew Weier O’Phinney some months ago; thanks, Matthew.) […]

By: yosoyminero

yosoyminero — Thu, 30 Mar 2006 07:32:30 +0000

I don’t really know if it is already considered, but UTF-8/Unicode should also be in the scope…

By: Christopher Thompson

Christopher Thompson — Wed, 29 Mar 2006 17:12:09 +0000

Maarten: Actually it’s not overdesigned — it’s simpified, modular, and pretty standard. And as I said, I see no problem with procedural style solutions like Zend_InputFilter and would make no changes to it.

But the classes underneath Zend_InputFilter should allow multiple for solutions that are OO or procedural, and are simple or complex. The current Zend_Filter does not. They apparently just split out code from InputFilter not thinking about other use cases.

By: Arnaud

Arnaud — Wed, 29 Mar 2006 14:47:11 +0000

coffee_ninja: i understand the idea of the framework is to give you power through simplicity so I would say you should get both :)

By: coffee_ninja

coffee_ninja — Wed, 29 Mar 2006 12:35:11 +0000

Arnaud, from the bit I looked at the DB portion of the framework, I’d have to agree. I think ZFW needs it to “be complete,” but I don’t neccessary think I’m going to get much use out of it.

I’ve been writing my own DB layers for my applications, writing an interface that specifies what methods I need, then implementing it for a specific DBMS. I usually write Factory class to retrieve the right implementation. Personally I like doing things this way, as I can take advantage of features specific to any system.

Correct me if I’m wrong, but if I choose to use Zend_DB, I’ll trading in a lot of power for simplicity of coding, right?

By: Arnaud

Arnaud — Wed, 29 Mar 2006 10:59:20 +0000

coffee_ninja: the db part looks like the weakest point in the MVC part right now. I’ve started to use the ezcDb layer instead but haven’t got far enough to see what effect it has.

By: Maarten Manders

Maarten Manders — Wed, 29 Mar 2006 08:28:31 +0000

Or.. let’s use fluent interfaces ;)

$filter->theShit()->outOf()->untrusted($garbage)

Nah, seriously: Christopher, you do have a point but your suggestion looks way overdesigned from a PHP perspective. I can’t say that I love the ongoing trend to static methods but it’s really simple this way and that’s what the Zend Framwork is all about.

By: Christopher Thompson

Christopher Thompson — Wed, 29 Mar 2006 07:32:02 +0000

I really think the Zend_Filter class should be completely changed. The InputFilter class provides a handy shortcut way to do simple filtering, but for more advanced controllers you really need FilterChain/Validator style classes. To achieve that, the Zend_Filter class should be split into two groups: Filters and Rules. Filters modify the value passed to them; Rules return true/false. To allow extensiblity each Filter and Rule should be its own class. This allows FilterChain and Validator classes to accept the polymorphic Filters and Rules (respectively).

The InputFilter class could keep the same interface and would only need minor changes internally to use the Filters and Rules classes. But this change to Zend_Filter would open up many more filtering and validation possiblities.