struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stanl...@gmail.com
Subject Re: REST Showcase 2.1.2
Date Mon, 01 Sep 2008 15:57:07 GMT
Thank you Yoda. :)

On Mon, Sep 1, 2008 at 9:10 AM, Dave Newton <newton.dave@yahoo.com> wrote:

> Become the change you desire.
>
> http://struts.apache.org/helping.html#documentation
>
> Dave
>
> --- On Mon, 9/1/08, stanlick@gmail.com <stanlick@gmail.com> wrote:
>
> > From: stanlick@gmail.com <stanlick@gmail.com>
> > 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, <stanlick@gmail.com>
> > 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 <
> > > jeromy.evans@blueskyminds.com.au> 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:
> > user-unsubscribe@struts.apache.org
> > >> For additional commands, e-mail:
> > user-help@struts.apache.org
> > >>
> > >>
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message