On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > 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.
I just checked SVN, and ActionContext has been in there for just over a year. Some people have been developing with it in nightly builds since then. I, for one, am certainly not in favour of changing such a key class on the eve of rolling the first "real" 1.3.x build, not least because I don't want to have to go change my code! ;-) 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. +1 -- Martin Cooper 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] > >
