Matthias, I think your best bet is to look at the compareTo validator source.
1) It might already be doing what you need if you're working with only two components. 2) It's got code to handle all of the cases, regardless of ordering or validation or immediate status. And if not, it's a bug we need to fix :) On 12/15/05, Matthias Kahlau <[EMAIL PROTECTED]> wrote: > Hi! > > Yes, your approach described should work. But there are other possible > constellations, as I found out in the meantime (see also the email of Simon > Skitching: > http://www.mail-archive.com/users%40myfaces.apache.org/msg13438.html). When > implementing cross-component validation, it's very important to be aware of > the lifecycle and the component update points relative to the lifecycle, and > also that the validators are processed in the order of their occurence in > the form. > > But not only the ordering of the components in the form is deciding, you > also have to consider the immediate configuration. Validator methods of > components configured immediate are invoked in the apply request values > phase, validator methods of components configured none-immediate are invoked > in the process validations phase. > > > Regards, > > Matthias > > > > -----Ursprungliche Nachricht----- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Auftrag > > von Conway. Fintan (IT Solutions) > > Gesendet: Donnerstag, 15. Dezember 2005 10:49 > > An: MyFaces Discussion > > Betreff: RE: Retrieving component values in validation methods > > > > > > > > > 2) Which is the right method to get the values of other components in > > > the validator method, getSubmittedValue(), getLocalValue(), dependent > > > on configuration issues (immediate) of the component owning the > > > validator and other components asked in the validator method? > > > > Would the following work for you? > > (Taken directly from "Core Java Server Faces" book) > > > > The trick is to attach the validator to the last of the components. By > > the time its > > validator is called, the preceding components passed validation and had > > their > > local values set. The last component has passed conversion, and the > > converted > > value is passed as the Object parameter of the validation method. > > > > Of course, you need to have access to the other components. You can > > easily > > achieve that access by using a backing bean that contains all components > > of the > > current form. Simply attach the validation method to the backing bean: > > > > public class BackingBean { > > private UIInput dayInput; > > private UIInput monthInput; > > ... > > > > public void validateDate(FacesContext context, UIComponent > > component, > > Object value) { > > > > int d = ((Integer) dayInput.getLocalValue()).intValue(); > > int m = ((Integer) monthInput.getLocalValue()).intValue(); > > int y = ((Integer) value).intValue(); > > if (!isValidDate(d, m, y)) { > > FacesMessage message = ...; > > throw new ValidatorException(message); > > } > > } > > ... > > } > > > > Note that the value lookup is a bit asymmetric. The last component does > > not > > yet have the local value set since it has not passed validation. > > > > An alternative approach is to attach the validator to a hidden input > > field that > > comes after all other fields on the form. > > > > <h:inputHidden id="datecheck" validator="#{bb.validateDate}" > > value="needed"/> > > > > The hidden field is rendered as a hidden HTML input field. When the > > field > > value is posted back, the validator kicks in. (It is essential that you > > supply some > > field value. Otherwise, the component value is never updated.) With this > > approach, the validation function is more symmetrical since all other > > form > > components already have their local values set. > > > > > > * ** *** ** * ** *** ** * ** *** ** * > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. > > Any views or opinions presented are solely those of the author, > > and do not necessarily > > represent those of ESB. > > If you have received this email in error please notify the sender. > > > > Although ESB scans e-mail and attachments for viruses, it does > > not guarantee > > that either are virus-free and accepts no liability for any > > damage sustained > > as a result of viruses. > > > > * ** *** ** * ** *** ** * ** *** ** * > > > >
