On 10/5/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > The idea of the plugin is that something is added rather than removed.
On 10/5/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > I definitely agree on a personal level. But trying to place a framework > into a development organization means that I have to ensure that the > framework is easy to use for a larger number of developers of various > levels. I'm not opposed to refactoring, I just want to make sure that the > reasons are well defined and it doesn't incur major headaches. Speaking from experience, letting the framework grow and grow without refactoring concerns into separate components is most definitely a major headache for everyone. In Struts 1, we began to decompose the project into subprojects with independent artifacts because it became too hard to juggle changes to separate concerns. And, it is important to remember that the tags are a separate concern from the core framework. Many people do not use the tags at all, but simply use Struts as a DWR-like backend, either for Ajax widgets, or for web services, or for some other presentation system. I'm not aware of any technical benefit gained by hardwiring various concerns into a single JAR. But, there are a number of technical benefits gained by separating concerns into separate artifacts and then assembling them at runtime. In Struts 2, we have a robust plugin system, and, it follows that everything that can be a plugin should be a plugin (a la Eclipse). For ease of use, we can always assembly a stock set of plugins into a single JAR, and have the best of all worlds. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
