Re: Rendering Images
At 09:31 AM 6/17/2004, Niall Pemberton wrote: Firstly, I found this like helpfull: http://www.mnot.net/cache_docs/ Niall, Thanks, Niall, this was very helpful. You information led me to the granddaddy of all information on this: http://www.ietf.org/rfc/rfc2616.txt. This document tells it all. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rendering Images
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" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Struts Users
Mailing List" <[EMAIL PROTECTED]>
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 tag doesn't know whether the image exists or not, all
it
> >does is render the 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" <[EMAIL PROTECTED]>
> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> >Sent: Wednesday, June 16, 2004 5:15 PM
> >Subject: RE: Rendering Images
> >
> >
> > > YES! ;-)
> > >
> > > -Original Message-
> > > From: Linck, Ken [mailto:[EMAIL PROTECTED]
> > > 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 tag where you could specify an
alternate
> > > image instead.
> > >
> > > It seems like a common challenge in many places.
> > >
> > > -Original Message-
> > > From: mike [mailto:[EMAIL PROTECTED]
> > > 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:[EMAIL PROTECTED]
> > > >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
RE: Rendering Images
I was thinking that perhaps the problem of rendering an alternative
image when the image is not found could be resolved with Xkins.
You could create a ImageTemplateProcessor. This processor can receive
the image name, verify if exists in the web server disk and if true,
return the html image tag with the image, otherwise, return an
alternative image:
In the Xkins definition file, do as follows:
The ImageTemplateProcessor can be like this:
package com.yourCompany;
public class ImageTemplateProcessor extends VelocityTemplateProcessor {
public static final String IMG_NOT_FOUND =
"/images/imgNotFound.gif";
public void process(Template input, Context context,
OutputStream os) throws XkinsException {
//receives the bodyContent parameter with the image name
String image =
(String)context.getParameters().get(XkinProcessor.JSP_BODY);
//check if the file exists (you should preppend the real
path... It's not the purpouse of this snippet)
String imageRealPath = this.getRealPath(image); //you
should implement getRealPath method...
if(!(new File(imageRealPath)).exists()) { //the file is
not found in the server...
//replaces the file name for the imageNotFound
context.getParameters().put(XkinProcessor.JSP_BODY, IMG_NOT_FOUND);
}
//lets VelocityTemplateProcessor process the template,
with the original image or
//with the IMG_NOT_FOUND image if original does not
exists.
super.process(input, context, os);
}
}
And finally, in the JSP, you should do as follows:
<%@ taglib uri="/WEB-INF/tld/xkins.tld" prefix="xkins" %>
/images/myImage.gif
Using instead of tag will use Xkins
template to render the image.
If /images/myImage.gif is not found, tag will render
with /images/imgNotFound.gif.
Besides, you could orgaanize your images paths with Xkins Paths or add
more parameters to the template (like sizes, etc).
Cheers.
Guillermo.
-Original Message-
From: Niall Pemberton [mailto:[EMAIL PROTECTED]
Sent: Miércoles, 16 de Junio de 2004 11:34 p.m.
To: Struts Users Mailing List
Subject: Re: Rendering Images
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 tag doesn't know whether the image exists or not, all
it does is render the 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" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Wednesday, June 16, 2004 5:15 PM
Subject: RE: Rendering Images
> YES! ;-)
>
> -Original Message-
> From: Linck, Ken [mailto:[EMAIL PROTECTED]
> 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 tag where you could
> specify an alternate image instead.
>
> It seems like a common challenge in many places.
>
> -Original Message-----
> From: mike [mailto:[EMAIL PROTECTED]
> 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.g
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 tag doesn't know whether the image exists or not, all it does is render the 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" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Wednesday, June 16, 2004 5:15 PM Subject: RE: Rendering Images > YES! ;-) > > -Original Message- > From: Linck, Ken [mailto:[EMAIL PROTECTED] > 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 tag where you could specify an alternate > image instead. > > It seems like a common challenge in many places. > > -Original Message- > From: mike [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > >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
Re: Rendering Images
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 tag doesn't know whether the image exists or not, all it does is render the 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" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Wednesday, June 16, 2004 5:15 PM Subject: RE: Rendering Images > YES! ;-) > > -Original Message- > From: Linck, Ken [mailto:[EMAIL PROTECTED] > 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 tag where you could specify an alternate > image instead. > > It seems like a common challenge in many places. > > -Original Message- > From: mike [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > >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
RE: Rendering Images
No worries, Ken. Seeing you thinking the same way was a bit edifying. I am not sure why people continue to use URLs when protocols will do and are so much general a solution. I use this, by the way, to convert all my jpegs to Flash inside ActionScript without having to introduce any image into Flash, so that all my Flash delivery is handled by ONE SWF file. Cool, eh? At 08:50 AM 6/16/2004, Linck, Ken wrote: Sorry..didnt make the connection initially between your initial proposal and mine. Some subtle differences but mostly identical. -Original Message- From: mike [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 11: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: >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=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:[EMAIL PROTECTED] >Sent: Tuesday, June 15, 2004 4:44 PM >To: '[EMAIL PROTECTED]' >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 &
RE: Rendering Images
YES! ;-) -Original Message- From: Linck, Ken [mailto:[EMAIL PROTECTED] 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 tag where you could specify an alternate image instead. It seems like a common challenge in many places. -Original Message- From: mike [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] >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: > > >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL= >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 ex
RE: Rendering Images
On a sidenote, it would be kind of nice to add some kind of imageNotFound property to the tag where you could specify an alternate image instead. It seems like a common challenge in many places. -Original Message- From: mike [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] >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: > > >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL= >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.
RE: Rendering Images
Sorry..didnt make the connection initially between your initial proposal and mine. Some subtle differences but mostly identical. -Original Message- From: mike [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 11: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: >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=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:[EMAIL PROTECTED] >Sent: Tuesday, June 15, 2004 4:44 PM >To: '[EMAIL PROTECTED]' >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: [EMAIL PROTECTED] >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 f
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:[EMAIL PROTECTED] 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: >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=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:[EMAIL PROTECTED] >Sent: Tuesday, June 15, 2004 4:44 PM >To: '[EMAIL PROTECTED]' >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 image
RE: Rendering Images
The reason is that I use jsp behind WEB-INF and want to avoid all the difficulties with HTML and URLs behind WEB-INF. It also gives me a great interface for solving all sorts of problems like this one. This allows the page designer just to ask for whatever they want in a standard way that never changes no matter what and lets the backend people decide how they get it. You would be surprised how helpful this can be. For example, I can use this inside Flash ActionScript when normal URLs would cause huge difficulties. No matter the context, when you take the URL out of the mix and use an Action protocol, this provides a standard solution. I cannot tell you how much this little goodie helps me Jacob. Even if I did not use the jsp behind WEB-INF, I would do this. I have discovered as I go along many, many uses for this. 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:[EMAIL PROTECTED] 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: >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=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:[EMAIL PROTECTED] >Sent: Tuesday, June 15, 2004 4:44 PM >To: '[EMAIL PROTECTED]' >Subject: RE: Rendering Images > >Ken, >
RE: Rendering Images
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:[EMAIL PROTECTED] 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: >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=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:[EMAIL PROTECTED] >Sent: Tuesday, June 15, 2004 4:44 PM >To: '[EMAIL PROTECTED]' >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: [EMAIL PROTECTED] >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
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: " 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:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 4:44 PM To: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 1:21 PM To: '[EMAIL PROTECTED]' 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 Pho
RE: Rendering Images
With respect, I think this is a great solution (and the exact one I offered
long ago in this thread with the code to do it) but a wrong description of
the problem. He is trying to create a response and as part of that has to
request an image, which is a typical and unexceptional requirement, but
must be described this way. I have given him the model part of the action
that serves such images. The facade and the action itself follow:
public class ResourceFacade {
public ResourceFacade() {
super();
}
public void handle(HttpServletRequest request,
HttpServletResponse response) {
new WriteResponse().write(new InitResponse().init(request, response),
response);
return;
}
} ///;-) Michael McGrady HomeSites
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
new ResourceFacade().handle(request, response);
return null;
}
} /// ;-) Michael McGrady HomeSites
The code I gave you before had .CRACKWILLOW instead of .do.
Regards,
Michael McGrady
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:
" 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:[EMAIL PROTECTED]
Sent: Tuesday, June 15, 2004 4:44 PM
To: '[EMAIL PROTECTED]'
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: [EMAIL PROTECTED]
Sent: 6/15/2004 2:32 PM
Subject: RE: Rendering Images
Just curious but why not just manually make this file once and return
RE: Rendering Images
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: " 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:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 4:44 PM To: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 1:21 PM To: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Rendering Images
This solution, Wendy, is just a less sophisticated version of what I said. I think this is the way to go, however. Not that the exist() method of File works for files on "foreign" computers. Michael At 03:13 PM 6/15/2004, Wendy Smoak wrote: > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > Actually, I think you can do this pretty easily with CSS... Here's a thread that might be helpful... http://www.webmasterworld.com/forum91/1871.htm -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Rendering Images
That does not make any difference, Wendy. Granted that if you want to collect a resource with a URL that is different than using a file system protocol in some senses. However, for purposes of what I said, it makes no difference. The code I get these images with in fact is the following (substituting protocol for URL): border='0' width='95%' height='100%' valign='bottom' align='right'> This code allow the image to be anywhere in the world. Those issues are decided in the model of the MVC. At 02:34 PM 6/15/2004, Wendy Smoak wrote: > From: mike [mailto:[EMAIL PROTECTED] > I deliver all resources with the following code (you have to > fill in some > details). You can easily see where you can test for the > availablitlity of > the image. Anyway, you can always test with, as I said > before the exists() method of the File class. Except that he said the images live on a different web server, which I took to mean that the file system was not accessible directly, the only way to get to the images is with the URL. The only thing I'm coming up with is a Servlet that would use the URL to read in the bytes of the image, and either send them as the response, or else read in the 'not found' image and send that. It just doesn't seem very efficient, and I think it should be pushed off onto the web server rather than the Servlet container. With a million items, I'm guessing this is not running on a single Tomcat instance... -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Rendering Images
Render Time - Missing Images
#prdNoImg {
width: 300px; height: 75px;
background-image: url(img/bg.gif);
background-repeat: no-repeat;
}
#prdImg {
width: 300px; height: 75px;
background-image: url(img/b_search.gif);
background-repeat: no-repeat;
}
You would define the #prdImg's background image at server time through jstl
or a scriplet(*boo*). So it would be:
background-image: url();
This works because if the background image of #prdImg is not found, the
browser just won't render anything, whereas it would normally render a
broken image icon. If the image is found, then it will show up over top of
#prdNoImg's.
You would want to play around with the dimensions too. If you would have
any other CSS questions, look at www.w3schools.com
Jacob Hookom
Senior Analyst/Programmer
McKesson Medical-Surgical, Minnesota
"don't buy a dog and bark yourself"
-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 15, 2004 5:14 PM
To: Struts Users Mailing List
Subject: RE: [OT] RE: Rendering Images
> From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
> Actually, I think you can do this pretty easily with CSS...
Here's a thread that might be helpful...
http://www.webmasterworld.com/forum91/1871.htm
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Rendering Images
> From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > Actually, I think you can do this pretty easily with CSS... Here's a thread that might be helpful... http://www.webmasterworld.com/forum91/1871.htm -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Rendering Images
Actually, I think you can do this pretty easily with CSS... Do all your images have the same dimensions? -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 4:34 PM To: Struts Users Mailing List Subject: RE: [OT] RE: Rendering Images > From: mike [mailto:[EMAIL PROTECTED] > I deliver all resources with the following code (you have to > fill in some > details). You can easily see where you can test for the > availablitlity of > the image. Anyway, you can always test with, as I said > before the exists() method of the File class. Except that he said the images live on a different web server, which I took to mean that the file system was not accessible directly, the only way to get to the images is with the URL. The only thing I'm coming up with is a Servlet that would use the URL to read in the bytes of the image, and either send them as the response, or else read in the 'not found' image and send that. It just doesn't seem very efficient, and I think it should be pushed off onto the web server rather than the Servlet container. With a million items, I'm guessing this is not running on a single Tomcat instance... -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Rendering Images
> From: mike [mailto:[EMAIL PROTECTED] > I deliver all resources with the following code (you have to > fill in some > details). You can easily see where you can test for the > availablitlity of > the image. Anyway, you can always test with, as I said > before the exists() method of the File class. Except that he said the images live on a different web server, which I took to mean that the file system was not accessible directly, the only way to get to the images is with the URL. The only thing I'm coming up with is a Servlet that would use the URL to read in the bytes of the image, and either send them as the response, or else read in the 'not found' image and send that. It just doesn't seem very efficient, and I think it should be pushed off onto the web server rather than the Servlet container. With a million items, I'm guessing this is not running on a single Tomcat instance... -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] RE: Rendering Images
I deliver all resources with the following code (you have to fill in some
details). You can easily see where you can test for the availablitlity of
the image. Anyway, you can always test with, as I said before the exists()
method of the File class.
public class InitResponse {
public InitResponse() {
}
public String init(HttpServletRequest request,
HttpServletResponse response) {
String fileType = (request.getParameter(ImageConstant.TYPE)).intern();
String fileName = request.getParameter(ImageConstant.NAME);
String contentType = null;
String file = null;
if (ImageConstant.CSS_FILE.equals(fileType)) {
contentType = ImageConstant.CSS_CONTENT;
file = ImageConstant.CSS_LOCATION;
} else if (ImageConstant.JPEG_FILE.equals(fileType)) {
contentType = ImageConstant.JPEG_CONTENT;
file = ImageConstant.JPEG_LOCATION;
} else if (ImageConstant.PNG_FILE.equals(fileType)) {
contentType = ImageConstant.PNG_CONTENT;
file = ImageConstant.PNG_LOCATION;
} else if (ImageConstant.FLASH_FILE.equals(fileType)) {
contentType = ImageConstant.FLASH_CONTENT;
file = ImageConstant.FLASH_LOCATION;
} else if (ImageConstant.GIF_FILE.equals(fileType)) {
contentType = ImageConstant.GIF_CONTENT;
file = ImageConstant.GIF_LOCATION;
} else if (ImageConstant.TEXT_FILE.equals(fileType)) {
contentType = ImageConstant.TEXT_CONTENT;
file = ImageConstant.TEXT_LOCATION;
} else if (ImageConstant.HTML_FILE.equals(fileType)) {
contentType = ImageConstant.HTML_CONTENT;
file = ImageConstant.HTML_LOCATION;
} else if (ImageConstant.APPLET_FILE.equals(fileType)) {
contentType = ImageConstant.APPLET_CONTENT;
file = ImageConstant.APPLET_LOCATION;
}
response.setContentType(contentType);
return Classpath.WEB_INF + file + fileName;
}
}
public class WriteResponse {
public WriteResponse() {
}
public static void write(String fileName,
HttpServletResponse response) {
response.setHeader("Cache-Control", "");
response.setHeader("Pragma", "");
response.setHeader("Expires", "");
response.addHeader("Content-Disposition","filename=" + fileName);
try {
FileInputStream fis = new FileInputStream(fileName);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes= new byte[bis.available()];
OutputStreamos = response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log("log.error","WriteResponse: problem file (B) is: " +
fileName + "\n" + StackTrace.trace(ioe));
}
}
}
At 02:05 PM 6/15/2004, Wendy Smoak wrote:
> From: CRANFORD, CHRIS [mailto:[EMAIL PROTECTED]
> 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.
How often do you get new images? If the data is bad, resist programming
around it, and FIX it. (Pet peeve of mine, I've spent hours writing
around "issues" that were really training/data entry problems.) Maybe
there's a problem with a procedure when new items are added. I'm
guessing, of course...
I'd be more inclined to keep a closer eye on the logs (which will show
the 404's when a non-existent resource is requested) and write a
standalone program to run at night daily/weekly/monthly to go through
the database and check that each image is where it's supposed to be.
I use Apache to serve images and other static resources, leaving the
dynamic stuff to Tomcat, but I don't have any idea how to convince
Apache to send an alternate image instead of a 404.
If I had to do it in Tomcat, I'd map a Servlet to the .jpg file
extension, read in the requested image, and either send it or send the
'no image found' image out to the browser.
--
Wendy Smoak
Application Systems Analyst, Sr.
ASU IA Information Resources Management
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Rendering Images
When you're talking a dataload of over 1 million items every month or so, it gets to be very time consuming and tedious to go behind suppliers to insure their "data" is always correct :-). Unfortunately, its kind of the nature of our business. At any rate, have an example of how to put a filter on catching these file types and serving it back if it exists; otherwise serve back a generic "not found" image instead? Thanks, Chris -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 5:05 PM To: Struts Users Mailing List Subject: [OT] RE: Rendering Images > From: CRANFORD, CHRIS [mailto:[EMAIL PROTECTED] > 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. How often do you get new images? If the data is bad, resist programming around it, and FIX it. (Pet peeve of mine, I've spent hours writing around "issues" that were really training/data entry problems.) Maybe there's a problem with a procedure when new items are added. I'm guessing, of course... I'd be more inclined to keep a closer eye on the logs (which will show the 404's when a non-existent resource is requested) and write a standalone program to run at night daily/weekly/monthly to go through the database and check that each image is where it's supposed to be. I use Apache to serve images and other static resources, leaving the dynamic stuff to Tomcat, but I don't have any idea how to convince Apache to send an alternate image instead of a 404. If I had to do it in Tomcat, I'd map a Servlet to the .jpg file extension, read in the requested image, and either send it or send the 'no image found' image out to the browser. -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: Rendering Images
> From: CRANFORD, CHRIS [mailto:[EMAIL PROTECTED] > 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. How often do you get new images? If the data is bad, resist programming around it, and FIX it. (Pet peeve of mine, I've spent hours writing around "issues" that were really training/data entry problems.) Maybe there's a problem with a procedure when new items are added. I'm guessing, of course... I'd be more inclined to keep a closer eye on the logs (which will show the 404's when a non-existent resource is requested) and write a standalone program to run at night daily/weekly/monthly to go through the database and check that each image is where it's supposed to be. I use Apache to serve images and other static resources, leaving the dynamic stuff to Tomcat, but I don't have any idea how to convince Apache to send an alternate image instead of a 404. If I had to do it in Tomcat, I'd map a Servlet to the .jpg file extension, read in the requested image, and either send it or send the 'no image found' image out to the browser. -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Rendering Images
We have the same environment and simply put a filter on the image web app to catch *.jpg, then your main app doesn't have any logic to worry about, or even "pre-fetch" images every time which would be a HUGE waste of resources. -Original Message- From: CRANFORD, CHRIS [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 3:44 PM To: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 1:21 PM To: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 1:21 PM To: '[EMAIL PROTECTED]' 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: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
