Page 2 of 4

Posted: Fri Mar 30, 2007 5:36 am
by onion2k
neel_basu wrote:You dont need to do anything on php
In your system explain to me how I would set up a validation that meant field2 is required if field1 is equal to a certain value.

Here's an example:

Code: Select all

How did you hear about this site: <select name="how">
    <option value="1">Please select an option</option>
    <option value="2">Search engine</option>
    <option value="3">Print advert</option>
    <option value="4">Recommended by a friend</option>
    <option value="5">Other (Please complete 'Other' box)</option>
</select>
Other <input type="text" name="other">
I have a dropdown box with "How did you find out about this site?". If the value is empty then the validation should fail because they didn't choose an option. If the user chooses options 1,2,3 or 4 then 'other' is not required. If the user does choose "Other", option 5, then they have to fill in a text input box stating where they heard about the site, eg 'other' becomes required.

That's a very common validation rule. Can your framework cope with it?

Posted: Fri Mar 30, 2007 5:39 am
by Maugrim_The_Reaper
The problem with validation classes is that, without exception, they're not powerful enough. If you need to validate content on a contextual basis (eg, if field1 is completed then field2 must be completed, and field3 must be an email address, and field4 must be identical to field3) there's nothing better than a simple if..else tree. Simply checking the values of each individual field meet some requirements is trivial. When you're doing proper validation you invariably need much more than that though.
Not sure whether that's an 80/20 experience though - most forms I go through only require a few exceptions like needing two password fields to eliminate typing errors and such. Complex forms aren't overwhelmingly a majority so a little special treatment for those hurts less.

There's also the possibility of using something other than procedural logic as you describe - think of how a build system like ant is configured for example. You could, for example, place a dependency on Password1 that Password2 exists and is valid. Password2 might have a dependency that the Email 1 field exists (which links into a dep on Email2). Purely contrived example (and I haven't seen such a validator in PHP either ;)). But in an OO system this would dictate the validation order of an array by finding the base dependencies first. I think that would be a neat system to implement to add a little more power for really tricky forms where certain fields are only valid if others are also valid.

Posted: Fri Mar 30, 2007 5:46 am
by neel_basu
onion2k wrote:
neel_basu wrote:You dont need to do anything on php
In your system explain to me how I would set up a validation that meant field2 is required if field1 is equal to a certain value.

Here's an example:

Code: Select all

How did you hear about this site: <select name="how">
    <option value="1">Please select an option</option>
    <option value="2">Search engine</option>
    <option value="3">Print advert</option>
    <option value="4">Recommended by a friend</option>
    <option value="5">Other (Please complete 'Other' box)</option>
</select>
Other <input type="text" name="other">
I have a dropdown box with "How did you find out about this site?". If the value is empty then the validation should fail because they didn't choose an option. If the user chooses options 1,2,3 or 4 then 'other' is not required. If the user does choose "Other", option 5, then they have to fill in a text input box stating where they heard about the site, eg 'other' becomes required.

That's a very common validation rule. Can your framework cope with it?
In This Way

Code: Select all

<?php
$validate = new validate();
if($_GET['how'] != '5'){$validate->exclude('other');}
print_r($validate->report());
?>

Posted: Fri Mar 30, 2007 10:08 am
by Luke
I have a situation just like what you are talking about, onion. If the user checks a checkbox that says "all day" the time fields are not necessary...

Code: Select all

/**
         * If event is not all day, validate the start and end times
         */
        if(!$form->exportValue('event_all_day'))
        {
            $form->addRule('event_start_date', 'If you do not select "all day", you must specify start and end times for this event', 'required');
            $form->addRule('event_start_time', 'Must be in hh:mm format', 'callback', array('Cal2','isTimeHHMM'));
        }
Still, HTML_QuickForms, with all of its problems, beats out anything else I've found in this situation.

Posted: Fri Mar 30, 2007 10:10 am
by dreamscape
arborint wrote:(FYI dreamscape - you have created a fluent version of Zend_Filter_Input 8O )
Actually, it's a fluent interface for the interface The Ninja Space Goat proposed in the first post, or any similar interface. Filters themselves are still atomic, but the main difference is that the interface is a facade and "hides" all of the dirty details involved in The Ninja Space Goat's proposed interface from the public at a lower level, so that as a programmer you yourself don't have to deal with them and can basically enter your rules as a sentence.

My:

Code: Select all

$validate->username->hasLengthOf(5, 15)->orError('Username must be between 5 and 15 characters');
would essentially call in the background:

Code: Select all

$validator->add('username', $_POST['username'], new Zend_Validate_StringLength(5,15), 'Username must be between 5 and 15 characters');
It's not that difficult to do. The first call to __get() sets the field, the 2nd call to __get() or 1st call to __call() sets and returns the current validator (naming convention would have to be used, for example hasLengthOf automatically wires to the class ValidateHasLengthOf) and resets the call count (so you can now add additional rules for the same or other fields). And orError() would either be a method of the individual validator interface or set the error message on the current validator (depends on what the main interface you are facading looks like).

