Since I am on trainings today/tomorrow, I will comeback to this possible already over the weekend...
Greetings, Matthias On Thu, Jun 19, 2008 at 11:43 AM, Stephen Friedrich <[EMAIL PROTECTED]> wrote: > Thanks Matthias for the answer. > I spent a couple more hours on it. > Looks like there are two problems: > > - Client side validation is not run when form is submitted via > defaultCommand: > That is https://issues.apache.org/jira/browse/TRINIDAD-695 and that issue > contains some suggestions for a fix. > > The second bug is much more serious, because it leaves the server without > any > validation. > > - tr:validateLength (and very probably also the other validators that extend > the > standard validators like tr:validateDoubleRange) don't validate anything on > the > server at all when used with mojarra. > This bug is very similar to one I reported earlier, and that you helped me > get resolved: > https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=641 > At first I checked wether that fix is still in mojarra 1.2_08, but that is > ok. > However Trinidad no longer restored the minimum and maximum fields of the > base > class javax.faces.validator.LengthValidator. > So far I have no idea where those values should get restored: > PropertyKey.restoreValue() and StateUtils.restoreState() seemed good > candidates > but I can't see any (reflective?) call (to setters) anywhere. > Any idea? > And generally: Is there any explanation how state saving is supposed to > work > with Trinidad? The javadoc is a little scarce. > > IMHO the cleaner way would be to not extend the standard validators at all. > There isn't much code reuse going on anyway and it seems to be too fragile > (currently broken for the second time). > > > Matthias Wessendorf wrote: >> >> Perhaps I have time to check on the weekend. >> There is already a bug like this in jira. Patches >> are welcome too. >> >> On Thu, Jun 19, 2008 at 6:44 AM, Stephen Friedrich <[EMAIL PROTECTED]> >> wrote: >>> >>> While testing I noticed that my application crashed with an error from >>> the >>> persistence layer. >>> I found out that the reason is invalid form data submitted using enter in >>> a >>> tr:inputText that is contained in a tr:from with a defaultCommand. >>> > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
