Someone should update the REST plug-in docs so others don't waste days trying something that WILL NOT work as designed. Validation permutations can be tricky enough without chasing a dead end.
On Mon, Sep 1, 2008 at 8:57 AM, <[EMAIL PROTECTED]> wrote: > Thanks Jeromy -- > > I'd rather sleep with my sister than embed annotations in my code. This > notwithstanding, I understand your reluctance to add yet another permutation > to that lookup scheme. I poked around in the code back in 2.0 and nearly > got a nose bleed. I hope there are a ton of unit tests around that baby! > I'm getting the feeling that REST is not ready for prime time. I too > wondered why it was excluding edit, editNew. I'm sure there was a reason. > > Peace, > Scott > > > On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans < > [EMAIL PROTECTED]> wrote: > >> 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] >> >> >
