On 12/23/05, netsql <[EMAIL PROTECTED]> wrote: > > One nice thing about Struts and Spring is that *everyone* knows how to > start examining and working on the application. > Just go to the config.xml! > > It tells you where to start and what gets called and I can open it and > start there. Once you get rid of a config .xml, there is no guide to the > application, I have to look at packages and code, etc. and I have at > times re-written things because it was faster than trying to figure out > what they guy before me did. A guide that requires documentation.
There is definitely a value to configuration files ... indeed, when Struts first started using XML for configuration this was considered a huge positive, for the reasons Vic lists :-). It's only nowdays that XML config is out of fashion. That being said, there is a competing school of thought that revolves around the idea of just building the actual logic of your application, and let the framework figure out how to wire everything together. For a framework to be popular today (versus five years ago when Struts was working towards a 1.0release), it needs to recognize this desire. 2ndorily, CoR is a huge feature, developing a library of reusable > "action brick" that can be mixed and matched. So you can use them in > other configurations an contexts. Plus digester type features to ... > "inject". Like to use the commands w/ WS, etc. > > -1 Even if this proposal gets implemented, and even if it meant removing the existing built-in support for executing a Commons Chain command mapped to a URL, nothing stops you from using CoR yourself. It's a few lines of code to set up an action method that does what the current implementation does. Indeed, the existing code from ShaleApplicationFilter.doFilter() does exactly what you'd need to do -- it would just need to be recast into an action method instead of as a Filter. .V Craig
