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:
<xkins>
<skin name="imageNotFound" defaultSkin="true">
<template name="image">
<processor
type="com.yourCompany.ImageTemplateProcessor"/>
<content><![CDATA[ <img src="$bodyContent"/ border='0'>
]]></content>
</template>
</skin>
</xkins>
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" %>
<xkins:template name="image">/images/myImage.gif</xkins:template>
Using <xkins:template name="image"> instead of <img> tag will use Xkins
template to render the image.
If /images/myImage.gif is not found, <xkins:template> 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 <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" <[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 <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:[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:
> > ><img
> > >src="http://www.mysites.com/proxyRemoteImage.do?remoteURL=<bean:wri
> > >te
> > >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 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]
> >
> >
> >
> >---------------------------------------------------------------------
> >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]
>
>
>
> ---------------------------------------------------------------------
> 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]
>
>
> ---------------------------------------------------------------------
> 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]
NOTA DE CONFIDENCIALIDAD
Este mensaje (y sus anexos) es confidencial, esta dirigido exclusivamente a las
personas direccionadas en el mail y puede contener informacion (i)de propiedad
exclusiva de Interbanking S.A. o (ii) amparada por el secreto profesional. Cualquier
opinion en el contenido, es exclusiva de su autor y no representa necesariamente la
opinion de Interbanking S.A. El acceso no autorizado, uso, reproduccion, o divulgacion
esta prohibido. Interbanking S.A no asumira responsabilidad ni obligacion legal alguna
por cualquier informacion incorrecta o alterada contenida en este mensaje. Si usted ha
recibido este mensaje por error, le rogamos tenga la amabilidad de destruirlo
inmediatamente junto con todas las copias del mismo, notificando al remitente. No
debera utilizar, revelar, distribuir, imprimir o copiar este mensaje ni ninguna de sus
partes si usted no es el destinatario. Muchas gracias.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
