Lord, if there were gigabytes of comments that would be bad.
Horrible. A disaster. Something to cry about. However, there are
not. So that is good. Very good. Something to smile about. If
there is anything like a whole bunch of comments, that is the sign of
an amateur and the same is true a
This is directly contrary to best practices. What really would have
helped in Struts would have been if someone had discussed some of the
naming conventions prior to committing them. They are particularly
bad in Struts. However, best practices is to make the code clear
first. If that is not pos
I think the idea is to make code clear. If you cannot possibly make
the code clear without comments, then put the comments into the code.
Gratuitous comments are counter-productive.
On 9/29/05, Dave Newton <[EMAIL PROTECTED]> wrote:
> Frank W. Zammetti wrote:
>
> > Let me ask this question... wh
Actually, if you are going to build a servlet with this capacity, it
should handle all such resources, not just images. You can, e.g.,
make big savings with using these for CSS, etc.
On 9/29/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> On 9/29/05, Braun, James F <[EMAIL PROTECTED]> wrote:
>
Braun, James F wrote:
In my defense:
No need--we go off on these dumb tangents (well, _I_ do, anyway) all the
time. It's just one of those stupid religious flamewars.
I'm reminded of the guide on Mt Everest who said, "If they need my help,
they shouldn't be here!" That was the year 17 peo
Users Mailing List
Subject: Re: [OT] Re: writing images from a database
Frank W. Zammetti wrote:
> Let me ask this question... what's the HARM in "read in the bytes"?
Having comments that are superfluous:
(a) still requires brain processing, and my brain is in short supply :/
(
On 29 Sep 2005 at 19:11, Frank W. Zammetti wrote:
> Murray, have you ever actually had a compiler choke on a source file
> because of comments?!? *That* might be the harm indeed! :)
There were a couple of times when I had to consider the cost of disk space vs
the value
of a program. When the
Norris Shelton wrote:
It is better to be over-documented, than under. Also, I would
use the full package name on objects. Nothing is more fun than
trying to figure out an object when it's in more than one
package (like ALL the client certificate code) or it's in some
library that you have neve
Frank W. Zammetti wrote:
Let me ask this question... what's the HARM in "read in the bytes"?
Having comments that are superfluous:
(a) still requires brain processing, and my brain is in short supply :/
(b) obscures what's actually being done (see note below)
(c) requires maintenance
Note: If
Let me ask this question... what's the HARM in "read in the bytes"?
Murray, have you ever actually had a compiler choke on a source file
because of comments?!? *That* might be the harm indeed! :)
Frank
Dave Newton wrote:
Murray Collingwood wrote:
I agree with Frank, we all started with Jav
Yes and no.
If it's his production code no, but if it's a how-to or
something that goes in a wiki, it should leave no details
uncovered.
It is better to be over-documented, than under. Also, I would
use the full package name on objects. Nothing is more fun than
trying to figure out an objec
Murray Collingwood wrote:
I agree with Frank, we all started with Java/Struts somewhere and back then the more
comments in the code made it so much easier for us to understand.
If you're documenting functionality, I totally agree.
If you're commenting "inputStream.read(xxx)" with "read in th
I agree with Frank, we all started with Java/Struts somewhere and back then the
more
comments in the code made it so much easier for us to understand. The people
who
come after us will also be learning, let's make it easier for them.
The only time you should reduce comments is when your comp
We had a similar requirement. We solved it in the same way. We
had the special image requests served by a servlet directly.
The servlet read the information from the database (also Oracle)
and streamed out the bytes to the user.
The DBA did tweak the database to perform moderately well
(Oracle
Michael Jouravlev wrote:
simpler and generic, like a servlet with image name as parameter.
+1
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Frank W. Zammetti wrote:
Well now, *this* is a good way to go off-topic in a hurry Dave! :)
I'm sorry, I have a cold. (Marginally obscure Monty Python reference.
Every OT post needs one.)
I didn't mean to start a debate here?
I personally feel just the opposite... the more comments the b
On 9/29/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> For instance, take this line:
>
> String s = s1.toUpperCase().trim().replace('A', '-');
>
> Now, that's pretty straight-forward. But, if someone added a comment:
>
> // Convert s1 to all upper-case, trim whitespace from both ends and
> rep
On Thu, September 29, 2005 11:57 am, Dave Newton said:
> Oh god remove the comments. Bottom line: if someone can't figure out
> what's going on here w/o relying on the comments then they're fired.
Well now, *this* is a good way to go off-topic in a hurry Dave! :)
I personally feel just the opposi
On 9/29/05, Braun, James F <[EMAIL PROTECTED]> wrote:
> With the help of this list and some digging I think I came up with a
> relatively elegant solution (subject to expert critique which is
> welcome). I don't know if attachments are allowed on this list so I've
> included the how-to I write up f
Braun, James F wrote:
I didn't mean for this to become debate.
Yeah, good luck with that.
*lol*
As you've discovered, some people are more interested in being uppity
than actually helping with the core question :/
byte[] bytes = new byte[1024*1024]; // some maximum size
The only question I would ask is why your storing it in the ActionForm?
If it's request-scoped, that means you are reading the image from the
database with each request (or from server cache I suppose), which is
something I would suggest avoiding if possible. If the form is
session-scoped (which
You can post them on the Struts wiki:
http://wiki.apache.org/struts/
Niall
- Original Message -
From: "Braun, James F" <[EMAIL PROTECTED]>
Sent: Thursday, September 29, 2005 3:15 PM
Although I'm new to struts I've collected several of these how-to
articles which address problems I'
I didn't mean for this to become debate. I was stuck with a legacy app
that required storing images in the db.
With the help of this list and some digging I think I came up with a
relatively elegant solution (subject to expert critique which is
welcome). I don't know if attachments are allowed on
ut with the hit of obtaining a database connection and writing
> the bytes to file (In whatever highly efficient method you recommend)
>
> -Original Message-
> From: Murray Collingwood [mailto:[EMAIL PROTECTED]
> Sent: 27 September 2005 22:46
> To: user@struts.apache.org
He doesn't care about overhead, Frank. He just wants to do it. If it
is slow, ugly, etc. that does not matter to him.
On 9/27/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> The Wiki is your friend:
>
> http://wiki.apache.org/struts/StrutsFileDownload
>
> Specifically, you will be interested
Sorry, Murray, he just wants to do it. All the performance, etc.
stuff is just not relevant to his coding.
On 9/27/05, Murray Collingwood <[EMAIL PROTECTED]> wrote:
> I went through the process recently - the performance of MySQL handling
> images was
> soo bad I immediately changed all my think
Sorry, Ross, he doesn't care about doing this well. Only just doing it somehow.
On 9/27/05, Ross Gibb <[EMAIL PROTECTED]> wrote:
> I'm using DB2 with pictures stored as blobs. We have a system similar
> to what Wendy suggested. When the image is retrieved from the database
> it is sent to an im
005 22:46
> To: user@struts.apache.org
> Subject: Re: writing images from a database
>
> I went through the process recently - the performance of MySQL handling
> images was
> soo bad I immediately changed all my thinking and put the images in a
> sub-directory in
> my file syste
I'm using DB2 with pictures stored as blobs. We have a system similar
to what Wendy suggested. When the image is retrieved from the database
it is sent to an image servlet that will cache the image. The browser
then asks the image servlet for the image. The image servlet is also
smart enoug
:[EMAIL PROTECTED]
Sent: 27 September 2005 22:46
To: user@struts.apache.org
Subject: Re: writing images from a database
I went through the process recently - the performance of MySQL handling
images was
soo bad I immediately changed all my thinking and put the images in a
sub-directory in
my file
I went through the process recently - the performance of MySQL handling images
was
soo bad I immediately changed all my thinking and put the images in a
sub-directory in
my file system.
The code I was using was buffering (32k) and the images were only about 100k
and still
I had to wait 8 sec
The way I do this is to dynamically control caching on the CLIENT.
Some clients have one cache time and others have a different time.
Also, for different images, you can use different caching times on the
same client. There are lots of ways to fry this fish.
On 9/27/05, Frank W. Zammetti <[EMAI
The Wiki is your friend:
http://wiki.apache.org/struts/StrutsFileDownload
Specifically, you will be interested in the downloadapp.zip sample I
posted there... it has an example of serving a BLOB from a database. All
you need to do is have a mapping to this Action, and use it as the src
attribute
You need to put in a bit more buffering, etc. in this code, Mark. I
recommend you read up on how to read and to write to files more
efficiently. Also, due to the nature of how computers work, I would
highly recommend you create a multi-threaded application to do this.
You will find that your per
From: "Braun, James F" <[EMAIL PROTECTED]>
Goal: Read a blob image from an Oracle database and render it on an html
page using the struts framework.
I have no trouble getting the image from the database. However, I wonder
if there isn't a better way to display it rather than writing it to a
phy
I've seen this conversation before so I don't think I am saying anything
outlandish here.
There is a performance overhead from reading a database to present to the
JSP page, however you look at it. There is nothing wrong with writing the
image once to the file system, and storing a reference to th
36 matches
Mail list logo
