struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hookom, Jacob" <Jacob.Hoo...@redline.mckhboc.com>
Subject RE: Rendering Images
Date Wed, 16 Jun 2004 15:34:14 GMT
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


Mime
View raw message