Hi Fintan,
> One solution is to have a method in your backing bean which validates > the entire backing bean values (or have a separate > MyBackingBeanValidator class which does the same). This method is > called just before the "save()" method is called on your bean. This way > you are validating only when you need to save the data. thanks, but how do you show the user the messages of validation errors. Don't you have to generate the FacesMessages yourself, and add it to the specific component messages in the JSF page? That would necessarily require more code to write and to maintain. Additionally work is introduced if you want the messages to be localized. That's why I think it would be better to have a facility to * save view away / restore view again * as needed, independent of the navigation history, or the JSF implementation behavior, respectively. Regards, Matthias > -----Ursprungliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Conway. Fintan (IT Solutions) > Gesendet: Donnerstag, 1. Dezember 2005 10:43 > An: MyFaces Discussion > Betreff: RE: UI component behavior problem > > > Hi Matthias, > > One solution is to have a method in your backing bean which validates > the entire backing bean values (or have a separate > MyBackingBeanValidator class which does the same). This method is > called just before the "save()" method is called on your bean. This way > you are validating only when you need to save the data. > > Just a thought, > > Fintan > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 01 December 2005 09:30 > To: MyFaces Discussion > Subject: AW: UI component behavior problem > > > > I think that's some kind of problem with JSF. I want the validation to > be applied when the form is submitted to save, of cource, at the end of > the user task. But I do not want the page to be validated only when the > user navigates to an edit details page, which is part of the form of the > first page. I also do not want the page to be validated only when the > user changes a selection in a selectOneMenu. Both will break the user > work flow, because the selectOneMany or the edit details link comes > logically before some other input components, or worse, depend on the > selection of the selectOneMenu or selectOneRadio -> that would cause > that the user has to input mandatory info which is not relevant or > required after the selection, which may show a partly different form. > > > > * ** *** ** * ** *** ** * ** *** ** * > 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. > > * ** *** ** * ** *** ** * ** *** ** * >
