-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Martin Cooper wrote:
On Sat, 27 Nov 2004 13:33:38 -0500, Ted Husted <[EMAIL PROTECTED]> 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 :)
Perhaps it's a reason to add *some* download example to the Examples app, but IMHO not this particular one.
Downloading a file in Struts is almost trivial - feed the data to the response output stream and return null from your action. I don't want to rain on Frank's parade, but I just don't think that we should complicate such an example by using custom action mappings, or extracting the content from a database.
If we do want a download example in Examples, then I would suggest something like downloading an XML file (maybe even struts-config.xml) from within the app itself. Let's keep it simple, and keep it portable by not referencing the file system.
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.
If we can automate the testing, then great! But adding functionality without that is going to be a pain. It takes quite some time to go through every option in every example we have today, which is what I do for the "play test bundled applications" part of the release process. The end result is that I have a lot more confidence in the build, but if this process gets much longer, it's going to be very tempting to start skipping part of it, which definitely wouldn't be a maintenance helper. ;-) Oh, and by the way, most of the recent bugs in the examples have been discovered and fixed by me, in the process of trying to get a release done...
-- Martin Cooper
-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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
