Ken, I am in agreement interceptor stacks should be something like templates. I think we need to do something that's a mix of JSF and S1. JSF has a predefined lifecycle and S1 had named commands (its version of interceptors). So if you want to inject something before or after a step in the lifecycle, it needs to be named. Many times, for example, I just wanted to replace one part of the interceptor stack without creating a new interceptor stack. That's the kind of functionality I am desiring.
Cheers, Paul On Tue, Dec 9, 2014 at 4:19 PM, Ken McWilliams <ken.mcwilli...@gmail.com> wrote: > > Interceptor stacks don't translate well with annotations (the struts2 > package-name and action-name are required by the action-mapper to kick off > the processing, two keys are a pretty minimal requirement). It only makes > sense to use Struts2 package annotations as Java package-level annotations. > But then if the annotations were used that way (which as far as I know they > are not), you would get the worst of both worlds. You would have > annotations but they would not be on the action so you would need to look > elsewhere but unlike struts.xml it would be split-up into different files > (package-info.java) but where struts.xml will explicitly state what other > files are involved in the config you would have to hunt and peck for the > package meta-data. > > At the end of the day, for interceptor definition struts.xml is the most > ideal. If annotations are being used conventions are probably at play, and > annotations should then be used for what they are intended for: overriding > the conventions, and in general shouldn't be something you do on every > action, otherwise the default conventions behaviour should be altered for > your case. > > There of course is room for improvement, perhaps considering > interceptor-stacks something like templates? That is parts of templates can > be changed out, without needing a full redefinition. > > On Tue, Dec 9, 2014 at 2:14 PM, Paul Benedict <pbened...@apache.org> > wrote: > > > I hear your points. > > > > In addition, I noticed that namespaces don't translate well with > > annotations. It might just be more consistent to configure on a per > action > > basis just by specifying the interceptor stack to use. > > > > Also, I find namespaces most frustrating when I rename URLs and have to > > move around the config to put the XML action configs in the right > > namespaces. > > On Dec 9, 2014 2:57 PM, "Dave Newton" <davelnew...@gmail.com> wrote: > > > > > I used package-level interceptors from time to time, mostly for really > > easy > > > auth interceptors applied to chunks of pages. There was some other > > use-case > > > I had, but I can't recall what it was; it was related to some data > > > transformations. > > > > > > It also provides a mechanism for grouping actions together in a logical > > way > > > w/o having to rely on consistent URL naming convention that can be > > > fat-fingered pretty easily, but I'm not sure that counts as "really > > > valuable". > > > > > > On Tue, Dec 9, 2014 at 3:52 PM, Paul Benedict <pbened...@apache.org> > > > wrote: > > > > > > > One concept I never really liked in S2 are namespaces. I never found > a > > > good > > > > reason to logically group actions together with common interceptor > > setup. > > > > Rather I always find myself in the situation where the interceptor > > stack > > > is > > > > globally set and actions have one-off changes. And I also never liked > > how > > > > namespaces limit the scope of result types. > > > > > > > > Am I right or is this feature really valuable? > > > > > > > > > > > > > > > > -- > > > e: davelnew...@gmail.com > > > m: 908-380-8699 > > > s: davelnewton_skype > > > t: @dave_newton <https://twitter.com/dave_newton> > > > b: Bucky Bits <http://buckybits.blogspot.com/> > > > g: davelnewton <https://github.com/davelnewton> > > > so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton> > > > > > >
