Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

> 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

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]

Reply via email to