What do you guys think of Zend_Validate?
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Looks kind of like what I'm trying to do. Interesting. I can't imagine how anybody could possibly think Zend_Filter_Input is a worthy validation/filtering method. It's nothing short of ridiculous. Zend_Filter_Input used to be bad (although I used it, arborint showed me the errors of my ways), but this second incarnation is HORRIBLE.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Yes it is. But a lot of us commented to that effect and yet it remains
. I think Maurice Fonk went so far as to start a project to just reverse the changes and progress from the original version. I think Bryce's proposal came closest to a workable solution that made sense (to me anyway) but it doesn't seem to have moved forward since it was accepted into the Laboratory. Maybe for Zend 2.0
.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I have been frustrated recently with maintaining sites built on Zend, Cake and Symfony. There is too much weird wiring working around basic design flaws in them.
I have begun moving all my client's sites to PHP5. Once I do that I think I may go back to my Skeleton code and upgrade it all to PHP5 so I can start using for larger projects. I will probably make it Zend compatible to an extent because I like some of their components. Frameworks like Skeleton are a little more work initially because more things have to be done explicitly, but I find in the long run it is easier to customize and maintain a system that combines objects following basic patterns rather than a system with an ever growing list of configuration methods to adapt non-standard designs.
One of the Cake guys, Chris Hartjes, did a podcast recently. I was struck by two things about his talk. First that he used the opportunity to criticize Zend and Code Igniter which are Cake's main competitors.
The second was his comparison of what he called Glue vs. Full Stack frameworks. Now there is some validity to the notion of loosely coupled vs tightly coupled classes being a design decision. But what struck me most is that he was unknowingly comparing the bad design of the frameworks mentioned. Glue vs. Full Stack is not an either/or decision. It is bad design that causes either too loose of coupling or too tight of coupling. The designs of those frameworks are what they are because to the limits of their designers. We see in this thread Zend making these kinds of bad decisions.
There is no reason what a framework cannot support building multiple full stacks on a single code base -- except the design skill of the current crop of PHP framework designers.
I have begun moving all my client's sites to PHP5. Once I do that I think I may go back to my Skeleton code and upgrade it all to PHP5 so I can start using for larger projects. I will probably make it Zend compatible to an extent because I like some of their components. Frameworks like Skeleton are a little more work initially because more things have to be done explicitly, but I find in the long run it is easier to customize and maintain a system that combines objects following basic patterns rather than a system with an ever growing list of configuration methods to adapt non-standard designs.
One of the Cake guys, Chris Hartjes, did a podcast recently. I was struck by two things about his talk. First that he used the opportunity to criticize Zend and Code Igniter which are Cake's main competitors.
The second was his comparison of what he called Glue vs. Full Stack frameworks. Now there is some validity to the notion of loosely coupled vs tightly coupled classes being a design decision. But what struck me most is that he was unknowingly comparing the bad design of the frameworks mentioned. Glue vs. Full Stack is not an either/or decision. It is bad design that causes either too loose of coupling or too tight of coupling. The designs of those frameworks are what they are because to the limits of their designers. We see in this thread Zend making these kinds of bad decisions.
There is no reason what a framework cannot support building multiple full stacks on a single code base -- except the design skill of the current crop of PHP framework designers.
(#10850)
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Well, consider some of the decisions of the last year or so. They're weighted in my direction (as a contributor's personal experience) so excuse the bias and reload the other way a bitMy faith in this project is starting to wither. I really had high hopes for the framework, but it seems that its design-by-committee nature is stifling development.
1. Zend_View reaches 1.0, and after 4+ months of campaigning, complaints, and general confusion still hasn't a single worthwhile measure for supporting atypical features of View structuring (layouts, partials, composite view, etc.)
2. Bryce Lohr's proposal is superceded by an alternative which sucks for input validation/filtering
3. Zend decide to write their own OpenID library - when one already existed, and was proposed, and even worked
They're some withering points for me. I don't get these kinds of decisions but they are made. Of course, it's not really the ZF's fault - I doubt there are many projects immune to bad decisions of some kind. It's practically a given in open source. Zend's responsibility to get releases out there on schedule, so every now and again something gets sacrificed to the Release Manager deity or some funky internal Zend wishlist.