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
