@Steven, David: The use case it to be more dynamic. As per Volker, the use of regex within the interceptor stack to determine the mapping would be quite nice. What is being done with the regex is creating a custom convention within that package. It would be more ideal if logic from the struts2-conventions-plugin was made more central. It would be nice if you could add or remove conventions by adding a conventions-interceptor (interceptor which can modify the conventions behaviour on a package by package basis, possibly assuming a different result type, or possibly assuming a different conventions for how to reach the result type). Conventions of course should still be applied globally, but this would allow overrides. Certainly the conventions plugin could be improved but making it more central, would make that effort simpler.
So it isn't just the ActionMapping but all the actions configuration should be alterable at run-time, conveniently from within the interceptor (well you would use ActionInvocation or whatnot but it should be readily possible and documented). A use-case I would like to see which would likely come from such an extension, is the ability to query the execution state. For instance you could say: Given namespace X and action Y with the following parameters, what is the state and configuration before the first interceptor fires? After the fist interceptor? After the second interceptor? Etcetera. Such query functionality would need to be built into the ActionInvocation whereby an external Action could request an invocation (execute another action) and ask it to gather state at each step of the chain then provide that meta-data back to the user. This would be an enormous help when debugging. The config-browser-plugin could be readily improved to now be able to determine what action will actually be run even if the action is using a regex or conventions, both are currently popular and throw a wrench into using this for debugging. Another feature, in the name of flexibility is that even interceptors, stacks, and actions be definable/loadable/and removable at run time. The use-case for this is quite significant, with this foundation it would be possible for Struts2 to build a web based IDE for itself. Such a project is beyond the scope of a web framework, but allowing for such a foundation and functionality isn't unreasonable. Also it would be easier to load configuration from other sources (currently loading and building struts2 configuration is a bit tricky, few people seem to know how to do this). With the ability to dynamically create configuration, it is a given that it would need to be persisted and restored, but this too opens up a large number of possibilities (Write JavaScript in a web based editor, persist it to the DB and use that for the Action). I was a bit hesitant to write this. I really like to help out on StackOverflow, when I can, with Struts2 related questions. I know this isn't what the typical Struts2 user is looking for, because that is not what Struts2 does. But if it could do it... I'm sure this would open a world of possibilities. It should also be possible to retain backwards compatibility while doing so. I can't see why it would be impossible, and it can offer revolutionary change and gain. Improving the DI would make the internals nicer, abstracting the request/response with a nice wrapper such as the Tiles Request API would too (the later would allowing struts actions use to be used outside of a servlet environment, and reduce friction between different web frameworks which often try to provide their own request wrapper). These would be nice things and would certainly improve struts internals but embracing dynamism, that could really neat. On Wed, Nov 26, 2014 at 1:37 AM, Volker Krebs <volker.kr...@abas.de> wrote: > Sounds good. A series of interceptors that handle action mapping. > So when I'm not using wildcard or regex matchers I simply remove the > corresponding interceptors from the chain. > > ,Volker > > > > Am 25.11.2014 um 21:40 schrieb Paul Benedict: > > Responding to both you and Steven: >> >> Yes, the ActionMapper does select the action and method. My apologies for >> phrasing my question as I did. Yet where in the interceptor chain is the >> ActionMapper invoked? Or invoking the action? I think it's part of our >> hidden stock functionality which means I can't easily stub in code before >> or after or replace. That's really my point in all this: to fully break >> down the controller into a series of interceptors so developers can >> enhance >> the processing chain in the guts of Struts. >> >> >> >> >> >> Cheers, >> Paul >> >> On Tue, Nov 25, 2014 at 2:22 PM, Dave Newton <davelnew...@gmail.com> >> wrote: >> >> On Tue, Nov 25, 2014 at 10:24 AM, Paul Benedict wrote: >>> >>>> For example, there is no easy way in S2 to customize which action will >>>> be >>>> selected -- or which method on the action will be invoked. >>>> >>> >>> Customize in what way? >>> >>> Wouldn't most situations be covered by either wildcarding or regex >>> matchers? >>> >>> Dave >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
