The point of having extensible, open-ended interceptor and configuration mechanisms is precisely so we *can* extend it to meet application needs, without having to modify the framework itself.
The framework provides the hooks, through interceptors and plugins, precisely for circumstances unforeseen by the original developers. Don't underestimate the malleability of Struts 2 at the user layer. d. On Nov 28, 2011 9:16 PM, "Li Ying" <liying.cn.2...@gmail.com> wrote: > Yes, of course you are right. > > But what you talking about sounds like to change S2 mechanism itself, > which we can not do. > As a S2 user but not a S2 developer, the simplest way is to write a > new validator...... > > Of course, If the [pre-condition based validation] is a common > request, I think it will be great if we post it to the S2 feature > request list. > > 2011/11/29 Dave Newton <davelnew...@gmail.com>: > > If the need is across the application, then modifying the app-wide > > interceptor makes sense. > > > > App-wide rule-based validations require something higher-level than > > reworking existing validators, or writing new ones, to express something > > that is likely declarative in nature. Seems more like "run this bunch of > > validations based on this condition"--rather than simply look up > > validations based on the action name, lookup should be based on the > > condition(s). > > > > That's mechanism-level, not validate-level. > > > > d. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
