stanlick wrote:
Also, what is the naming convention for validation xml files using the Code
Behind/REST plug-in?
I've tried several combinations of naming, but none seem to work.
The short answer is: you can't. It doesn't work.
Fortunately annotation validation works correctly in 2.1, so the
approach I've used is:
- the action carries validation annotations on the applicable methods;
- the model's use XML validation
as they can be used together and it's well suited to ModelDriven.
The problem is that the DefaultValidatorFileParser in Xwork that reads
the XML file has no way to specify which method it should be applied
to. It applies to the entire class.
With wildcards in 2.0 you could get around this because the action
"alias" included the method name.
It's the same reason using "method='update'" spefied in struts.xml never
worked properly with XML validation. The parameter was ignored by the
XML validator. This had always frustrated me.
Fortunately somebody fixed the annotation interceptor so it can
distinguish between the methods being executed. Unfortunately that fix
(validateAnnotatedMethodOnly) is not enabled by the rest plugin by default.
Further compounding the problem is that rest plugin has disabled
validation for the edit, editNew and other relevant methods. (I'm not
sure why...there must have been a reason for that).
What I've done is replace the rest default stack with one that includes
the validation interceptor with better configuration:
<interceptor-ref name="validation">
<param name="excludeMethods">input,back,cancel,browse,index</param>
<param name="validateAnnotatedMethodOnly">true</param>
</interceptor-ref>
<interceptor-ref name="restWorkflow">
<param name="excludeMethods">input,back,cancel,browse,index</param>
</interceptor-ref>
I've been tempted to delve in a fix this but so far I've stayed out of
xwork. The rest plugin does the right thing setting up the
ActionInvocation with the action name and method name; the XML
validation config reader just needs to use the method name to select the
file (eg. to load OrdersControler-<action>-<method>-validation.xml if it
exists). But I feel it already searches for far too many combinations,
so I've been reluctant to touch it.
stanlinck also wrote:
Would you share the interceptor stack to fold paramsPrepareParamsStack
capabilities into the restDefaultStack?
I haven't experimented with this much with the rest plugin as I try to
avoid it . It's reasonable logical...
The actionMappingParams interceptor is the one responsible for setting
the id, so it needs to appear before the prepare interceptor.
If you need other params, before prepare, you also need params before
prepare.
The actionMappingParams and params are then required after prepare again.
ie. set the id, load the object, set the id and params
It's different because the ActionMapper obtained the id from URI.
If you use other variables in the namespace you also need this
interceptor before prepare.
Hope that helps,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
