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]
