As with all things, a bit of discipline has to be used. If you take an idea and use it to build an "everything" example app, you have to choose something that is (a) not so difficult as to be useless as an example and (b) is big enough to NATURALLY use everything you'd want to demonstrate. If you have to force things in then it doesn't meet the second criteria, and if it's so massive that the app's own code gets in the way of the example then it fails the first.
That's where I came up with the idea of something along the lines of a web-based Outlook. It wasn't a massive undertaking for our old framework, I suspect it wouldn't be for Struts, yet it has enough functionality to be able to incorporate just about anything you'd want without doing anything unnaturally.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Ted Husted wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
