You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ted Husted <hu...@apache.org> on 2006/07/24 16:22:59 UTC
[s2] Re: What's the future of Action, events / dispatching and CoC/CoR
On 7/23/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> - dependency injection by Spring for my services / delegates (/ daos)
S2 uses Spring as its default object factory, and Action properties
can be injected from Spring by matching the property name with the
object factory ID.
> - replacing all the struts parameters to my methods with a context object
S2 uses a content object internally, so that seems in line.
> - an exception handling switch
Like S1, S2 includes a declarative exception handler.
> - a mechanism for handling 'on-the-fly' URL & query strings for actionForwards
Like S1, S2 lets you specify a "default" action to use when nothing
else matches. Wildcards are also supported.
> I expect this won't take me too long to achieve (a day or two) but I would still like to >'future-proof' what I write - or should I say, 'future-orientate', since experience tells me that
>most 'future-proofing' underestimates the wild changes that the
future may bring.
>
> Can anyone involved in struts 2 tell me about potential brick walls that this sort of Action
>base class and its children would be heading into? I checked out the
dev list for hints and
>saw oblique references to Chain of Commands but couldn't guage much
from the threads
> there.
S2 doesn't use Commons Chain internally. S2 relies on the notion of
"interceptors" to do what we did in S1 with the Chain of Commands.
Essentially, interceptors are POJO filters that let us run custom code
before and after a key event, like invoking an Action class.
The package that delivers the interceptor mechanism is XWork. XWork
also handles matcing things like URIs to action mappings and it
provides the base validation framework. Surprisingly little is
actually in Struts 2 itself. Most of the functionality derives from
XWork, which is web-neutral. XWork is already being used to power
other frameworks.
If I had understood interceptors and XWork better when we were
creating Commons Chain, I would have pushed harder for us to use XWork
in 1.3 instead of Commons Chain. Jason tried to explain it to me once,
but it didn't click. I in turn mentioned using XWork with Struts to
Don Brown, which became the nexus of TI, which evolved into the
merger.
>
> Regards
> Adam
-- HTH, Ted.
* http://www.husted.com/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] IoC containers (was: What's the future of Action, events / dispatching and CoC/CoR)
Posted by Ted Husted <hu...@apache.org>.
On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Webworks supports (or used to) several IOC containers. In fact, on my previous
> project we used a singleton component factory that hid Spring and the intent was
> to keep all Spring code isolated behind this. Is S2 going to take this route, or
> is Spring strongly tied in?
The strategy is unchanged from WebWork 2.2. You can plug in another
IoC container, if you like, and the IoC plumbing is hidden from the
application developer. If you are using Spring, the Spring support is
seamless.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] IoC containers (was: What's the future of Action, events
/ dispatching and CoC/CoR)
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Ted Husted on 24/07/06 15:22, wrote:
> On 7/23/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>> - dependency injection by Spring for my services / delegates (/ daos)
>
> S2 uses Spring as its default object factory, and Action properties
> can be injected from Spring by matching the property name with the
> object factory ID.
Webworks supports (or used to) several IOC containers. In fact, on my previous
project we used a singleton component factory that hid Spring and the intent was
to keep all Spring code isolated behind this. Is S2 going to take this route, or
is Spring strongly tied in?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
IoC/CoR
Posted by Duong BaTien <du...@gmail.com>.
Hello Ted:
What you describe is interesting. I do not have time in the next couple
of weeks. But please post on this list when you have something concrete
about XWork "interceptors" in the nexus. (i change the subject from
CoC/CoR to IoC/CoR. Correct me if i am wrong).
BaTien
On Mon, 2006-07-24 at 10:22 -0400, Ted Husted wrote:
> On 7/23/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> > - dependency injection by Spring for my services / delegates (/ daos)
>
> S2 uses Spring as its default object factory, and Action properties
> can be injected from Spring by matching the property name with the
> object factory ID.
>
>
> > - replacing all the struts parameters to my methods with a context object
>
> S2 uses a content object internally, so that seems in line.
>
>
> > - an exception handling switch
>
> Like S1, S2 includes a declarative exception handler.
>
>
> > - a mechanism for handling 'on-the-fly' URL & query strings for actionForwards
>
> Like S1, S2 lets you specify a "default" action to use when nothing
> else matches. Wildcards are also supported.
>
>
> > I expect this won't take me too long to achieve (a day or two) but I would still like to >'future-proof' what I write - or should I say, 'future-orientate', since experience tells me that
> >most 'future-proofing' underestimates the wild changes that the
> future may bring.
> >
> > Can anyone involved in struts 2 tell me about potential brick walls that this sort of Action
> >base class and its children would be heading into? I checked out the
> dev list for hints and
> >saw oblique references to Chain of Commands but couldn't guage much
> from the threads
> > there.
>
> S2 doesn't use Commons Chain internally. S2 relies on the notion of
> "interceptors" to do what we did in S1 with the Chain of Commands.
> Essentially, interceptors are POJO filters that let us run custom code
> before and after a key event, like invoking an Action class.
>
> The package that delivers the interceptor mechanism is XWork. XWork
> also handles matcing things like URIs to action mappings and it
> provides the base validation framework. Surprisingly little is
> actually in Struts 2 itself. Most of the functionality derives from
> XWork, which is web-neutral. XWork is already being used to power
> other frameworks.
>
> If I had understood interceptors and XWork better when we were
> creating Commons Chain, I would have pushed harder for us to use XWork
> in 1.3 instead of Commons Chain. Jason tried to explain it to me once,
> but it didn't click. I in turn mentioned using XWork with Struts to
> Don Brown, which became the nexus of TI, which evolved into the
> merger.
>
> >
> > Regards
> > Adam
>
> -- HTH, Ted.
> * http://www.husted.com/struts/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] on-the-fly actionForwards (was: What's the future of Action, events / dispatching and CoC/CoR)
Posted by Ted Husted <hu...@apache.org>.
In S2, the equivalent of ActionForwards are Results. S2 Results are
intended to be extensible objects, and I expect you would move this
code to a custom Result (where it belongs), rather than have it spill
over into the Action.
-Ted.
On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Ted Husted on 24/07/06 15:22, wrote:
> > On 7/23/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> >> - a mechanism for handling 'on-the-fly' URL & query strings for
> >> actionForwards
> >
> > Like S1, S2 lets you specify a "default" action to use when nothing
> > else matches. Wildcards are also supported.
>
> I think I am not hitting the mark here. My BaseAction receives an ActionForward
> name (not object) back from the child action. Before my BaseAction pulls that
> named actionForward out of the actionMapping, it checks whether the name of the
> actionForward I want equals CUSTOM_FORWARD, a constant.
>
> In that case I then look for CUSTOM_URL and CUSTOM_QUERY_STRING in the request
> attributes and build a new actionForward from scratch.
>
> This however is merely bells and whistles, I only mention it because I
> occasionally but not infrequently see people asking how to do it. I thought
> there might be a place in the request-processing lifecycle for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] on-the-fly actionForwards (was: What's the future of Action,
events / dispatching and CoC/CoR)
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Ted Husted on 24/07/06 15:22, wrote:
> On 7/23/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>> - a mechanism for handling 'on-the-fly' URL & query strings for
>> actionForwards
>
> Like S1, S2 lets you specify a "default" action to use when nothing
> else matches. Wildcards are also supported.
I think I am not hitting the mark here. My BaseAction receives an ActionForward
name (not object) back from the child action. Before my BaseAction pulls that
named actionForward out of the actionMapping, it checks whether the name of the
actionForward I want equals CUSTOM_FORWARD, a constant.
In that case I then look for CUSTOM_URL and CUSTOM_QUERY_STRING in the request
attributes and build a new actionForward from scratch.
This however is merely bells and whistles, I only mention it because I
occasionally but not infrequently see people asking how to do it. I thought
there might be a place in the request-processing lifecycle for it.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
CoC/CoR
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
If you look at the number of people using struts, 20% of them is still very
many. Using interceptors is not rocket science either.
Of course I can see why <interceptor-ref> will be valuable for its
descriptiveness, but good documentation would be too, and 'syntactical
sweetness' would appeal to all those who prefer to see a nicely curved engine
cover than a mass of tubing, electrics and cylinder head! (The majority, surely?)
Regards
Adams
Don Brown on 25/07/06 00:34, wrote:
> A quick word about interceptors. The purpose of Interceptors is to
> allow you greater control over the controller layer, specifically
> common logic that applies to multiple actions.
>
> 80% of applications shouldn't need to define their own interceptors,
> as the default stack should do what you need. Think of the default
> interceptor stack as the Struts RequestProcessor. Most Struts
> applications have no need to define their own request processor.
>
> Of the remaining 20%, I'd guess 80% or so of those applications need
> to define specific interceptors for specific actions. Most of the
> time, you can define an application-specific application, place that
> interceptor in a new default stack, then have that stack the default
> for all your packages.
>
> Therefore, only a small percentange really need the ability to define
> interceptors at the action mapping level. If you find yourself using
> the interceptor-ref element a lot, ensure that you couldn't avoid that
> by setting a default interceptor stack for the package, or even if you
> need a custom interceptor stack at all. If you find yourself really
> needing the advanced use of interceptors, the name 'interceptor-ref'
> will be valuable as it signifies an interceptor defined elsewhere that
> you are referencing.
>
> Don
>
> On 7/24/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> interceptor-element?
>>
>> Ted Husted wrote:
>> > On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>> >> Guessing how busy you are, you may not be interested, but I think it's
>> >> pretty
>> >> obvious that the more user-friendly a name is, the more it will be
>> >> used by the
>> >> community.
>> >>
>> >> Interceptor-ref probably describes exactly what it is in framework
>> >> architecture
>> >> terms, but something like 'goal', 'phase', 'execution' or 'command'
>> will
>> >> undoubtedly be alot better received. (I grabbed those from the maven
>> >> vocab, in
>> >> case you didn't notice).
>> >
>> > The obvious name is interceptor-stack, but the DTD uses that for
>> > another purpose. The interceptor-ref can be a single interceptor,
>> > another interceptor-ref, or any combination of the two (e.g., a
>> > composite). It's role in the framework is to create what Struts 1
>> > calls the "request processor" or "controller". In Struts 1.3, the
>> > request processor is a chain of commands, and, so, conceptually very
>> > close to an interceptor stack.
>> >
>> > A syntatically sweet name might be "controller", but since it's
>> > implemented as a composite of interceptor stack, that name would mask
>> > what it is doing, and probably make it harder to use.
>> >
>> > <interceptor-stack-composite> might be the most descriptive, but it's
>> > a lot to type, and the DTD is designed to be keyboard friendly.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
Posted by Ted Husted <hu...@apache.org>.
On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> <interceptor-ref> is /so/ ugly.
If that's the worst complaint anyone has about S2, I'll be a very
happy camper. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
CoC/CoR
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Sorry Don, it's getting late and I dashed off that last answer before I
understood what you'd written :O
I realised while brushing my teeth, it should be possible, instead of
<interceptor-ref> to have something like
<interceptor ref="">
or
<interceptor>
<ref>
<interceptor-ref> is /so/ ugly.
Don Brown on 25/07/06 00:34, wrote:
> A quick word about interceptors. The purpose of Interceptors is to
> allow you greater control over the controller layer, specifically
> common logic that applies to multiple actions.
>
> 80% of applications shouldn't need to define their own interceptors,
> as the default stack should do what you need. Think of the default
> interceptor stack as the Struts RequestProcessor. Most Struts
> applications have no need to define their own request processor.
>
> Of the remaining 20%, I'd guess 80% or so of those applications need
> to define specific interceptors for specific actions. Most of the
> time, you can define an application-specific application, place that
> interceptor in a new default stack, then have that stack the default
> for all your packages.
>
> Therefore, only a small percentange really need the ability to define
> interceptors at the action mapping level. If you find yourself using
> the interceptor-ref element a lot, ensure that you couldn't avoid that
> by setting a default interceptor stack for the package, or even if you
> need a custom interceptor stack at all. If you find yourself really
> needing the advanced use of interceptors, the name 'interceptor-ref'
> will be valuable as it signifies an interceptor defined elsewhere that
> you are referencing.
>
> Don
>
> On 7/24/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> interceptor-element?
>>
>> Ted Husted wrote:
>> > On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>> >> Guessing how busy you are, you may not be interested, but I think it's
>> >> pretty
>> >> obvious that the more user-friendly a name is, the more it will be
>> >> used by the
>> >> community.
>> >>
>> >> Interceptor-ref probably describes exactly what it is in framework
>> >> architecture
>> >> terms, but something like 'goal', 'phase', 'execution' or 'command'
>> will
>> >> undoubtedly be alot better received. (I grabbed those from the maven
>> >> vocab, in
>> >> case you didn't notice).
>> >
>> > The obvious name is interceptor-stack, but the DTD uses that for
>> > another purpose. The interceptor-ref can be a single interceptor,
>> > another interceptor-ref, or any combination of the two (e.g., a
>> > composite). It's role in the framework is to create what Struts 1
>> > calls the "request processor" or "controller". In Struts 1.3, the
>> > request processor is a chain of commands, and, so, conceptually very
>> > close to an interceptor stack.
>> >
>> > A syntatically sweet name might be "controller", but since it's
>> > implemented as a composite of interceptor stack, that name would mask
>> > what it is doing, and probably make it harder to use.
>> >
>> > <interceptor-stack-composite> might be the most descriptive, but it's
>> > a lot to type, and the DTD is designed to be keyboard friendly.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
Posted by Don Brown <do...@gmail.com>.
A quick word about interceptors. The purpose of Interceptors is to
allow you greater control over the controller layer, specifically
common logic that applies to multiple actions.
80% of applications shouldn't need to define their own interceptors,
as the default stack should do what you need. Think of the default
interceptor stack as the Struts RequestProcessor. Most Struts
applications have no need to define their own request processor.
Of the remaining 20%, I'd guess 80% or so of those applications need
to define specific interceptors for specific actions. Most of the
time, you can define an application-specific application, place that
interceptor in a new default stack, then have that stack the default
for all your packages.
Therefore, only a small percentange really need the ability to define
interceptors at the action mapping level. If you find yourself using
the interceptor-ref element a lot, ensure that you couldn't avoid that
by setting a default interceptor stack for the package, or even if you
need a custom interceptor stack at all. If you find yourself really
needing the advanced use of interceptors, the name 'interceptor-ref'
will be valuable as it signifies an interceptor defined elsewhere that
you are referencing.
Don
On 7/24/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> interceptor-element?
>
> Ted Husted wrote:
> > On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> >> Guessing how busy you are, you may not be interested, but I think it's
> >> pretty
> >> obvious that the more user-friendly a name is, the more it will be
> >> used by the
> >> community.
> >>
> >> Interceptor-ref probably describes exactly what it is in framework
> >> architecture
> >> terms, but something like 'goal', 'phase', 'execution' or 'command' will
> >> undoubtedly be alot better received. (I grabbed those from the maven
> >> vocab, in
> >> case you didn't notice).
> >
> > The obvious name is interceptor-stack, but the DTD uses that for
> > another purpose. The interceptor-ref can be a single interceptor,
> > another interceptor-ref, or any combination of the two (e.g., a
> > composite). It's role in the framework is to create what Struts 1
> > calls the "request processor" or "controller". In Struts 1.3, the
> > request processor is a chain of commands, and, so, conceptually very
> > close to an interceptor stack.
> >
> > A syntatically sweet name might be "controller", but since it's
> > implemented as a composite of interceptor stack, that name would mask
> > what it is doing, and probably make it harder to use.
> >
> > <interceptor-stack-composite> might be the most descriptive, but it's
> > a lot to type, and the DTD is designed to be keyboard friendly.
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
CoC/CoR
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
interceptor-element?
Ted Husted wrote:
> On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>> Guessing how busy you are, you may not be interested, but I think it's
>> pretty
>> obvious that the more user-friendly a name is, the more it will be
>> used by the
>> community.
>>
>> Interceptor-ref probably describes exactly what it is in framework
>> architecture
>> terms, but something like 'goal', 'phase', 'execution' or 'command' will
>> undoubtedly be alot better received. (I grabbed those from the maven
>> vocab, in
>> case you didn't notice).
>
> The obvious name is interceptor-stack, but the DTD uses that for
> another purpose. The interceptor-ref can be a single interceptor,
> another interceptor-ref, or any combination of the two (e.g., a
> composite). It's role in the framework is to create what Struts 1
> calls the "request processor" or "controller". In Struts 1.3, the
> request processor is a chain of commands, and, so, conceptually very
> close to an interceptor stack.
>
> A syntatically sweet name might be "controller", but since it's
> implemented as a composite of interceptor stack, that name would mask
> what it is doing, and probably make it harder to use.
>
> <interceptor-stack-composite> might be the most descriptive, but it's
> a lot to type, and the DTD is designed to be keyboard friendly.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
Posted by Ted Husted <hu...@apache.org>.
On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Guessing how busy you are, you may not be interested, but I think it's pretty
> obvious that the more user-friendly a name is, the more it will be used by the
> community.
>
> Interceptor-ref probably describes exactly what it is in framework architecture
> terms, but something like 'goal', 'phase', 'execution' or 'command' will
> undoubtedly be alot better received. (I grabbed those from the maven vocab, in
> case you didn't notice).
The obvious name is interceptor-stack, but the DTD uses that for
another purpose. The interceptor-ref can be a single interceptor,
another interceptor-ref, or any combination of the two (e.g., a
composite). It's role in the framework is to create what Struts 1
calls the "request processor" or "controller". In Struts 1.3, the
request processor is a chain of commands, and, so, conceptually very
close to an interceptor stack.
A syntatically sweet name might be "controller", but since it's
implemented as a composite of interceptor stack, that name would mask
what it is doing, and probably make it harder to use.
<interceptor-stack-composite> might be the most descriptive, but it's
a lot to type, and the DTD is designed to be keyboard friendly.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
CoC/CoR
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Ted Husted on 24/07/06 21:59, wrote:
> On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>> It all looks very interesting. I just read some stuff on the xworks
>> opensymphony site and it looks pretty sound [1] and [2]. You guys must be
>> working like dogs, there seems to be so much there to integrate. Kudos and
>> respect to you all, this seems to be more and more important the more I
>> find out.
> ...
>> On a semantic note, are you really going to have <interceptor-ref> tags in
>> struts-config? Or are you changing the name to something more, ahem,
>> user-friendly?
>
> To be clear, we've adopted WebWork 2.2 as Struts 2.0. For Struts 1
> developers, moving to Struts 2 is going to represent a clean break. Both
> versions use the same strategies and architecture, but the implementation
> details differs. We're working on material to ease the transition, but it's
> still going to be a transition. Happily, the versions can coexist, so one
> option for teams with a working S1 application will be to try new work in S2.
>
> I hadn't really thought of <interceptor-ref> as being unfriendly before. I
> believe the idea is that we can specify an interceptor or a reference to
> another interceptor element, mixing and matching as needed.
Guessing how busy you are, you may not be interested, but I think it's pretty
obvious that the more user-friendly a name is, the more it will be used by the
community.
Interceptor-ref probably describes exactly what it is in framework architecture
terms, but something like 'goal', 'phase', 'execution' or 'command' will
undoubtedly be alot better received. (I grabbed those from the maven vocab, in
case you didn't notice).
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
Posted by Ted Husted <hu...@apache.org>.
On 7/24/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> It all looks very interesting. I just read some stuff on the xworks opensymphony
> site and it looks pretty sound [1] and [2]. You guys must be working like dogs,
> there seems to be so much there to integrate. Kudos and respect to you all, this
> seems to be more and more important the more I find out.
...
> On a semantic note, are you really going to have <interceptor-ref> tags in
> struts-config? Or are you changing the name to something more, ahem, user-friendly?
To be clear, we've adopted WebWork 2.2 as Struts 2.0. For Struts 1
developers, moving to Struts 2 is going to represent a clean break.
Both versions use the same strategies and architecture, but the
implementation details differs. We're working on material to ease the
transition, but it's still going to be a transition. Happily, the
versions can coexist, so one option for teams with a working S1
application will be to try new work in S2.
I hadn't really thought of <interceptor-ref> as being unfriendly
before. I believe the idea is that we can specify an interceptor or a
reference to another interceptor element, mixing and matching as
needed.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
Posted by Ted Husted <hu...@apache.org>.
On 7/24/06, David Evans <ds...@berndtgroup.net> wrote:
> There is another idiom that is used for method selection which is
> fooAction!barMethod.action. In this case the mapper will run the
> barMethod of the fooAction. This seems to be going away, as it can be
> duplicated by the use of wildcards, as described in this thread:
> http://www.mail-archive.com/dev@struts.apache.org/msg22761.html
Yes, the action!alias idiom is deprecated. There are some release
notes regarding Struts 2.0.0 here:
* http://www.twdata.org/backups/WW/release-notes-200.html
Still a work-in-progress though.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
CoC/CoR
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
David Evans on 24/07/06 22:20, wrote:
> On Mon, 2006-07-24 at 21:45 +0100, Adam Hardy wrote:
>> Ted Husted on 24/07/06 15:22, wrote:
>>> The package that delivers the interceptor mechanism is XWork. XWork also
>>> handles matcing things like URIs to action mappings and it provides the base
>>> validation framework. Surprisingly little is actually in Struts 2 itself.
>>> Most of the functionality derives from XWork, which is web-neutral. XWork is
>>> already being used to power other frameworks.
>> I've divided up my response as you may have noticed from the list of emails from
>> my email address.
>>
>> It all looks very interesting. I just read some stuff on the xworks opensymphony
>> site and it looks pretty sound [1] and [2]. You guys must be working like dogs,
>> there seems to be so much there to integrate. Kudos and respect to you all, this
>> seems to be more and more important the more I find out.
>>
>> I am pondering on the command/dispatch style action mechanism like
>> DispatchAction where the dispatch switch is based on an HTTP parameter
>> identified by its prefix.
>>
>> Would that mechanism be implemented by a pre-action listener? I'm trying to pick
>> up the lingo on the hoof here [2].
>
> This page will help:
> http://opensymphony.com/webwork/wikidocs/ActionMapper.html
>
> If a parameter is sent which has the string "method:" as its beginning,
> the DefaultActionMapper uses the rest of the string as the name of the
> method to execute for that request.
Super. That is just what I was looking for. It's going straight into my Struts
1.3 app.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
CoC/CoR
Posted by David Evans <ds...@berndtgroup.net>.
On Mon, 2006-07-24 at 21:45 +0100, Adam Hardy wrote:
> Ted Husted on 24/07/06 15:22, wrote:
> > On 7/23/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> >> Can anyone involved in struts 2 tell me about potential brick walls that
> >> this sort of Action base class and its children would be heading into? I
> >> checked out the dev list for hints and saw oblique references to Chain of
> >> Commands but couldn't guage much from the threads there.
> >
> > S2 doesn't use Commons Chain internally. S2 relies on the notion of
> > "interceptors" to do what we did in S1 with the Chain of Commands.
> > Essentially, interceptors are POJO filters that let us run custom code before
> > and after a key event, like invoking an Action class.
> >
> > The package that delivers the interceptor mechanism is XWork. XWork also
> > handles matcing things like URIs to action mappings and it provides the base
> > validation framework. Surprisingly little is actually in Struts 2 itself.
> > Most of the functionality derives from XWork, which is web-neutral. XWork is
> > already being used to power other frameworks.
>
> I've divided up my response as you may have noticed from the list of emails from
> my email address.
>
> It all looks very interesting. I just read some stuff on the xworks opensymphony
> site and it looks pretty sound [1] and [2]. You guys must be working like dogs,
> there seems to be so much there to integrate. Kudos and respect to you all, this
> seems to be more and more important the more I find out.
>
> I am pondering on the command/dispatch style action mechanism like
> DispatchAction where the dispatch switch is based on an HTTP parameter
> identified by its prefix.
>
> Would that mechanism be implemented by a pre-action listener? I'm trying to pick
> up the lingo on the hoof here [2].
This page will help:
http://opensymphony.com/webwork/wikidocs/ActionMapper.html
If a parameter is sent which has the string "method:" as its beginning,
the DefaultActionMapper uses the rest of the string as the name of the
method to execute for that request.
There is another idiom that is used for method selection which is
fooAction!barMethod.action. In this case the mapper will run the
barMethod of the fooAction. This seems to be going away, as it can be
duplicated by the use of wildcards, as described in this thread:
http://www.mail-archive.com/dev@struts.apache.org/msg22761.html
dave
> On a semantic note, are you really going to have <interceptor-ref> tags in
> struts-config? Or are you changing the name to something more, ahem, user-friendly?
>
>
> Regards
> Adam
>
>
> [1] http://xwork.dev.java.net/servlets/NewsItemView?newsItemID=665
> [2] http://confluence.twdata.org/display/WW/Interceptors
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [s2] Re: What's the future of Action, events / dispatching and
CoC/CoR
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Ted Husted on 24/07/06 15:22, wrote:
> On 7/23/06, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>> Can anyone involved in struts 2 tell me about potential brick walls that
>> this sort of Action base class and its children would be heading into? I
>> checked out the dev list for hints and saw oblique references to Chain of
>> Commands but couldn't guage much from the threads there.
>
> S2 doesn't use Commons Chain internally. S2 relies on the notion of
> "interceptors" to do what we did in S1 with the Chain of Commands.
> Essentially, interceptors are POJO filters that let us run custom code before
> and after a key event, like invoking an Action class.
>
> The package that delivers the interceptor mechanism is XWork. XWork also
> handles matcing things like URIs to action mappings and it provides the base
> validation framework. Surprisingly little is actually in Struts 2 itself.
> Most of the functionality derives from XWork, which is web-neutral. XWork is
> already being used to power other frameworks.
I've divided up my response as you may have noticed from the list of emails from
my email address.
It all looks very interesting. I just read some stuff on the xworks opensymphony
site and it looks pretty sound [1] and [2]. You guys must be working like dogs,
there seems to be so much there to integrate. Kudos and respect to you all, this
seems to be more and more important the more I find out.
I am pondering on the command/dispatch style action mechanism like
DispatchAction where the dispatch switch is based on an HTTP parameter
identified by its prefix.
Would that mechanism be implemented by a pre-action listener? I'm trying to pick
up the lingo on the hoof here [2].
On a semantic note, are you really going to have <interceptor-ref> tags in
struts-config? Or are you changing the name to something more, ahem, user-friendly?
Regards
Adam
[1] http://xwork.dev.java.net/servlets/NewsItemView?newsItemID=665
[2] http://confluence.twdata.org/display/WW/Interceptors
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org