[
https://issues.apache.org/jira/browse/TRINIDAD-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607111#action_12607111
]
Matthias Weßendorf commented on TRINIDAD-1129:
----------------------------------------------
@CACHE_VIEW_ROOT: you see the issue here, because the restoreStateI() of the
original class isn't called. Things like Tomahawk t:stateSave will work now,
because of that. But the validator from Trinidad fails, because doesn't push
the "restore" to super. So, I think the best is here to just implement the
validation logic inside the Trinidad class. I'd still keep the base class, so a
"instanceof javax.faces......" is still OK. Does that make sense?
> Server-side validation does not work when using Sun JSF implementation
> ----------------------------------------------------------------------
>
> Key: TRINIDAD-1129
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1129
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.2.8-core
> Reporter: Stephen Friedrich
> Attachments: test.war
>
>
> <tr:validateLength> (and very probably other Trinidad validator also) do not
> validate anything on the server side at all.
> Trinidad's org.apache.myfaces.trinidad.validator.LengthValidator is a
> subclass of javax.faces.validator.LengthValidator.
> Trinidad's validate() method first delegates to the super class and if no
> validation exception occurs there, it does nothing.
> However the JSF base class never validates anything because the "minimum" and
> "maximum" fields do not have their values restored.
> It seems that the Trinidad way of handling state saving conflicts with
> mojarra's expectations.
> (Using mojarra 1.2_08)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
