On 30 Oct 2002 [EMAIL PROTECTED] wrote:
> Rename "Application" components to "Module" It would probably be more convenient to have this conversation directly on STRUTS-DEV while we hash out the details :-). Regarding Rob's basic issue, it might be worthwhile to see how I treated essentially the same problem in the 1.0->1.1 transition. For example, the concept of ActionMapping (1.0) is now called ActionConfig (1.1). In that case, I did: * Put all the functionality that used to be in ActionMapping into ActionConfig (tweaking for new properties as needed, of course). * Made ActionMapping extend ActionConfig, and added the few extra method signatures needed for backwards compatibility to the old ActionMapping API. * In this case, I chose not to deprecate ActionMapping because it is part of the fundamental application APIs (i.e. we pass one to the Action, so changing that would have a *lot* of impact on existing applications). I don't think that argument applies to things like ApplicationConfig, which would be deprecated in favor of ModuleConfig. This approach is *not* binary backwards compatible (because the underlying inheritance hierarchy of ActionMapping changed), but it *is* source backwards compatible - a recompile against the new struts.jar makes everything work. So, this is a long-winded case of asking "why can't we do this"? * Move all the functionality of ApplicationConfig to ModuleConfig. * Make ApplicaitonConfig a subclass of ModuleConfig with no extra methods of its own. * Deprecate the ApplicationConfig class itself. * Modify all source references from ApplicationConfig to ModuleConfig (which is a fairly large, but fairly mechanical, exercise) -- and don't forget the unit tests :-). Craig -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
