Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ * [jcarreira] You had me until the abstract class bit... Does it have to be abstract? Also, this limits testability in not-ok-ways... * [crazybob] It only has to be abstract if you want your action to be able to call methods on the mixin without casting. If it doesn't need to call those methods, there's no need for your action to explicitly implement that interface. You could also say `((ValidationAware) this).addActionError()`. I personally don't mind making the action abstract. In IntelliJ, you just make a mock class that extends your action and it will automatically generate stubs for the methods. * [plightbo] As mentioned earlier, you might be able to do this by using the value stack. For example, you could stick in a single "ValidationSupport" object at the bottom of the stack and then all classes would add error messages there. By adding a simple *Aware interface, actions could get a handle to that for adding error messages. - - * [jcarreira] Very nice idea... +1 ... We already do something like that. There's always a default TextProvider pushed onto the bottom of the stack for getting default texts... makes localized texts work with Sitemesh, for instance, when you're not hitting an action. Of course, that will be a problem when we're not using ThreadLocals. + * [jcarreira] Very nice idea... +1 ... We already do something like that. There's always a default TextProvider pushed onto the bottom of the stack for getting default texts... makes localized texts work with Sitemesh, for instance, when you're not hitting an action. Of course, that will be a problem when we're not using ThreadLocals. + * [tm_jee] What about keeping ActionSupport but instead have an AbstractActionSupport which ActionSupport extends off which consisting of getter/setters for the plugable strategy (like setValidatable(...) setValidationAware(...) setTextProvider(...) etc). There will be a default for those if none is set. We could then wired them in through Spring since Sprinc is now the recommended IOC container. + 1. [molitor]Extends support on actions in xml (Configuration Inheritance). Occasionally I want to utilize an existing action but only change one parameter. It would be nice to do something as simple as.{{{<action name="addPerson" class="com.opensymphony.webwork.showcase.person.AddPerson" > <interceptor-ref name="validationStack"/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
