What would be most helpful is an example of your alternative approach. The struts-config.xml itself is not really required, but is perceived as a convenient way to initialize and configure the objects used by the framework.
Once the objects are initalized, the struts-config is not referenced, so loading them from an alternate method is certainly feasible. (And it sounds like you have proven this in practice.) The purpose of the struts-config is to create the lists of ActionForms, ActionForwards, and ActionMappings. Many applications have many more ActionMappings than classes, so it can become a very long list. An XML format is perceived as the simplest way to create this list. I doubt that this perception could be easily changed without a working prototype. I know that in my work, I have made significant changes and additons to applications just by changing the struts-config, without touching a single Java class. Personally, I perceive that as a Good Thing, but your mileage may vary. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Jeff Canna wrote: > > At the risk of being flamed...... > > I've been very interested in struts for quite a while now. Actually tried > using it for a project that I was recently working on. After many days of > fighting with the struts-config.xml file the team decided to implement our > own ModelII framework. > > We had this implemented in about a half a day. (Keep in mind we did not do > anything with validation or internationalization.) We did not use anything > like a config file . Essentially we used reflection to create the action > class before calling into it. Making this work in this way has greatly speed > up our development. It was very clear when the submit had the wrong class > name in it. > > The answers I saw to the original post were in the vane that everyone else > is using XML so why shouldn't we. I haven't seen a good technical reason for > doing this. > > I would be VERY interested to understand the need for this file. In seems it > introduces unnecessary complexity into an application and the same > information can be retrieved from a more straight forward mechanism. > > Jeff Canna > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
