Thank you Yoda. :) On Mon, Sep 1, 2008 at 9:10 AM, Dave Newton <[EMAIL PROTECTED]> wrote:
> Become the change you desire. > > http://struts.apache.org/helping.html#documentation > > Dave > > --- On Mon, 9/1/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > Subject: Re: REST Showcase 2.1.2 > > To: "Struts Users Mailing List" <user@struts.apache.org> > > Date: Monday, September 1, 2008, 10:03 AM > > 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] > > >> > > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
