Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of mwessendorf@gmail.com
 designates 209.85.146.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=OFZ3GPh6QOoCs8Ne34WcWVgHfZNtxDxP1zJI69MdSKppX8Jq/d9b8mNxVgvJ0rTVbDFJbMMv0R62Mjnch6kYs6UVqMOxjmpJ1E1Vr6D0mg/dCzB4yT3KvjokO/ojFDePIvr2XHldBsvMxKY+cvlouOcYQDOug4nB41akt2HlUGc=
Message-ID: <71235db40708300023mab73215yb82ec5dd18fbb66c@mail.gmail.com>
Date: Thu, 30 Aug 2007 09:23:18 +0200
From: "Matthias Wessendorf" <matzew@apache.org>
Sender: mwessendorf@gmail.com
To: "MyFaces Discussion" <users@myfaces.apache.org>
Subject: Re: [Trinidad] Aaaaaargg - validateDoubleRange broken on JSF RI 1.2
In-Reply-To: <46D66CF0.1040300@eekboom.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46D617EA.4030909@eekboom.com>
	 <71235db40708292355u1130dd4dt53f72bb93206cf63@mail.gmail.com>
	 <46D66CF0.1040300@eekboom.com>

> Well, yeah, because these fields are not in the MyFaces implementation it works there, but breaks in RI.
> How can you argue that there's no need to save/restore the fields because they are non-standard?
> Is the "save format" specified by the standard? The RI does save/restore the fields and it works ok
> when not using Trinidad. IMHO it is Trinidad that causes the bug by not honoring the super class specifics.

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 ?

are these xyzSet fields new in JSF 1.2.x ?
>
> >
> >> How to fix this?
> >
> > when it is in the RI, ask the sun guys.
> >
> >>
> >> BTW: I don't yet understand why client side validation does not kick in even before
> >> the wrong value gets to the server.
> >
> > Interesting is, that I am also on JSF RI 1.2.x + Trinidad stack, works fine.
> >
> > So, feel free to file an issue, with details (and a test-case ?)
>
> You mean you get client validation, right?
> Or do you also don't see the bug with the server side not validating min/max values?
> Client validation _is_ working in simpler forms for me, maybe my complex page breaks something.
> I get these warnings in the console. Do you think they can have something to do with the issue:
>
> 03:44:16,468 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugHtmlResponseWriter _errorWithComment
> WARNUNG: Illegal HTML: cannot put a <form> element in a <table> element.
> 03:44:16,828 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "costLimit::icon" is used more than once.
> 03:44:16,828 ERROR [STDERR] 30.08.2007 03:44:16 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "costLimit::msg" is used more than once.
>
> (I definitely do not use the "costLimit" id more than once, no idea why there are duplicates of these generated ids.


the response writer tells you, that <form> inside a <table> isn't valid HTML.

However, please file an issue, I'll take a look, what's going on.


>


-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org