Probably you're right, I've just begun using Wicket and am not very into the
inner workings of everything.

Thanks for the suggestion about decorating inputstream, should have thought
of it myself.

/Daniel


igor.vaynberg wrote:
> 
> another problem with close is that you would have to internally keep a
> reference to the inputstream(), and what if getinputstream() was
> called more then once because for example you are generating a xls, a
> csv, and a png all at once...then your close() has to keep track of
> multiple references?
> 
> -igor
> 
> On Tue, Nov 4, 2008 at 9:22 AM, Igor Vaynberg <[EMAIL PROTECTED]>
> wrote:
>> the problem is that we would have to pass around the inputstream and
>> iresourcestream unless we put the burden on you to make
>> getreinputstream() return the same inputstream for the same request...
>>
>> you can pretty easily create a decorator for inputstream and intercept
>> close(), its not perfect but it will work for right now while we
>> figure out what to do with iresourcestream#close
>>
>> -igor
>>
>> On Tue, Nov 4, 2008 at 1:35 AM, bjolletz <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Thanks for the reply!
>>>
>>> So you're suggesting that the close() method of the IResourceStream
>>> should
>>> be removed?
>>>
>>> Isn't there a point in having the close() method? In my case, by
>>> overriding
>>> the close() method, it would be possible to be notified when a download
>>> is
>>> complete. Don't know how else I would accomplish that (any
>>> suggestions?).
>>>
>>> Wouldn't it be a better idea to implement a close() method with default
>>> close behaviour in the abstract classes implementing the IResourceStream
>>> interface? That way, by extending one of these abstract resource stream
>>> classes, you dont have to mind about the close() method if you dont want
>>> to.
>>>
>>> /Daniel
>>>
>>>
>>>
>>> igor.vaynberg wrote:
>>>>
>>>> hmm, seems like a bug. it looks like we now close the input stream
>>>> directly instead of using close() which allows users not to have to
>>>> keep a reference to the stream. #close() can probably be removed.
>>>> please open a jira issue.
>>>>
>>>> -igor
>>>>
>>>> On Mon, Nov 3, 2008 at 3:28 AM, bjolletz <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> I would like to have a download link through which a user can download
>>>>> some
>>>>> bytearray from my database. So far no problem, I accomplish this by
>>>>> creating
>>>>> a new WebResource and implementing the getResourceStream method.
>>>>>
>>>>> My problem is that I would like to be notified when the user is
>>>>> finished
>>>>> downloading so that I can mark the downloaded item as downloaded in my
>>>>> database. I'm using an AbstractResourceStream and I thought I would be
>>>>> able
>>>>> to do this by overriding the close() method. However, the close method
>>>>> of
>>>>> the AbstractResourceStream never seems to be called.
>>>>>
>>>>> The implementation of the getResourceStream() method of my WebResource
>>>>> object:
>>>>>
>>>>>            public IResourceStream getResourceStream() {
>>>>>                return new AbstractResourceStream() {
>>>>>                    ByteArrayInputStream bais;
>>>>>                    public InputStream getInputStream() throws
>>>>> ResourceStreamNotFoundException {
>>>>>                        bais = getByteArrayInputStreamFromDB();
>>>>>                        return bais;
>>>>>                    }
>>>>>
>>>>>                    public void close() throws IOException {
>>>>>                        bais.close();
>>>>>                        markByteArrayAsDownloadedInDB();
>>>>>                    }
>>>>>                };
>>>>>            }
>>>>>
>>>>>
>>>>> Why is it that the close() method is never called? Is there a
>>>>> better/other
>>>>> way to do it? Is it at all possible to get a callback when a user is
>>>>> finished downloading the bytearray?
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>> /Daniel
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Browser-file-download-complete-callback-tp20300290p20300290.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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]
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Browser-file-download-complete-callback-tp20300290p20318122.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Browser-file-download-complete-callback-tp20300290p20342791.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to