On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > Is it the intention of the Struts commiters to > make a Command something like a new Action that should be used instead? > Or are you expecting commands to be created solely for the request processor > chain?
Some people have suggested that Command replace Action, and we are encouraging people to explore that avenue to see how well it works. Personally, I favor using Commands the way WebWork/Action2 uses Interceptors and leaving Action as a "place to stand" on the web layer. Our intent has been to make a numbered build available so that we can get more input from other Struts developers. > If it is the second, then I stand by my suggestion that ActionContext should > be renamed > to reserve the name (ProcessorActionContext?) for the day when you want > actions to > receive an ActionContext like WebWork. :) There are any number of naming quirks in Struts Action 1.x, and I don't know if one more is going to make a difference. :) The 1.3.x series has been cooking for about 18 months now (since the summer of 2004), and some people are already using it in production. I think if we do not get something rolled this week, a few us might burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't mean that we can't make significant API changes before 1.3.x goes GA. But, it does mean more people will look at what we've done so far. If we did decide to rename a member for future use, we could copy it and deprecate the old one for a milestone, and then remove the old one. But, since the ActionContext has been in the nightly build for many, many months, we should not just change it willy-nilly. Once we get a numbered build out there, I'm sure that there will be many more comments like this. If there is interest, we can regroup and make any desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we have deprecated and removed and released new members during a beta cycle, and I expect we wil do so again. The other important thing is that once we roll the seven 1.3.0 builds, we can make internal changes to Action without re-releasing the other six, if the external API doesn't change. I would tend to agree that we need two flavors of Context available during the request/response cycle. One for the Actions and Commands to use internally, and another for server pages (including Velocity templates) to read externally. Perhaps we could just adopt the Velocity Tools for that, and expect that tags to get everything they need from a "tool" passed through the request. * http://jakarta.apache.org/velocity/tools/ But, before getting into anything like that, we should roll the 1.3.0 builds, so that we can start making lighter releases. I didn't have any discretionary time last night, but, hopefully, I can wrap up the review of the Release Notes tonight. We can then tag the repository for STRUTS_1_3_0 as well as for each of the subprojects (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. -- HTH, Ted. ** http://www.husted.com/ted/blog/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
