Re: downloading dynamic images
Re: downloading dynamic images
- Subject: Re: downloading dynamic images
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 13 May 2003 11:29:29 -0500
I'm going to guess that you are using WOImage with the 'data' binding, right?
Okay, WOImage with the data binding uses the WOResourceManager.setData
method to cache/restore the dynamic image. But there are some serious
problems with this design. There are two ways you can use this feature,
each with their own problem:
1) Without binding the 'key' binding of WOImage. This is probably what you
are doing now. The image will only be deliver-able ONCE. That is, a URL is
generated to the dynamic image. The first time that URL is accessed, the
image is delivered. Then the image is uncached from memory. Subsequent
requests to that same URL will fail. I forget if an HTTP error is returned,
or just a 0 byte response, or what---but the image is not returned. This
is what is happenign to you. (In those cases where it works, the user's
browser is using it's own cache; in those cases where it doesn't, the
browser is making the same request again to the server).
2) You bind the 'key' binding of the WOImage. Now, the URL that is
generated has this key in it. If you use the same key for two different
images, the second one will 'overwrite' the first! However, the app will
keep responding to that URL with the correct image, indefinitely. This is
good. Bad, however, is that the image is stored in memory by the
WOResourceManger indefinitely too. I forget if it's until the session
terminates, or until the app terminates. You can also manually remove it
from memory (invalidating the URL!) with the WOResourceManager api.
So binding the 'key' to the WOImage may be a solution, but there's a
potential for memory leak there, so it's not a very good one. But it may
work for you.
If you don't want to do that... one option would be storing the dynamic
image in the file system somewhere, and binding the 'url' of the WOImage to
point to it, rather than using the 'data' binding. But now you need to make
sure to delete the file on disk when you are done! Although I think
there's api in the Java File class to have the file automatically deleted
when the app shuts down, which may be sufficient if you have enough disk
space.
Alternately... at one point I wrote a WOImage replacement that handled the
'data' binding without using the WOResourceManager cache. Yes, I've found
it. I don't think the Apple list allows attachments, so I include all the
files for the component as text below. I believe it works fine, but use it
at your own risk. But it should allow indefinite requests to the image
URL, until the parent component is removed from the WO page cache, which is
generally exactly what you want.
---------------------------------------------
InMemoryImageElement.java
---------------------------------------------
// Generated by the WebObjects Wizard Thu Jul 18 16:33:56 America/Chicago 2002
import com.webobjects.foundation.*;
import com.webobjects.appserver.*;
import com.webobjects.eocontrol.*;
import com.webobjects.eoaccess.*;
public class InMemoryImageElement extends WOComponent {
public InMemoryImageElement(WOContext context) {
super(context);
}
public boolean synchronizesVariablesWithBindings() {
return false;
}
public String contentDeliveryURL() {
return context().componentActionURL();
}
public WOActionResults deliverImage() {
WOResponse response = new WOResponse();
response.setHeader(valueForBinding("MIMEType").toString(),
"content-type");
response.setContent((NSData) valueForBinding("data"));
return response;
}
}
----------------------------------------------------
InMemoryImageElement.api
-----------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<wodefinitions>
<wo class="InMemoryContentElement" wocomponentcontent="false">
<binding name="data"/>
<binding name="MIMEType"/>
<validation message="'data' is a required binding">
<unbound name="data"/>
</validation>
<validation message="'MIMEType' is a required
binding">
<unbound name="MIMEType"/>
</validation>
</wo>
</wodefinitions>
---------------------------------------
InMemoryImageElement.html
----------------------------------------
<WEBOBJECT NAME=GenericElement1></WEBOBJECT>
----------------------------------------
InMemoryImageElement.wod
----------------------------------------
GenericElement1: WOGenericElement {
elementName = "IMG";
invokeAction = deliverImage;
src = contentDeliveryURL;
}
At 04:39 PM 5/9/2003 -0400, Tom Pelaia wrote:
I've noticed a problem copying dynamic images off of WebObjects pages. If
I have a page where I display an image that I get from a database, the
image appears fine on the web page but the user cannot consistently copy
those images from the web page to their desktop or create a web page
archive with the image included. Most of the time the image just appears
with the name "wr" on the desktop and has zero bytes. Sometimes (even on
the very same images) the image will actually be copied properly including
the correct extension.
In the web component that displays the images I allow WebObjects to assign
names to the images.
Has anyone else experienced this problem before and does anyone know of a
solution that works consistently.
thanks,
-tom
--
Tom Pelaia
SNS Project, 701 Scarboro Road, MS-6473, Oak Ridge, TN 37830
phone: (865)574-6421, fax: (865)574-6617
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.