thx for the file,
I'll check tomorrow (German time)
nice day!
-Matthias
On 8/30/07, Stephen Friedrich <[EMAIL PROTECTED]> wrote:
> Hello, and thanks again for looking into this.
> To be on the safe side I tried to reproduce the bug with a fresh and
> otherwise empty application.
> If you have
> <client-validation>DISABLED</client-validation>
> in trinidad-config.xml then the simplest example exhibits the bug.
> No validation at all takes places in this case:
>
> <f:view>
> <trh:html>
> <trh:head/>
> <trh:body>
> <tr:form defaultCommand="saveButton">
> <tr:inputText label="Value in between 1.0 and 100.0"
> required="true"
> value="#{valueBean.percentage}">
> <tr:validateDoubleRange minimum="1.0" maximum="100.0"/>
> </tr:inputText>
>
> <tr:commandButton id="saveButton" text="Save" action="saved"/>
> </tr:form>
> </trh:body>
> </trh:html>
> </f:view>
>
> However if enabled, client side validation does work in this simple page.
> (Of course this only hides the bug and the potential security breach
> introduced by not doing server-side validation.)
> I have not managed to make it fail by nesting the form in a table.
> I will investigate the missing client side validation in my real app
> further.
>
>
> hi,
>
> looks like the maximumSet fields are present in JSF 1.1 RI as well.
> Let me check what really the issue is, here
>
> Trinidad's validators do have some extra properties, like
> messageDetailMaximum on the doublerangevalidator, so we override it.
> We delegate the save/restore to the underlying FacesBean, which is
> more efficient.
>
> @Bug, I fix this in some minutes :-)
>
> Thx,
> Matthias
>
>
> On 8/30/07, Stephen Friedrich <[EMAIL PROTECTED]> wrote:
> > Matthias Wessendorf wrote:
> > > Well, why should Trinidad care about the minSet/maxSet. They are only
> > > in the RI, as you say.
> > > Not in MyFaces. Wouldn't that cause other issues ?
> >
> > Well ok, I can try and raise the issue with the Sun folks.
> > However I think it's in the best interest of Trinidad to play nice with the
> RI
> > and that a "Matthias Wessendorf" is much better suited to discuss this than
> > a "Stephen Friedrich" ;-)
> > Maybe you even have personal contacts to some of the RI developers.
> >
> > What would really help is if you could point me to some paragraph in the
> spec
> > that says you must only save/restore public attributes. Lacking that I still
> > don't have any valid argument why the RI is broken.
> >
> > I don't know that much about the spec and its internal implementation, but
> > so far it appears to me similar to the serialization problems you'll get
> > when a subclass fails to serialize the super class's fields. In that case
> it's
> > not the super class that is to blame.
> >
> > Anyway: Why _do_ the Trinidad validators have to overwrite
> saveState/restoreState
> > at all? I don't see them adding anything of value.
> > Or maybe do not extend the standard faces DoubleRangeValidator at all.
> >
> > BTW:
> > Here is a code snippet that to my unsuspecting eyes looks like a definite
> > Trinidad bug:
> >
> > In org.apache.myfaces.trinidad.validator.DoubleRangeValidator:
> > public DoubleRangeValidator(long maximum)
> > {
> > super();
> > }
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> mail: matzew-at-apache-dot-org
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
