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
