On Sat, 27 Nov 2004 14:06:39 -0500, Frank W. Zammetti wrote: >�Before my company decided to join the real world and use Struts, we >�had our own custom framework that we developed. �One of the pieces >�I lobbied for and wound up building was one all-encompassing sample >�application with a suite of test cases along with it. �This sample >�was self-documenting (in source comments as well as the application >�being very verbose in it's UI) and served as a good example of how >�to do just about everything, and also providing a good way to test >�upgrades to see what got broken.
That sounds like a fine approach for a internal framework, where the use cases tend to be coherent, but an omnibus application for a shared framework, like Struts, can be problematic. What's happened in the past is that we are tempted to stretch the context of the application to fit the use case. The benefit of a Cookbook example application is that it is all example and no context. The examples don't have to have anything to do with each other. For us, a Cookbook mirrors real-life, where our users' applications don't have anything to do with each other either :) Of course, we also need a coherent example, which is a niche that a lean, mean MailReader application fills nicely. But, as usual, Martin makes a good point. We can't expand on the current set of examples without automating the testing. So as of now, the next three items on my own Struts to-do list are: * Finish the MailReader-Chain example, including automated testing. * Add automated testing to the Struts Examples application. * Consider whether we need to add a download example. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
