@Catagay: forget my offlist question The central messages element we could find by going through the tree and finding the first instance of the messages component. Would that be ok?
regards, Martin On 4/18/06, Cagatay Civici <[EMAIL PROTECTED]> wrote: > Hi, > > Then design maybe changed like; > > <cv:requiredFieldValidator for="text1" msg="msg1" error="Value is required" > highlight="true" enablePopup="false" /> > <h:message id="msg1" styleClass="someClass" /> > > This way there is no need to include the message component as a child. The > validator knows what to validate and what to use the display the error > message. If the msg attribute is not provided than the validation error is > displayed at main h:messages which acts like validation summary. > > > Regards, > > Cagatay Civici, > > On 4/18/06, Martin Marinschek < [EMAIL PROTECTED]> wrote: > > Yes, something like this. Don't know if the message needs to be > > included - can we find a way not to do this? What if you have several > > validators, but only one message component. > > > > @using the default server side validators: > > > > Due to the reasons Adam has pointed out (potential security risk) it > > would be good to have validators which always do server side > > validation as well. > > > > regards, > > > > Martin > > > > On 4/18/06, Cagatay Civici <[EMAIL PROTECTED] > wrote: > > > Hi, > > > > > > After some brainstorming on the discussion here's what I come up with; > > > > > > <cv:requiredFieldValidator message="Value is required" highlight="true" > > > enablePopup="false" display="dynamic"> > > > <h:message for="someInputTextToBeValidated" > > > styleClass="someClass" /> > > > </cv:requiredFieldValidator> > > > > > > By this way the message will be displayed using the message component. > Also > > > there are flags like enablePopup, display, highlight and more to provide > > > flexibility. The validators should use commons-validator also. > > > > > > Another idea will be to use the built-in standart validators rather than > > > seperate client validators above and in this case an attribute like > > > "enableClientScript" is needed. This will allow the validator validate > at > > > client site. Validators than can do both client and server side > validation > > > is the approach of Shale and .NET. > > > > > > Regards, > > > > > > Cagatay Civici > > > > > > > > > On 4/18/06, Martin Marinschek < [EMAIL PROTECTED]> wrote: > > > > Yes. > > > > > > > > That's the other thing I'd like to have - automatic client-side > > > > validation happening with the server side validation in place. It > > > > would be good to have something like a hook in the extended validators > > > > - with this hook, they are asked to render out their client-side > > > > validation javascript. > > > > > > > > Using this, separate validators wouldn't be necessary. > > > > > > > > Still, I think that the rendering question is very important. In the > > > > current state when working with ADF, I wished I could disable client > > > > side validation in ADF faces alltogether (I'm sure there is a way to > > > > do so, didn't look deeper into it so far). The popup box is just not > > > > context sensitive enough. > > > > > > > > regards, > > > > > > > > Martin > > > > > > > > On 4/18/06, Adam Winer < [EMAIL PROTECTED]> wrote: > > > > > > On 4/17/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > > > > > What I like about ADF faces is that it uses existing validators > for > > > > > > > the client side validation. What I don't like is that it > notifies > > > the > > > > > > > user with a popup box - not very interactive IMHO. > > > > > > > > > > I agree too - I'd like to feed that it into better schemes, > > > > > which I think is doable given the current APIs, esp. > > > > > popups floating by existing components. > > > > > > > > > > But to me, the really important issues aren't so much how it gets > > > > > rendered (which can be massaged down the line), but the > > > > > basic architectural ones, most particularly, how do you attach > > > > > client-side validation? For that, the only really clean answer > > > > > is that it should happen implicitly as a result of adding a > > > > > server-side validation, so that client-side validation is always > > > > > a strict subset of server-side validation. Any client-side > validation > > > > > scheme that doesn't follow this pattern is a security risk. > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > > > > > > > > > > > > > How do you tell the users that validation failed? > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > http://www.irian.at > > > > > > > > Your JSF powerhouse - > > > > JSF Consulting, Development and > > > > Courses in English and German > > > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