It all really boils down to whether you like fluent interfaces and facades or not. I program nearly every day all day, and for me, "well designed" fluent interfaces that simplify dirty and complex interfaces make the day go a little bit better. But then, maybe it is just me, because I also like to have my applications wire its components together by itself. Maybe it doesn't immediately save time, because you have to set it all up that it can wire itself together, but that is a couple days at most, and from then on, it is smooth sailing and a big smile on your face because you don't really have to deal with those kind of dirty details again. At least as a programmer, I find the less dirty details I have to deal with, the better I like my job and more I enjoy doing it.

It also boils down to whether you prefer to see details over simplicity. For me, in the long run, the desire for simplicity has won out by a large margin over the desire to see details.

Posted: Fri Mar 30, 2007 11:23 am
by Christopher
dreamscape wrote:Actually, it's a fluent interface for ... It also boils down to whether you prefer to see details over simplicity. For me, in the long run, the desire for simplicity has won out by a large margin over the desire to see details.
The part of the code you left out is how "hasLengthOf" is mapped onto "Zend_Validate_StringLength". If the mappings are internal then your class is monolithic. If they are specified then you would need to add extra lines for the mappings which makes it less fluent.

That's really gets to the heart of the problems with ZF and most other systems. People want convenience because the problem is simple in some cases. But the problem is really much more complex so more complex code is necessary. People seem to be more willing to make shortcuts in their personal code than bite-the-bullet and jump to a full system. It will be more lines of code, like it or not.

Posted: Fri Mar 30, 2007 11:53 am
by dreamscape
arborint wrote:The part of the code you left out is how "hasLengthOf" is mapped onto "Zend_Validate_StringLength". If the mappings are internal then your class is monolithic.
The mappings would either be automatically wired by naming convention, i.e, the alias stringLenth automatically maps to Zend_Validate_StringLength (i.e., uppercase first letter and prepend "Zend_Validate_");

Or they would be automatically wired by configuration, i.e, some type of a configuration mechanism (be it file, code, or otherwise) that allows mapping the alias stringLenth to Zend_Validate_StringLength.

The first is easier to implement, but prone to problems in larger systems because there can be no naming collisions. Thus it is also less flexible because you cannot swap out a "default" validator for a different one using the same alias.

The second involves a little more work in implementing, but is ultimately much more flexible, because it does not rely on convention, so you could overwrite mappings, for example re-map stringLenth to Zend_Validate_UTF8StringLength instead of Zend_Validate_StringLength.

You could even do both, allow configuration, and default to convention in the absence of it.

[public] interface complexity is not -- or should not be -- synonymous with flexibility. It is quite possible to have a simple [public] interface that affords just as much [or more] flexibility as a complex counterpart does. Quite frankly I am getting a little tired of programmers assuming that something seemingly relatively simple cannot be highly flexible. That is, how should I say, a cop out position, no offense intended towards you.

It's a bit counter-intuitive, because the validator system as a whole would be required to grow more complex to allow the public interface to the system to grow more simple. It's a concept knows as "simplexity", making increasingly complex things appear to be simple. It's one of my core development values that I try to achieve in everything I do. Really I think all developers should adopt it as a core value, though some (or many) will not agree. It's a modern world and simplexity is growing increasingly popular. Look at nature; all of nature for the most part is simplexity. Or look at new technology. Many of the new gadgets appear to be quite simple to use, ie. they have a simple public interface, but are in fact quite complex pieces of technology if you peer beneath the facade that is their user [public] interface.

Posted: Fri Mar 30, 2007 12:13 pm
by Christopher
dreamscape wrote:
arborint wrote:The part of the code you left out is how "hasLengthOf" is mapped onto "Zend_Validate_StringLength". If the mappings are internal then your class is monolithic.
The mappings would either be automatically wired by naming convention, i.e, the alias stringLenth automatically maps to Zend_Validate_StringLength (i.e., uppercase first letter and prepend "Zend_Validate_");

Or they would be automatically wired by configuration, i.e, some type of a configuration mechanism (be it file, code, or otherwise) that allows mapping the alias stringLenth to Zend_Validate_StringLength.

The first is easier to implement, but prone to problems in larger systems because there can be no naming collisions. Thus it is also less flexible because you cannot swap out a "default" validator for a different one using the same alias.

