Re: Struts 3 request/response processing

[Ken McWilliams <ke...@gmail.com>]

@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 <vo...@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 <da...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Struts 3 request/response processing

[Lukasz Lenart <lu...@apache.org>]

I thought a bit about that idea and still have some doubts. If we move
the whole processing into interceptors we will end up with "system"
interceptors that must run on the beginning and with "user"
related/developed interceptors. And either we allow create custom
stacks and mix the "system" interceptors with the "user" interceptors
(user will be able to create stack without the "system" interceptors)
or we will have to fasten the "system" interceptors to be always run
and allow user only play with the "user" interceptors.

Basically I like the idea with moving as much as possible "system"
logic into interceptors - this allows users change flow whenever they
want. But to do it and not to create monsters like
ParametersInterceptor we must introduce some kind of an interceptor
inner dependency flow - I mean interceptors can define
pre/post-conditions for other interceptors (ie. cannot run
ParametersInterceptor if SanityCheckInterceptor wasn't executed and so
on). It can be as simple as defining what interceptor names were
already processed.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org