Hello Stephen,
based on my mail, Ryan created this ticket:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=641
and fixed it for the next RI release. Not that they released the last
release yesterday...
-matthias
On 9/26/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Ok.
>
> I sent an email to the RI mailing list, I am sure Ryan / Roger will
> answer my email soon !
>
> Greetings,
> Matthias
>
> On 9/26/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > 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
> >
>
>
> --
> 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
