[s2] Re: What's the future of Action, events / dispatching and CoC/CoR
On 7/23/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
Ted Husted on 24/07/06 15:22, wrote: On 7/23/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
On 7/24/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
On 7/24/06, David Evans [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
Ted Husted on 24/07/06 21:59, wrote: On 7/24/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
On 7/24/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
interceptor-element? Ted Husted wrote: On 7/24/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
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 [EMAIL PROTECTED] wrote: interceptor-element? Ted Husted wrote: On 7/24/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
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 [EMAIL PROTECTED] wrote: interceptor-element? Ted Husted wrote: On 7/24/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Re: What's the future of Action, events / dispatching and CoC/CoR
On 7/24/06, Adam Hardy [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
