>From: "Wendy Smoak" <[EMAIL PROTECTED]>
>
> I'm having trouble with a custom validation rule. This used to work,
> before we had and before the switch to
> commons-validator 1.3.0. (Not that either of those changes is
> necessarily the cause of this problem, just trying to establish a
> timeline. :) )
>
There are several issues logged in the commons validator that required some
change. I think you are missing the formset/form info for your custom rule.
<formset>
<form name="org.apache.shale.validator.evenInteger">
<field property="evenInteger">
<arg position="0" name="message" key="arg" resource="false"/>
<arg position="1" name="message" key="submittedValue"
resource="false"/>
<arg position="0" name="parameter" key="submittedValue"
resource="false"/>
</field>
</form>
</formset>
I'll try to summarize some of the issues:
https://issues.apache.org/struts/browse/SHALE-31
https://issues.apache.org/struts/browse/SHALE-37 client side validation for
immediate
https://issues.apache.org/struts/browse/SHALE-65 client validation in data
list
https://issues.apache.org/struts/browse/SHALE-73 ignores dependencies
https://issues.apache.org/struts/browse/SHALE-180
https://issues.apache.org/struts/browse/SHALE-194
https://issues.apache.org/struts/browse/SHALE-217 value binding in the data
table
https://issues.apache.org/struts/browse/SHALE-247
https://issues.apache.org/struts/browse/SHALE-248
The big ones are 37, 65, 73, 217. They are not listed in the order they were
completed.
SHALE-73 This one reported that rule dependencies were not be evaluated
server side. This ended up being a pretty big deal due to the way the validator
rules were being invoked.
In Struts, the validator functions were all wrapped in a method that had a
common signature. The actual validation rule was invoked from the wrapper
function. The way it was implemented in shale was that the commons validator
directly invoked the validation function no wrapping function.
The problem with invoking a dependent validation rule before the target, was
that here was not any way to determine what the value of the formal parameter
should be passed of the dependent function.
To solve this problem, I used the validator form XML nodes to define the order
of the parameters and the name of the parameter being passed. I created a dummy
form to hold this extra meta-data. The form only has be be defined once per
custom validation rule. It's kind of a weird requirement but it's better than
having to define this information for each form you want to use the validation
on. In Struts, this was not abnormal since it's action oriented versus
component based. In JSF, it is more natural to capture validation parameter for
each instance of the validator.
I tried to communicate this in the JavaDoc
(http://shale.apache.org/shale-core/apidocs/org/apache/shale/validator/CommonsValidator.html)
I also created a bunch of test cases that invoke the validation (server side)
and test the rendering of the javascript by the ValidatorScript component.
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/test/java/org/apache/shale/validator/CommonsValidatorTestCase.java?view=markup
SHALE-37 In Strtus, we have a couple types of buttons. The submit button and
the cancel button. The cancel button added a bit of javascript that bypassed
client side validation. This issue is about mimicking the same behavior for
command's (commandLink, commandButton) that have their immediate flag turned
on. The trick here is to inject a bit of javascript without having to rewrite
the commands renderer's. The approach was to wrapper the RenderKit and wrapper
the renderer's of the command family. The decorated renderer's hijack the
response writer for just the rendering and swap back the original. We found
that it was only safe to do this for the command components that are required
by the RI because other components play the same games.
SHALE-65 This is also another interesting issue having to do with client side
validation within a UIData component. Components that extend UIData display a
grid of information. These components implement the fly weight pattern meaning
that they only contain components that represent a single row of the backing
model. As rendering occurs, the model is enumerated. This was a problem for the
ValidatorScript component that builds all of the client side javascript buy
looking at the tree after most of the tree had already been rendered. The
client side script needed to have the client id's of each input component in a
dataTable. The only way to capture the component client ids is at render time.
The same renderer decorate trick was used to capture the client id's of each
component before rendering and tuck them into a collection stored in the
components attributes collection.
SHALE-217 This one also had to do with client side script within a UIData
component. The validator attributes for the canned rules support value binding
expressions. The binding expressions were only invoked once per component
within the UIData component. This didn't work for client side validation since
the binding expression could be different for each visible row. The validator
attributes needed to be captured for each row at the time or rendering. The
render decorator trick was used to solve this problem too. We wrapper all
renderer's of components in the input family and capture their validator
attribute state before rendering so that the ValidatorScript component can
build the javascript to validate each visible component using the commmons
validator client side validation.
SHALE-248 This ticket was to upgrade shales commons validator support to
version 1.3. In the 1.3 version, the javascript is pulled from the commmons
validator archive. All the client script was removed from the XML file and the
jsFunction attribute of the validator node links to the javascirpt. Another big
change was that this version made a point to allow client side validation of
multiple html forms on the same page. All of the javascript factors in the form
name to determine the correct callback function that provides the rules
validation parameters. The ValidatorScript component had to be refactored to
capture what form a component was contained by in order to build the correct
javascript funcitons.
>
> Thanks,
> Wendy
Gary
