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 02:33:52 GMT
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


Mime
View raw message