Ted -- I think the method name "validation naming" would be more intuitive.
Thanks, Scott On 4/5/07, Ted Husted <[EMAIL PROTECTED]> wrote:
The WebWork "bang" notation for calling methods doesn't support per-method validations. However, the Struts-style wildcards do support per-method validations. Validations can be specified just as if the method name had been hardcoded in the configuration. The syntax is "ActionClass-actionName-validation.xml. In the case of a create method of a Course class that was invoked with the name Course!create.action, the validation configuration would be Course-Course!create-validation.xml. Note that it is the action name not the method name. (Though, I often wonder if the method name would make more sense.) The MailReader application for Struts 2 uses wildcards as well as per-method validation. HTH, Ted <http://www.husted.com/ted/blog/> On 4/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Scott [EMAIL PROTECTED]
