Ted --

This is a great explanation!  Can you add to this how Validator naming works
with respect to wildcard methods?  For instance:

CourseAction
  list()
  create()

Course-validation.xml
and supposedly support for something like Course-create-validation.xml

I think I remember reading something about this support at some point?

Thanks,
Scott


On 4/5/07, Ted Husted <[EMAIL PROTECTED]> wrote:

How the link is generated isn't relevant. Once the response hits the
browser, everything is in HTML, and the framework is no longer
involved. When the client clicks the link, it sends back a GET for the
resource. If the action resource has been configured for validation,
then validation fires. By now, the framework doesn't know what
creature manufactured the GET request. A request is a request is a
request. Whether a form was used is also not relevant (or even known).
A form can submit by GET too.

When an Action class has a validator, the methods that are excluded
from validation can be specified as part of the Interceptor stack.

                <interceptor-ref name="validation">
                    <param
name="excludeMethods">input,back,cancel,browse</param>
                </interceptor-ref>

The usual suspects to exclude are input, back, cancel, and browse, but
any method names could be configured.

I haven't been watching the annotation work, but I expect that
@skipvalidation is a special case of the general exclusions that can
be made for certain method names. If that idiom works in the case,
then I would consider using it, since the annotation support is bound
to be extended, and might one day may be considered the default
approach.

HTH, Ted
<http://www.husted.com/ted/blog/>

On 4/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Thanks Ted.  Let us suppose for a moment there are no parameters passed
with
> the URL.  Is there an S2 pulley or chain I can tug on to bypass the
> validation?  Maybe this is not a case where I should be using a S2
tag?  It
> strikes me as odd that a hyperlink not related to the form would be
> intercepted by the form validator.  I recently discovered the Java
> annotation @SkipValidation and now wonder if there might be an
attribute,
> flag, switch, bit of XML, or interceptor stack I could massage to avoid
this
> unwanted feature.
>
> You know, this extreme flexibility reminds me of a Dilbert I saw a few
years
> back illustrating the boneless chicken ranch.  Seriously, S2 seems to
offer
> an unbounded combination of techniques for about anything you need to
do.
> Granted, I think a framework should be flexible, but as I read these
> threads, I am more confused about the most recent "best S2 technique" I
used
> yesterday!
>
> Scott
>
> On 4/5/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> >
> > A hyperlink is a get, and if coded correctly a get shouldn't have side
> > effects, and so at first blush validation might seem redundant.
> > Although, the struts controller doesn't distinguish between get and
> > post. If there is a validator associated with the course action, then
> > it would be called regardless of whether the request is coded as a
> > hyperlink or form. I note that the link takes a parameter, and if the
> > parameter is required to consummate the get, then validation would
> > seem appropriate.
> >
> > HTH, Ted
> > <http://www.husted.com/ted/blog/>
> >
> > On 4/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Should the Action class validator be getting called when a hyperlink
is
> > > clicked?  This is the behavior I am experiencing.  My hyperlink is
coded
> > as
> > > follows:
> > >
> > >                         <s:url id="url" action="course!remove">
> > >                             <s:param name="course.id">
> > >                                 <s:property value="id" />
> > >                             </s:param>
> > >                         </s:url>
> > >
> > > The hyperlink is outside the form tags!

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Scott
[EMAIL PROTECTED]

Reply via email to