Nope,
I try to look at it...
-M
On 9/25/07, Stephen Friedrich <[EMAIL PROTECTED]> 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 <[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
