Modules vs. Sub-Applications
Going back to the discussion on calling modules sub-applications, I think it was decided to call everything a module to eliminate confusion. The naming of Struts 1.1 classes and methods is not helping this situation. For example, we have an ApplicationConfig class and RequestUtils.selectApplication() methods. Maybe we should change these and others to ModuleConfig and selectModule()? Maybe I'm wrong but this seems to make it consistent. David _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
I thought it was application module, therefore the current names are still consistent with that. Did I miss some threads :( Wait, stop the printer... chuck Going back to the discussion on calling modules sub-applications, I think it was decided to call everything a module to eliminate confusion. The naming of Struts 1.1 classes and methods is not helping this situation. For example, we have an ApplicationConfig class and RequestUtils.selectApplication() methods. Maybe we should change these and others to ModuleConfig and selectModule()? Maybe I'm wrong but this seems to make it consistent. David _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule() would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
Would it make sense to keep the current names but deprecate and replace them in a future version (maybe 2.0)? David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Date: Mon, 28 Oct 2002 10:21:40 -0800 (PST) On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule() would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
I was suggesting deprecating the names in a future version and moving to all module names for clarity, not necessarily removing the functionality. What benefits would making the ActionServlet into a Filter provide? It is an interesting idea. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Date: Mon, 28 Oct 2002 11:11:17 -0800 (PST) On Mon, 28 Oct 2002, David Graham wrote: Date: Mon, 28 Oct 2002 11:24:36 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Would it make sense to keep the current names but deprecate and replace them in a future version (maybe 2.0)? To me, deprecating them in 1.1 would imply that we'd really like to remove them in 1.2 or 1.3 (if there ever was such a thing). And I don't think that's necessarily what we want to do (although it might). If we implemented all of the wild ideas I know of already for 2.0 (such as making the controller a Filter instead of a Servlet), there would likely be very little similarity between 1.x and 2.x other than the product name. We're going to have to very carefully hash out what we think the roadmap should be, before we really have much of an idea on what 2.0 will hold and therefore what deprecstions it might imply. David Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
It would seem like there should be a relatively large gap between 1.X and 2, dont you think? For Struts to maintain it's leadership role in the web app framework, it seems that it must grow significantly. To do that, at some point we'd have to switch over to a different architecture. Much like the commons-workflow package, but customized for web apps. PTS - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 28, 2002 1:11 PM Subject: Re: Modules vs. Sub-Applications On Mon, 28 Oct 2002, David Graham wrote: Date: Mon, 28 Oct 2002 11:24:36 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Would it make sense to keep the current names but deprecate and replace them in a future version (maybe 2.0)? To me, deprecating them in 1.1 would imply that we'd really like to remove them in 1.2 or 1.3 (if there ever was such a thing). And I don't think that's necessarily what we want to do (although it might). If we implemented all of the wild ideas I know of already for 2.0 (such as making the controller a Filter instead of a Servlet), there would likely be very little similarity between 1.x and 2.x other than the product name. We're going to have to very carefully hash out what we think the roadmap should be, before we really have much of an idea on what 2.0 will hold and therefore what deprecstions it might imply. David Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
As these methods are really not part of the public API, could we not just change them now and be done with it? -Ted. 10/28/2002 1:21:40 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule () would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
+1 --- Ted Husted [EMAIL PROTECTED] wrote: As these methods are really not part of the public API, could we not just change them now and be done with it? -Ted. 10/28/2002 1:21:40 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule () would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
Ted Husted wrote: As these methods are really not part of the public API, could we not just change them now and be done with it? Some are Public, however I would also vote +1 to rename them now. I agree with David and say lets go one intermediate step and deprecate them for struts 1.1B3 but to remove them before the next beta or Release candidate. That is what I propose to do with the StrutsValidator StrutsValidatorUtil methods. This would not effect compatability between 1.0 1.1 and would give a grace period to people using the Beta3 or Nightly builds. If a user tries to upgrade to the final struts 1.1 build, we could always suggest first going to the 1.1B3 removing the deprecation warnings then going to 1.1 final. -Rob -Ted. 10/28/2002 1:21:40 PM, Craig R. McClanahan wrote: On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule () would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
On Tue, 29 Oct 2002, Rob Leland wrote: Date: Tue, 29 Oct 2002 00:27:11 -0500 From: Rob Leland [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Ted Husted wrote: As these methods are really not part of the public API, could we not just change them now and be done with it? Some are Public, however I would also vote +1 to rename them now. I agree with David and say lets go one intermediate step and deprecate them for struts 1.1B3 but to remove them before the next beta or Release candidate. That is what I propose to do with the StrutsValidator StrutsValidatorUtil methods. This would not effect compatability between 1.0 1.1 and would give a grace period to people using the Beta3 or Nightly builds. If a user tries to upgrade to the final struts 1.1 build, we could always suggest first going to the 1.1B3 removing the deprecation warnings then going to 1.1 final. I've come around to +1 on the rename+deprecation, but I'm not OK with removing the old ones in 1.1 final. Reasoning: we did a public release (1.1b2) with these APIs. If we'd only done nightlies, I would be OK with the removal. We can do a cleanup of deprecated stuff after 1.1 final and before the first 1.2 milestone, similar to what we did after 1.0 and before 1.1b1. Does that make sense? -Rob Craig -Ted. 10/28/2002 1:21:40 PM, Craig R. McClanahan wrote: On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule () would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
+1 on rename and deprecation. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Date: Mon, 28 Oct 2002 21:48:05 -0800 (PST) On Tue, 29 Oct 2002, Rob Leland wrote: Date: Tue, 29 Oct 2002 00:27:11 -0500 From: Rob Leland [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Modules vs. Sub-Applications Ted Husted wrote: As these methods are really not part of the public API, could we not just change them now and be done with it? Some are Public, however I would also vote +1 to rename them now. I agree with David and say lets go one intermediate step and deprecate them for struts 1.1B3 but to remove them before the next beta or Release candidate. That is what I propose to do with the StrutsValidator StrutsValidatorUtil methods. This would not effect compatability between 1.0 1.1 and would give a grace period to people using the Beta3 or Nightly builds. If a user tries to upgrade to the final struts 1.1 build, we could always suggest first going to the 1.1B3 removing the deprecation warnings then going to 1.1 final. I've come around to +1 on the rename+deprecation, but I'm not OK with removing the old ones in 1.1 final. Reasoning: we did a public release (1.1b2) with these APIs. If we'd only done nightlies, I would be OK with the removal. We can do a cleanup of deprecated stuff after 1.1 final and before the first 1.2 milestone, similar to what we did after 1.0 and before 1.1b1. Does that make sense? -Rob Craig -Ted. 10/28/2002 1:21:40 PM, Craig R. McClanahan wrote: On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule () would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
