This may not be the answer you want to hear, but I think it would be ok to display either a 'field cannot be empty' or 'invalid entry' message next to the zip code form field if the state, country, etc is invalid. If someone enters 'lqsdkfj' for the state, the error message next to zip code, while it may be meaningless, it would be correct. ' ', 00000, and 94103 are invalid zip codes for the state 'dsklqfdjs.'
If you find a great solution, post it. I'd be interested to know how you worked this out. On Sun, Jul 19, 2009 at 10:15 PM, Seth Atkins <satk...@nortel.com> wrote: > I appreciate the help here, but I think both of you are missing the > point a little bit, or I haven't explained the problem well. I don't > want to validate one element at a time, and yes I DO use the $context in > my isValid function. Context gives you the full form input, I wouldn't > even be asking this question if I didn't know how to pass the context > and verify one field against the other. Context, to the best of my > knowledge does not tell you the validation status of other elements, it > just tells you what the user inputted for those elements, bogus or not. > > Let me ask it this way. If I were to submit country asdf and state > gffdds, how the heck are you going to verify if the zip code is of the > right format for a bogus country/state submission. Any error you present > next to the zipcode field is going to be meaningless. You haven't helped > the user at all by providing that extra "info" and you haven't decreased > the likelihood one bit of them not having to resubmit the form a couple > more times to get all the fields correct. > > If I assume that the country is a real country and the state a real > state, then sure, all the tools I need are $context and serial > validation of all elements. But when it comes to security of a website, > preventing injection attacks and things of that nature, "assuming" > things like this is a pretty poor practice. I'm not trusting in the > honorability of the user to only select what I have in the select boxes > when I know how easy it is to fabricate POST data to a website. > > The real situation I face is not a zip code, but that was an easier > example to use than to describe how I have several joins and where > clauses to make to pull together a data set that contains the data > needed for form creation and validation. Now, I could simply remove the > where clauses so it retrieves all records so it is all available to > verify the dependent fields based on other fields and possible choices. > Not real efficient. Or I could live with an extremely inefficient use of > the database, with multiple queries to retrieve the same data: once to > generate the form, once for EACH validator to validate the form based on > it's own view of context, and once to write the form data back to > database. Or I minimize the database querying by not validating what > can't be validated if other fields are not correct. I'm trying to > optimize and there are a number of cases where validation of an element > is meaningless based on other elements and their validation. This is > what I am trying to avoid. > > All the arguments presented against why I would find this feature useful > can be used to argue against breakChainOnFailure at the element level > too. Why not show all the things wrong with an entry? Why make the user > fix one mistake at a time on an entry? The fact is, there are times when > it is actually useful to suspend the remaining validation checks on an > element once one check fails, JUST LIKE this is also sometimes useful > behavior at the form level. > > > --Seth > > -----Original Message----- > From: Matthew Weier O'Phinney [mailto:matt...@zend.com] > Sent: Saturday, July 18, 2009 5:01 PM > To: fw-...@lists.zend.com > Subject: Re: [fw-mvc] breakChainOnFailure > > -- Seth Atkins <satk...@nortel.com> wrote (on Friday, 17 July 2009, > 01:19 PM -0500): > > Then how does one validate dependent input? If certain fields need > > certain validation criteria depending on a previous field containing > > valid data, you can't properly validate the other fields. > > This has been covered many times before: add a second argument to your > validator's isValid() declaration for $context: > > public function isValid($value, $context = null) > { > } > > Zend_Form passes the entire array as a second argument to isValid(). If > you need to use it, it's available. > > This is well documented in the manual: > > > http://framework.zend.com/manual/en/zend.form.elements.html#zend.form.el > ements.validators > > and search for the heading, "Validation Context." > > This feature has been available since the initial stable release of > Zend_Form in 1.5.0. > > This *is* different than having a "breakChainOnFailure" feature for > Zend_Form itself, however, as this latter functionality changes the > behavior of Zend_Form substantially. The current behavior is to run > validation on *all* elements in order to return as much information > about invalid entries as possible. > > > For example > > suppose you wanted to check for valid zip codes based on the entered > > state (so someone couldn't enter a NY zip code with state AZ. If > > someone entered an invalid state and that failed its check, the > > remaining check on the zip code would give a bogus "invalid" message. > > I'd rather it simply suspend the rest of the form validation since the > > > rest cannot be validated properly. > > > > This may fall into the needed feature bucket for future releases, > > unless there is an easy workaround. I managed to find a clunky way of > > doing this by sort of "pre-validating" the input of the field that the > > > others depend on so I can put in a conditional to addValidator for the > > > affected elements. That way if the pre-validation fails, no validators > > > are added at all. If the pre-validation passes, then the others are > validated. > > > > The way I implemented pre-validation was to pass the field input to > > the form constructor. The form constructor has to gather some data > > from the database anyway, so I simply compare that field input to this > > > data to ensure it is a valid selection. Hence it is pre-validated. > > > > I looked through the code for isValid methods and it seems that this > > would be a fairly easy feature to implement if there was a mechanism > > in Zend_Form::isValid similar to breakChainOnFailure to tell it to > > stop looping through the element validators once one comes back false. > > > I could even do that myself, but I'm reluctant to start tinkering > > around changing the code base of ZF. > > > > > > > > --Seth > > > > -----Original Message----- > > From: Matthew Weier O'Phinney [mailto:matt...@zend.com] > > Sent: Thursday, July 16, 2009 4:56 PM > > To: fw-...@lists.zend.com > > Subject: Re: [fw-mvc] breakChainOnFailure > > > > -- Seth Atkins <satk...@nortel.com> wrote (on Thursday, 16 July 2009, > > 02:47 PM -0500): > > > I believe this feature works only within the scope of a single > > > element > > > > > validation. I may be misunderstanding how it works, but I believe it > > > > means that if the first validation fails, it stops validating and > > > outputs only the first validation error message. > > > > It means that if the given validator fails, it will not process any > > validators occurring after it in the chain. > > > > > What I am looking for is a way to break out of all form validation > > > if an element fails. If several fields have validators set, and the > > > first > > > > > field fails its check, then I'd like the $form->isValid($data) to > > > exit > > > > > the validation loop that takes it through the remaining elements. I > > > don't see a way to do this within the functions provided in ZF > > > unless I am missing something. Am I missing something? > > > > Zend_Form does not allow for this; it attempts to validate all > > elements, so that you can return all possible validation errors for > > all elements back to the user. > > > > You could likely write a validator that you insert at the top of each > > element that checks the parent form for any failed element validations > > > and skips validation -- but it would mark that element as failed in > > validation as well. > > > > -- > > Matthew Weier O'Phinney > > Project Lead | matt...@zend.com > > Zend Framework | http://framework.zend.com/ > > > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > >
