Well, a framework is a semi-complete application [Johnson]. A lightweight container is essentially an object factory, as you implied.
Struts is more than a framework. It's also a container that manages the lifecycle of the objects created by the struts-config. You could, for example, use Spring to load the struts-config instead of the Distiller. Right now, I'm using Spring to load my CoR objects. But, hey, the business-end of the applications someone else writes might not need or want a container. :) It's not possible for me to say why someone else needs a container. :) I can say why my team uses a container for our business logic objects. So Why? Because we really, really like writing a handful of base objects to do 90% of the work and configuring them in XML. Of course, your mileage may vary. A lot of people decide not to use Struts because they don't want to do the XML config thing. In the application in front of me now, we have 13 base objects that we use to create 51 commands or chains. After lunch, I'll add another 20 commands for editing various database records, but I won't need to add a single new class. All I need are new elements in the Spring config to configure old base objects with new details, and the corresponding datebase statements in the iBATIS config. It's not unlike using Tiles to create pages, except we're creating chains of business logic. If anyone is actually interested in IoC containers, check out Rod Johnson's book, "J2EE Development without EJB". Another good reference is Matt Raible's WebLog. [http://raibledesigns.com/page/rd?anchor=appfuse_refactorings_part_ii_spring] Matt refactored Appfuse "in Anger" for Spring and has never looked back :) But, at this point, I think we begin to digress ... -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
