struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@blueyonder.co.uk>
Subject Re: Rendering Images
Date Thu, 17 Jun 2004 16:31:09 GMT
Firstly, I found this like helpfull:

     http://www.mnot.net/cache_docs/

I'm not expert, but my understanding is that you need to decide how long you
are happy for the stuff to be cached (a day, a week, a month) and set the
"Expires" and "Cache-Control" headers. Something like...

   response.setHeader("Cache-Control", "public,max-age=86400"); // Cache for
24 hrs

(max-age is in seconds)

   Calendar calendar = Calendar.getInstance();
   calendar.add(Calendar.DATE, 1); // add one day
   response.setDateHeader("Expires", calendar.getTime().getTime());

The link I gave says the Date for the "Expires" header needs to be GMT.

Thats the limit of my knowledge, anyone else who knows more, feel free to
jump in.

Niall

----- Original Message ----- 
From: "mike" <mike@michaelmcgrady.com>
To: "Struts Users Mailing List" <user@struts.apache.org>; "Struts Users
Mailing List" <user@struts.apache.org>
Sent: Thursday, June 17, 2004 6:31 AM
Subject: Re: Rendering Images


> Hi, Niall,
>
> Could you amplify on your note about "the right headers"?  Thanks!  I hope
> to learn something from you on this one.
>
> Michael
>
> At 07:33 PM 6/16/2004, Niall Pemberton wrote:
> >No! :-( This wouldn't be as simple as just adding an "imageNotFound"
> >property and for it to work it wouldn't be desirable in this tag.
> >
> >The <html:image..> tag doesn't know whether the image exists or not, all
it
> >does is render the <input type="image src="....." /> markup with the
"src"
> >attribute pointing to the location of the image - its then the browser
which
> >actually downloads the image, based on the src specified. The good thing
> >about this is that it can do caching, making pages load faster on
subsequent
> >visits.
> >
> >In order for the tag to know that the image didn't exist it would have to
> >retrieve it from the location specified - that would happen every time
the
> >jsp was executed to create the page  and the browser would still do the
> >download as well. It would be better all round to use the solution
proposed
> >in this thread (using an Action to render an image) as with the right
> >headers set in that action, caching could still occur.
> >
> >Niall
> >
> >----- Original Message -----
> >From: "CRANFORD, CHRIS" <chris.cranford@setechusa.com>
> >To: "'Struts Users Mailing List'" <user@struts.apache.org>
> >Sent: Wednesday, June 16, 2004 5:15 PM
> >Subject: RE: Rendering Images
> >
> >
> > > YES! ;-)
> > >
> > > -----Original Message-----
> > > From: Linck, Ken [mailto:Ken.Linck@crowncastle.com]
> > > Sent: Wednesday, June 16, 2004 11:57 AM
> > > To: Struts Users Mailing List
> > > Subject: RE: Rendering Images
> > >
> > >
> > > On a sidenote, it would be kind of nice to add some kind of
imageNotFound
> > > property to the <html:image..> tag where you could specify an
alternate
> > > image instead.
> > >
> > > It seems like a common challenge in many places.
> > >
> > > -----Original Message-----
> > > From: mike [mailto:mike@michaelmcgrady.com]
> > > Sent: Wednesday, June 16, 2004 11:48 AM
> > > To: Struts Users Mailing List; 'Struts Users Mailing List'
> > > Subject: RE: Rendering Images
> > >
> > > I should say also, Jacob, that if you think the simple "URL" or
"protocol"
> > > is important and you wanted to complicate the code you could easily
change
> > > the request in the response to: /resource.do?hello.gif.  I use
> > > /resourcedo?file_type=gif&file_name=hello.gif because in fact there
are
> > > other uses for things like /resource.do?hello.gif which are more
important
> > > to me.  That is another story, however.
> > >
> > > At 08:34 AM 6/16/2004, Hookom, Jacob wrote:
> > > >Why would you use something like that?  I'm maybe not following the
> > > >code? Is this so instead of writing:
> > > >
> > > >/images/hello.gif
> > > >
> > > >you can write:
> > > >
> > > >/resource.do?file_type=gif&file_name=hello.gif
> > > >
> > > >??
> > > >
> > > >-----Original Message-----
> > > >From: mike [mailto:mike@michaelmcgrady.com]
> > > >Sent: Wednesday, June 16, 2004 10:14 AM
> > > >To: Struts Users Mailing List; Struts Users Mailing List
> > > >Subject: RE: Rendering Images
> > > >
> > > >I forgot.  I have the entire solution I use at the struts wiki at
> > > >http://wiki.apache.org/struts/StrutsCatalogEschewUrlForProtocol.  All
> > > >you have to do is to examine the input and give a different output
for
> > > >your problem.  I use Wendy's get the data right solution, but I don't
> > > >have your problem.  This is the easiest way to do this, I think.
> > > >
> > > >At 11:20 PM 6/15/2004, Linck, Ken wrote:
> > > > >It sounds like you have enough ways to do it and just asking what
> > > > >would be the best way or if there is another way to more
efficiently
> > > > >handle your situation. Yes?
> > > > >
> > > > >I cannot think of one personally.  If your only means is HTTP, your
> > > > >only choice is evaluating the response to determine if something
> > > > >exists as far as I can tell.  If the request cant be served, I
assume
> > >
> > > > >you get a typical response code like a 404?  Not sure what else
there
> > > is.
> > > > >
> > > > >Nothing is real efficient when it comes to file io like functions
via
> > >
> > > > >HTTP.  We tried to have a standard once for serving up file like
> > > > >functions via HTTP but it becomes complex if you wanted to perform
> > > > >other file-io activities like list files, seeing if they exist,
list
> > > > >directories, get file modified dates/times, delete files etc.
Almost
> > >
> > > > >felt like putting a square peg in a round hole for us(Course I
might
> > > > >be behind on the latest and greatest of HTTP).
> > > > >
> > > > >If I was concerned about managing unreliable sources, I probably
> > > > >would have attempted a proxy-like solution through a struts action
at
> > >
> > > > >first crack to do as little coding as possible but it sounds like
> > > > >your past the first crack at it?
> > > > >
> > > > >I will offer up my solution for battering by the populous here.
> > > > >
> > > > >You could set up a specific action which serves the images for
remote
> > >
> > > > >sites.  Your JSP would have an action with a parameter passing in
the
> > >
> > > > >remote URL of the remote site.  Since you indicated that you
> > > > >semi-manage the reference of the image but cant guarantee that it
> > > > >actually exists since its elsewhere, this solution might work
> > > > >good(i.e. you are supplying the remote URL?).
> > > > >
> > > > >You could open a request to the remote site of your URL in a Struts
> > > > >Action instead, if you get a success, take the content of the
> > > > >response and shove it into your response, otherwise, shove the
> > > > >no-image found file(from your server) into the response(Make sure
you
> > >
> > > > >return a null action mapping) since your writing off the content
> > > directly.
> > > > >
> > > > >Your JSP Might look like this:
> > > > ><img
> > > >
>src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=<bean:write
> > > > >name="thisForm" property="remoteURL"/>" width="300" height="300"
> > > > >border=0>
> > > > >
> > > > >Semi/Pseudo Code for proxyRemoteImage.do action:
> > > > >URL theRemoteImageURL = New URL(yourForm.getRemoteURL()); Open
> > > > >theRemoteImageURL Get Response If Response Code good shove content,
> > > > >content type and all the other stuff you need into your response of
> > > > >your users request(that might get rid of you having to handle file
> > > > >type conditions).
> > > > >If Response Code is bad, get the no image file data and shove that
> > > > >into the response instead Return null from execute method.
> > > > >
> > > > >I am sure you can gather upsides and downsides to the proxy-like
> > > > >solution.  Just thought I would throw it into the pool of options.
> > > > >Not a great option but at least as simple I think.  Not sure if you
> > > > >consider it more flexible or not.
> > > > >
> > > > >Hope you find what your looking for.
> > > > >
> > > > >
> > > > >-----Original Message-----
> > > > >From: CRANFORD, CHRIS [mailto:chris.cranford@setechusa.com]
> > > > >Sent: Tuesday, June 15, 2004 4:44 PM
> > > > >To: 'user@struts.apache.org'
> > > > >Subject: RE: Rendering Images
> > > > >
> > > > >Ken,
> > > > >
> > > > >That is what I'd like to do.   Have an image which is rendered in
the
> > > > >case
> > > > >when the defined image cannot be loaded.  the problem I have is
that
> > > > >our database record says that an image should exist, but the
> > > > >manufacturer/supplier didn't provide it to us... thus I need a way
to
> > >
> > > > >check if that image does exist to test that condition.
> > > > >
> > > > >thanks,
> > > > >chris
> > > > >
> > > > >ps - these images are maintained by a second webapp that is on a
> > > > >different web server all together due to space requirements.  so i
> > > > >have to do testing via a HTTP request or something i would think,
no?
> > > > >
> > > > >-----Original Message-----
> > > > >From: Linck, Ken
> > > > >To: chris.cranford@setechusa.com
> > > > >Sent: 6/15/2004 2:32 PM
> > > > >Subject: RE: Rendering Images
> > > > >
> > > > >Just curious but why not just manually make this file once and
return
> > >
> > > > >it when a real image is not found on disk?  Why bother creating one
> > > > >on the fly every time?  Is it different from request to request?
> > > > >
> > > > >We had done something similar.  We created a static image file on
> > > > >disk and return that when a real one is not available.  I think we
> > > > >used a struts condition if tag testing if a real one exists
otherwise
> > >
> > > > >use the URL to not found image.
> > > > >
> > > > >-----Original Message-----
> > > > >From: CRANFORD, CHRIS [mailto:chris.cranford@setechusa.com]
> > > > >Sent: Tuesday, June 15, 2004 1:21 PM
> > > > >To: 'user@struts.apache.org'
> > > > >Subject: Rendering Images
> > > > >
> > > > >I'm curious if anyone has used or knows of an open-source image
> > > > >rendering servlet that permits rendering a "no image found" image
> > > > >file if the referenced image to be rendered does not exist on disk.
> > > > >
> > > > >Thanks
> > > > >
> > > > >_______________________________________________________
> > > > >Chris Cranford
> > > > >Programmer/Developer
> > > > >SETECH Inc. & Companies
> > > > >6302 Fairview Rd, Suite 201
> > > > >Charlotte, NC  28210
> > > > >Phone: (704) 362-9423, Fax: (704) 362-9409, Mobile: (704) 650-1042
> > > > >Email: chris.cranford@setechusa.com
> > > > >
> > > > >
> > > >
>---------------------------------------------------------------------
> > > > >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > > >For additional commands, e-mail: user-help@struts.apache.org
> > > > >
> > > >
>---------------------------------------------------------------------
> > > > >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > > >For additional commands, e-mail: user-help@struts.apache.org
> > > >
> > > >
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > >For additional commands, e-mail: user-help@struts.apache.org
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > >For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message