>> Some thoughts... >> - Is it such a good idea to pour much of fundamental application design into >> xml files? >> - Should config files be confined to things such as database parameters? >> - Tendency for xml config to become a mini programming language in itself >> - Lacks type safety, syntax checking (ide / compiler) >> - Ultimately gets parsed back into application config classes >> >> The struts-config provides low-coupling, but could this be achieved more >> easily and efficiently another way e.g. static initialisation of core >> classes? >>
I agree with the approach of consolidating configuration information into XML files whereever appropriate. The alternatives of embedding configuration in Java classes is just as error prone - in fact potentially more so. By using XML you present the opportunity for configuration validation via DTD or XML Schema. You also can consolidate most of your config information into a single place - rather than spread it out among a variety of Java files which is what generally happens. Another advantage is that using XML allows the configuration to be changed dynamically and then saved without having to recompile. Embedding constants in java files requires recompilation to alter the configuration. Struts doesn't yet (to my knoweldge) allow the struts-config to change on the fly and then be saved, but this feature may be desireable some day. The one thing I'll add is that once the XML gets beyond a basic level, there should be a tool provided that allows the user to manage the configuration without editing the xml directly. I believe that Struts is approaching this level FOR BEGINNING USERS. Those that have been using it for a while could probably edit the struts-config in their sleep, but for new people and entry-level developers the number of elements can be confusing at first. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
