I agree completely, and can speak from experience...
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.
I'd definitely agree that Struts should have such a beast. From what I understand, the MailReader is a decent start at this, but probably should be taken to the next level. One thing I could see fiting in this mold is an actual PIM and webmail application. More work to developer initially to be sure, but has all the benefits we're talking about. Also, it shouldn't be too tough to break it into discrete pieces to be developed by a number of individuals, and you would be able to assign each piece various bits of "sample space" to demonstrate (i.e., the contacts module should demonstrate functions A, B and C, while the tasks module should demonstrate, D, E and F for example). This would also make the sample more useful because you could look at a particular module when you know you are looking for a specific feature demonstration rather than going through everything in a monolithic way.
I think such a suite of applications would also be big enough to actually touch on every feature in a non-forced way, yet wouldn't be so big as to be impossibly time-consuming to build, especially when spread across a number of people. I'm not talking about building a web-based Outlook, but relatively simple versions of contacts, tasks, notes, webmail and maybe journaling shouldn't be immensely difficult to put together. I'd certainly sign up to do some portion of it, time permitting (I MIGHT be able to justify some of it on company time if I claim it's a new feature of an existing system).
Add to this a suite of test cases, and you should be able to tell when you break anything going forward without much difficulty.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Ted Husted wrote:
On Fri, 26 Nov 2004 20:42:07 -0800, Martin Cooper wrote:
On Fri, 26 Nov 2004 23:27:44 -0500, Ted Husted <[EMAIL PROTECTED]> wrote:
There's a download module in the struts-examples application.
Er, that's an upload example. ;-)
All the more reason to add it to the current suite of examples, then :)
IMHO, one of the keys to the success of Struts was that, from the beginning, Craig included a working example. The purpose of a framework like Struts is to write applications, and it only makes sense that we eat some of our own dog food by writing our own.
As it happens, the MailReader is nicely scaled example. Big enough to have some meat, small enough that you can review it before lunch.
Of course, you can't squeeze use cases for every framework feature inside of a nicely-scaled example. We've made some desperate hacks to the MailReader to demonstrate features like wildcard actions. MailReader also includes some "grey practices", like tag-based security, apparently for the sake of demonstration.
What I would suggest is that we expand the existing Struts Examples application, perhaps turning it into an actual cookbook. The goal would be for each significant feature to be demonstrated either in the MailReader or in the Cookbook. To keep things from breaking, we can include Struts TestCases and/or Canoo WebTests that step through the applications for us. (I'm using WebTests in Mailreader-Chain, so people will be able to see them action.)
It's been my experience that a best-practices example and an omnibus Cookbook are not maintenance burdens -- but maintenance helpers. As issues are reported, we can add cookbook examples to demonstrate that the issue exists, and then use the same example to demonstrate that the issue is resolved.
-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]
