myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: [Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
Date Wed, 26 Sep 2007 06:20:39 GMT
Nope,

I try to look at it...

-M

On 9/25/07, Stephen Friedrich <trinidad@eekboom.com> wrote:
> Hi Matthias, any news on this?
>
> I am getting the same error on Trinidad 1.0.2 when client side validation is disabled.
>
> Matthias Wessendorf wrote:
> > thx for the file,
> > I'll check tomorrow (German time)
> >
> > nice day!
> >
> > -Matthias
> >
> > On 8/30/07, Stephen Friedrich <trinidad@eekboom.com> 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 <trinidad@eekboom.com> 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

Mime
View raw message