The second involves a little more work in implementing, but is ultimately much more flexible, because it does not rely on convention, so you could overwrite mappings, for example re-map stringLenth to Zend_Validate_UTF8StringLength instead of Zend_Validate_StringLength.
Yeah, I understand how the mapping schemes would work. But the system would need internal mappings and would need code to support those mappings and you might need to specify which mappings to use and if you want something that is not part of the built-in mappings then you are back to needing more lines of code to specify that.
dreamscape wrote:[public] interface complexity is not -- or should not be -- synonymous with flexibility. It is quite possible to have a simple [public] interface that affords just as much [or more] flexibility as a complex counterpart does. Quite frankly I am getting a little tired of programmers assuming that something relatively simple cannot be highly flexible. That is, how should I say, a cop out position, no offense intended towards you.
Sometimes it is possible to a simple interface that is as flexible as a complex interface. And I would definitely support the simpler interface. But sometimes the simpler interface is not as flexible as a more complex one. I believe that is the case with filtering and validation.
dreamscape wrote:It's a bit counter-intuitive, because validator system as a whole would be required to grow more complex to allow the public interface to the system to grow more simple. It's a concept knows as "simplexity", making complex things appear to be simple. It's one of my core development values that I try to achieve in everything I do. Really I think all developers should adopt it as a core value, though some (or many) will not agree. It's a modern world and simplexity is growing increasingly popular. Look at nature; all of nature for the most part is simplexity. Or look at new technology. Many of the new gadgets appear to be quite simple to use, ie. they have a simple public interface, but are in fact quite complex pieces of technology.
This sounds a little subjective. If you can simplify an interface while maintaining function -- that's just good design. But you can't simplify everything.

The interface I showed apparently seems a little more complex than other systems ... although I find itsimpler. The difference is that the interface stays the same no matter how much the "complexity" if the rules and filters increases. All cases are handled in the same way. In other systems the simple cases may be simpler, but then you need to add complexity as complexity increases. And that's not simpler to me.

Posted: Fri Mar 30, 2007 3:52 pm
by dreamscape
arborint wrote:Yeah, I understand how the mapping schemes would work.
With all due respect, I'm not entirely sure that you do.
arborint wrote:But the system would need internal mappings and would need code to support those mappings
As I openly stated, the internal complexity of the system would have to necessarily increase. That is not in question, and is quite obvious. The purpose of simplifying an interface to a system without loosing flexibility is not to make the life of the system developer easier. It's to make the life of the user of the system easier. If you are writing your own code, then you serve both roles, and would loose out a little at first, but ultimately gain in the long run. However, if you are only the system developer, then you just have to bite the bullet at first too. But even if you are only the system developer, you too will still win out in the long run because you will have a happier and more loyal customer base.

Unfortunately, the Zend Framework developers do not seem to share in the philosophy that you should develop for your user. As far as I can tell, Zend Framework developers appear to be developing for themselves and not for users of Zend Framework, and there is a key distinction in there. It does not matter that the users are also developers. We developers are no different from other consumers; we also want the tools we use to be easy to use and have simple interfaces.
arborint wrote:But you can't simplify everything.
Sorry, but just another cop out. Some things are complex by nature. Hell a lot of things are complex by their very nature. However, just because something is complex by nature does not mean you cannot make it seem to be simple. That is what simplexity is all about; making very complex things appear to be simple. I for one hold the opinion that anything which is complex, can certainly be made to appear simple (relatively speaking).
arborint wrote:The interface I showed apparently seems a little more complex than other systems ... although I find itsimpler. The difference is that the interface stays the same no matter how much the "complexity" if the rules and filters increases. All cases are handled in the same way. In other systems the simple cases may be simpler, but then you need to add complexity as complexity increases. And that's not simpler to me.
What does any of that have to do with what I am talking about? The interface I showed is a facade to an interface like the one you showed. The only difference is how you access them. And in the case of mine there is a little bit of setup to do ahead of time. So in a small application, sure maybe accessing it the more complex way is "simpler" or just as simple, but do that in an applicaiton with 250,000 lines of code with several forms that all need validation, and you might start singing a different tune. I know about the 15th time I had to write "new Rule_Maxlength" I'd start thinking, "Gee I wish there was a simpler way to set these rules up".

Posted: Thu Sep 06, 2007 5:06 pm
by Luke
So it's been 5 months... anything new in the world of validation? I am writing an app with the Zend Framework and I don't really want to suffer through their validation. Is there something better yet?

EDIT: You know who has a really cool forms framework that fits my needs PERFECTLY? Django! Problem is, it's not PHP :(

Posted: Thu Sep 06, 2007 6:53 pm
by Christopher
Well ... they brought back Zend_Filter_Input ... I imagine dreamscape still thinks I am an idiot ... there have been a few forms proposals -- check the incubator ...

How do you like using Zend Framework? I have been steadily losing interest because it seems slow development a little.

Posted: Thu Sep 06, 2007 9:48 pm
by RobertPaul
Perhaps this isn't the place to ask, but what's the problem with Zend_Filter_Input? I just started using it recently for a few small items I'd been working on, so I guess I ought to know any critical pitfalls before I'm in too deep.

[edit]Nevermind, did some searching. Interesting...[/edit]

Posted: Fri Sep 07, 2007 5:53 am
by Bon Bon
I think the Zend framework needs a serious redesign if it is going to be taken seriously.

The Zend_Validate requires too much work for a task that should be considered a basic in any framework.

Posted: Fri Sep 07, 2007 10:39 am
by Luke
Bummer... I've been feeling the same way. I've heard good things about symfony, but the learning curve seems to be pretty steep. CakePHP looks decent, but I don't really want to learn a whole other framework. I wish python was as popular as PHP so I could use django :(

Posted: Fri Sep 07, 2007 11:48 am
by Christopher
Ninja, can you show us some pseudo-code examples of what you like about how Django does things?