>> 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? >> >> XML gives language independence - but struts is basically a homogenous java >> environment, so I've lost sight of why I am designing my config in XML. >> >> With the struts-config, you can easily swap new classes, and change >> application parameters without recompiling, but this may actually hinder the >> real burden of ensuring application integrity, regression testing etc. >> >> I'm interested in different views on this to sway me one way or the other... >>
>The important benefits that using XML brings to Struts: > >* The data is naturally organized in a hierarchical manner, > which is utilized to good effect when it matches the nature > of the things being configured. This is miserably difficult > in a "flat" file format like properties files. > >* The data format is amenable to being generated by tools > instead of people. Things like Struts Console already do the > grunt work of getting the XML syntax right -- extending this > concept to automatically scanning a JAR file and building you > a select box of all the classes that implement Action (so that > you can point and click instead of type a class name) is the > next logical step. I agree that tools are perfectly suited for this. ObjectAssembler (http://www.objectventure.com/objectassembler.html) not only generates and maintains the XML configuration file, but it gives you the next logical step that Craig is referring to. You are still free to type in, say, what action component is used in an action mapping, but OA provides a drop-down that gives you a list of all available fully qualified action components. Same goes for ActionForms and other components. In addition, OA provides real-time validation of all Struts components and configurations, which goes beyond pointing out compilation problems. What about deployment issues? Good programming practice? Tools like OA take much of the grunt work out of building these configuration files, packaging your stuff in a WAR, and deploying while avoiding common mistakes. And with the popularity of Struts, tool support for it will continue to improve. >> Regards >> Paul Kelly >> >Craig Regards, Bill -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
