Craig wrote: > > "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" > "http://struts.apache.org/dtds/struts-config_1_2.dtd"; [ > > > > ... > ]> > > > > &package-a; > &package-b; > ... > > > > where "package-a.xml", "package-b.xml" and so on contain the form > beans and actions for some logical subset of your overall application.
Craig, thank you for this info. Craig, does this confirm with the dtd file? Also, can you tell us the site link on Internet that uses hundreds actions? It seems this approach the best in all the options we discussed. In fact, when I develop an knowlege site with forums in java. I first used struts, then I had some problems on configure file so I used another MVC approach. If I know I could do this way, I may stick with struts in this large project. Jack H. Xu Technology columnist and author http://www.usanalyst.com http://www.getusjobs.com (Both sites are developed in java and on open source). ----- Original Message ----- From: "Craig McClanahan" To: "Struts Users Mailing List" Subject: Re: long struts-config.xml file Date: Fri, 17 Jun 2005 22:48:44 -0700 > > On 6/17/05, Frank W. Zammetti wrote: > > Good info Craig... So do I understand correctly then that you can > > specify multiple config files for an app regardless of module > > usage (well, one with just the "default" module really)? > > Yep. > > > I thought I saw someone mention a CSV list in the ActionServlet > > init param, is that all there is to it?... > > Yep :-). > > > If so, I don't think I was aware of that, definitely not fully > anyway, and thank you for pointing it out :) > > You're welcome. > > Of course, there's also an XML level solution to this problem, > something that works even if the program that is reading the document > doesn't support multiple configuration files -- XML entities. > Consider the following sort of struts-config.xml file: > > > "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" > "http://struts.apache.org/dtds/struts-config_1_2.dtd"; [ > > > > ... > ]> > > > > &package-a; > &package-b; > ... > > > > where "package-a.xml", "package-b.xml" and so on contain the form > beans and actions for some logical subset of your overall application. > In this scenario, the XML parser glues everything together into one > document (from the point of view of the application doing the > parsing), while still allowing each subset's own configuration file to > be managed by the team that is responsible for the code and JSP pages > for that subset. > > This strategy works with any sort of environment that consumes XML > documents, because it's the parser that is doing the dirty work for > you. > > > > > Frank > > > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Jack H. Xu Technology columnist and author http://www.usanalyst.com http://www.getusjobs.com -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
