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
