Re: Action Validator ans s:url...
Anyone? Beuler? Beuler?
I'm still not seeing it, and it's going to irritate me
all weekend.
--- Dave Newton [EMAIL PROTECTED] wrote:
--- [EMAIL PROTECTED] wrote:
Actually annotations do work at the method level.
That's what I thought too :/ I must be doing
something
toopid, and I would have sworn I did this before
(but
I already made one huge mis-assumption about my
validations); hopefully it'll be obvious to a fresh
set of eyes.
-- struts.xml
struts
constant
name=struts.enable.DynamicMethodInvocation
value=true /
constant name=struts.devMode value=true /
include file=/val1/val1-struts.xml/
/struts
-- /val1/val1-struts.xml
struts
package name=val1 namespace=/val1
extends=struts-default
action name=val1 class=val1.Val1Action
result
name=input/WEB-INF/jsp/val1/val1.jsp/result
/action
action name=val2 class=val1.Val1Action
result
name=input/WEB-INF/jsp/val1/val2.jsp/result
/action
/package
/struts
-- Val1Action (minus fname/lname get/setters)
@Validation()
public class Val1Action extends ActionSupport {
@Validations(
requiredStrings = {
@RequiredStringValidator(type=ValidatorType.SIMPLE,
fieldName=fname, message=First name required)
}
)
public String req1() throws Exception {
return INPUT;
}
@Validations(
requiredStrings = {
@RequiredStringValidator(type=ValidatorType.SIMPLE,
fieldName=lname, message=Last name required)
}
)
public String req2() throws Exception {
return INPUT;
}
}
-- val1.jsp
s:form action=val1!req1 method=post
s:textfield name=fname label=First Name/
s:textfield name=lname label=Last Name/
s:submit/
/s:form
-- val2.jsp
s:form action=val2!req2 method=post
s:textfield name=fname label=First Name/
s:textfield name=lname label=Last Name/
s:submit/
/s:form
I always seem to be getting both validation errors
with several combinations of dynamic method
invocation
vs. config file method attributes etc.
(I also can't figure out why I can't set the
validateAnnotatedMethodOnly attribute of either the
XWork ValidationInterceptor or S2
AnnotationValidationInterceptor, but that's a
different issue.)
d.
Expecting? Get great news right away with email
Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
On 4/5/07, Dave Newton [EMAIL PROTECTED] wrote: Having the validation files key off of method names would be pretty handy (and avoid some extra action defs). I poked around, and it seems the design justification is to allow the methods to be validated differently in different contexts. I do see the use case for having different validation for different methods, but I don't see a case for a context beyond the method. I would think that the method is the context. If a method needs to be validated, then it needs to be validated. I'm thinking that since annotations will focus on the method name (since they do not know the action name), then we should look at supporting configuration by method name too, so that there is at least one consistent path. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
Amen! I really don't know if I have this straight or not. On 4/6/07, Ted Husted [EMAIL PROTECTED] wrote: On 4/5/07, Dave Newton [EMAIL PROTECTED] wrote: Having the validation files key off of method names would be pretty handy (and avoid some extra action defs). I poked around, and it seems the design justification is to allow the methods to be validated differently in different contexts. I do see the use case for having different validation for different methods, but I don't see a case for a context beyond the method. I would think that the method is the context. If a method needs to be validated, then it needs to be validated. I'm thinking that since annotations will focus on the method name (since they do not know the action name), then we should look at supporting configuration by method name too, so that there is at least one consistent path. :) -Ted. - 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]
Re: Action Validator ans s:url...
--- Ted Husted [EMAIL PROTECTED] wrote: but I don't see a case for a context beyond the method. I would think that the method is the context. If a method needs to be validated, then it needs to be validated. That was more or less my thought, perhaps not quite as well-stated ;) then we should look at supporting configuration by method name too, so that there is at least one consistent path. :) Sounds good to me! OT, got some interesting S2 feedback today from someone who had used GWT on their last project--I'll try to write it up sometime, although what I mostly got from it was that they found it more verbose than GWT (they also came from a Swing background, which would make a difference). It was an interesting conversation (big financial client) but they are focusing on S2 right now. d. Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
Does anybody know what is the status of that JSR? musachy On 4/5/07, Ted Husted [EMAIL PROTECTED] wrote: On 4/5/07, Dave Newton [EMAIL PROTECTED] wrote: Turns out the annotations are class-based as well (again, I had just been lucky so far)... If the validation files were based off of method names the annotations could be as well, which would be a nice, unified view of things, IMO. The validation comes out of XWork, so we'd have to file a ticket over there. I've never looked at that part of the code, so I don't know what's involved. There's also the who JSR 303 thing, but I have no idea how that's going. * http://jcp.org/en/jsr/detail?id=303 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Action Validator ans s:url...
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! -- Scott [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott [EMAIL PROTECTED]
Re: Action Validator ans s:url...
--- [EMAIL PROTECTED] wrote: It strikes me as odd that a hyperlink not related to the form would be intercepted by the form validator. Meh; if an action is Validatable then it's Validatable, you know? I have to agree with Ted--if you're passing a parameter that's being used by the method, why *wouldn't* you want to validate it? That said, the validation interceptor is a subclass of MethodFilterInterceptor so you can configure it with an excludeMethods parameter as described on the validation interceptor wiki page: http://struts.apache.org/2.x/docs/validation-interceptor.html You could probably also create a class-method-validation.xml file that would do something different for just that method. d. Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
Maybe you missed the part about *not* passing a parameter with the link url? I am experimenting with a few ideas to minimize writing too many Action classes by leveraging the wildcard method feature. This link allows an item to be deleted and the parameter being passed is a read-only hibernate id that was loaded into the page during the request. There is no need for validating this sort of link. I suppose I can write another Action just for this method, but this is precisely what I am trying to avoid. Also, I'd rather not override framework plumbing to solve this trivial scenario. The immediate solution looks like replacing the S2 tags which are seemingly at the heart of S2! On 4/5/07, Dave Newton [EMAIL PROTECTED] wrote: --- [EMAIL PROTECTED] wrote: It strikes me as odd that a hyperlink not related to the form would be intercepted by the form validator. Meh; if an action is Validatable then it's Validatable, you know? I have to agree with Ted--if you're passing a parameter that's being used by the method, why *wouldn't* you want to validate it? That said, the validation interceptor is a subclass of MethodFilterInterceptor so you can configure it with an excludeMethods parameter as described on the validation interceptor wiki page: http://struts.apache.org/2.x/docs/validation-interceptor.html You could probably also create a class-method-validation.xml file that would do something different for just that method. d. Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott [EMAIL PROTECTED]
Re: Action Validator ans s:url...
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=excludeMethodsinput,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]
Re: Action Validator ans s:url...
--- [EMAIL PROTECTED] wrote: Maybe you missed the part about *not* passing a parameter with the link url? Maybe I was answering your *first* question? This link allows an item to be deleted and the parameter being passed is a read-only hibernate id that was loaded into the page during the request. There is no need for validating this sort of link. Besides the issues with exposing such functionality as a plain link (**bad** idea), I'll generally still validate such things, because people can pass in whatever they want, not just what *you* present them as a link. If I specifically *didn't* want to validate it for some reason, I'd just create a different validation config via file or, most likely, annotations. The immediate solution looks like replacing the S2 tags which are seemingly at the heart of S2! I'm not sure what the tags have to do with this usecase? The tags don't have anything to do with the validation functionality. d. Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
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=excludeMethodsinput,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]
Re: Action Validator ans s:url...
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=excludeMethodsinput,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]
Re: Action Validator ans s:url...
--- Ted Husted [EMAIL PROTECTED] wrote: Note that it is the action name not the method name. (Though, I often wonder if the method name would make more sense.) Sakes alive, really?! Hmm, I wonder if I've just been naming things luckily up 'til now--I may have to rename some validation files, although up until now I haven't had any issues. I think for *sure* the method name would make more sense; that's even what I thought it *was*!!! Is that on the validation wiki page? d. Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
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=excludeMethodsinput,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! -
Re: Action Validator ans s:url...
--- Ted Husted [EMAIL PROTECTED] wrote: Note that it is the action name not the method name. (Though, I often wonder if the method name would make more sense.) Apparently I've just been lucky (and had fewer method-specific validations than I thought :/ so far. Having the validation files key off of method names would be pretty handy (and avoid some extra action defs). Turns out the annotations are class-based as well (again, I had just been lucky so far)... If the validation files were based off of method names the annotations could be as well, which would be a nice, unified view of things, IMO. Thanks, Dave Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
On 4/5/07, Dave Newton [EMAIL PROTECTED] wrote: Turns out the annotations are class-based as well (again, I had just been lucky so far)... If the validation files were based off of method names the annotations could be as well, which would be a nice, unified view of things, IMO. The validation comes out of XWork, so we'd have to file a ticket over there. I've never looked at that part of the code, so I don't know what's involved. There's also the who JSR 303 thing, but I have no idea how that's going. * http://jcp.org/en/jsr/detail?id=303 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
--- Ted Husted [EMAIL PROTECTED] wrote: The validation comes out of XWork, so we'd have to file a ticket over there. My guess is that it wouldn't be worth it; it's easy enough to see the need for the existing way of doing it and it's not *that* much more work. I guess. :/ If anybody else chimes in and thinks it's a reasonable idea I'll throw the idea XWork's way. I haven't heard anything about JSR 303 for awhile now and I was never sure if it allowed for validation based on anything except the bean itself, which I've never been a huge fan of (I always used [Dyna]ValidatorActionForms :) Thanks, Dave TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action Validator ans s:url...
Actually annotations do work at the method level. On 4/5/07, Dave Newton [EMAIL PROTECTED] wrote: --- Ted Husted [EMAIL PROTECTED] wrote: Note that it is the action name not the method name. (Though, I often wonder if the method name would make more sense.) Apparently I've just been lucky (and had fewer method-specific validations than I thought :/ so far. Having the validation files key off of method names would be pretty handy (and avoid some extra action defs). Turns out the annotations are class-based as well (again, I had just been lucky so far)... If the validation files were based off of method names the annotations could be as well, which would be a nice, unified view of things, IMO. Thanks, Dave Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - 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]
Re: Action Validator ans s:url...
--- [EMAIL PROTECTED] wrote:
Actually annotations do work at the method level.
That's what I thought too :/ I must be doing something
toopid, and I would have sworn I did this before (but
I already made one huge mis-assumption about my
validations); hopefully it'll be obvious to a fresh
set of eyes.
-- struts.xml
struts
constant
name=struts.enable.DynamicMethodInvocation
value=true /
constant name=struts.devMode value=true /
include file=/val1/val1-struts.xml/
/struts
-- /val1/val1-struts.xml
struts
package name=val1 namespace=/val1
extends=struts-default
action name=val1 class=val1.Val1Action
result
name=input/WEB-INF/jsp/val1/val1.jsp/result
/action
action name=val2 class=val1.Val1Action
result
name=input/WEB-INF/jsp/val1/val2.jsp/result
/action
/package
/struts
-- Val1Action (minus fname/lname get/setters)
@Validation()
public class Val1Action extends ActionSupport {
@Validations(
requiredStrings = {
@RequiredStringValidator(type=ValidatorType.SIMPLE,
fieldName=fname, message=First name required)
}
)
public String req1() throws Exception {
return INPUT;
}
@Validations(
requiredStrings = {
@RequiredStringValidator(type=ValidatorType.SIMPLE,
fieldName=lname, message=Last name required)
}
)
public String req2() throws Exception {
return INPUT;
}
}
-- val1.jsp
s:form action=val1!req1 method=post
s:textfield name=fname label=First Name/
s:textfield name=lname label=Last Name/
s:submit/
/s:form
-- val2.jsp
s:form action=val2!req2 method=post
s:textfield name=fname label=First Name/
s:textfield name=lname label=Last Name/
s:submit/
/s:form
I always seem to be getting both validation errors
with several combinations of dynamic method invocation
vs. config file method attributes etc.
(I also can't figure out why I can't set the
validateAnnotatedMethodOnly attribute of either the
XWork ValidationInterceptor or S2
AnnotationValidationInterceptor, but that's a
different issue.)
d.
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
