-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
> I don't really like your approach and don't want to see such an Action > added to a Framework like Struts. Here's a few comments why: A big part of the reason I posted this was to see if this was something people thought should be included, so I very much welcome your opinion and thank you for it. > * Struts is database-independent. People don't necessarily use plain > JDBC. Fair point, but that was the reason I wrote it to work from a database as well as the file system. While the production app I use this in does work from a database, that's obviously not always the way it's done in every case. In addition, although I didn't put this in the comments, but I speficially broke out the getDBConnection() method so that a developer could override it to handle whatever method of DB access they use. True enough, that doesn't remove the JDBC code from the rest of the Action. > * You are getting anything you need for accessing your DB from the > request, including SQL, username, password, i. e. it would > probably have to be included plain text in some JSP. Bad thing... Yes, true, but as my comments stated, I did it this way because I couldn't do it the way I wanted on my own, which is to have most, if not all, of the parameters as attributes of the <action> tag. I'd still like to keep the ability to use what comes with the request because then you could do things like have a single ImageServerAction that just accepts the query portion with the request with the rest coming from the Action mapping for instance, you could do: <img src="/myapp/ImageServerAction.ma?clientid=123"> That way, maybe the user can select a client to work with, just insert the ID in the JSP code and your all set with a dynamic logo maybe (this example is exactly what I do in my production app). > * I don't like JDBC in Actions. What about separating controller > from business logic and database access? I agree in general 100%. However, I wouldn't consider something like this to be "business logic" per se, and therefore JDBC in the Action is less offensive to me than it otherwise would be. > * Your approach is not very flexible. You may not always want to > read the data completely into memory before writing it to the > response. Yep, someone else pointed this out to me. I hadn't considered that. If for no other reason than performance and server resource utilization, I need to refactor the code to stream the BLOB object. > * BTW, it's a good idea to call response.reset() and, if possible, > to set the content length before writing to the OutputStream. The content-length was an oversight on my part... My production code DOES do that, but when I re-wrote it to post here I neglected to add that line. My bad, as the young folk say :) > Streaming files back to the reponse is really nothing special, and it's > not exactly a Struts-specific thing. A simple Booch utitlity class would > serve the purpose. I don't argue that. My only point with this was that since this is a common enough activity that many Struts users do, it might be a good candidate for being "built-in" to Struts, at least to deal with the 95% of cases that it can deal with in a generic way. My response to Craig's comments tie in with this discussion as well, he raises an interesting possibility... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
