On Tue, February 19, 2013, Martin Grigorov wrote:
> This is how it works.
> #replaceAllRequestHandlers() throws an exception to stop doing whatever it
> does at the moment.
> #scheduleRequestHandlerAfterCurrent() just appends a new RH to the list and
> executes it when all previous are executed.
On Tue, 19 Feb 2013 09:23:28 +0100
Martin Dietze wrote:
> IMO the problem is not that much how the response is generated,
> but how the component is already uses within the system. At
> this point creating a download link is simple as it simply is a
> BookmarkableLink to that page with the approp
On Tue, Feb 19, 2013 at 11:14 AM, Martin Dietze wrote:
> On Tue, February 19, 2013, Martin Grigorov wrote:
>
> > You can use requestCycle.replaceAllRequestHandlers(new
> > ResourceRequestHandler(new ByteArrayResource(byteArray))) in your page
> code.
> > This will stop the page rendering and will
On Tue, February 19, 2013, Martin Grigorov wrote:
> You can use requestCycle.replaceAllRequestHandlers(new
> ResourceRequestHandler(new ByteArrayResource(byteArray))) in your page code.
> This will stop the page rendering and will return the byte[] from this
> response. You can still configure the
Hi,
You can use requestCycle.replaceAllRequestHandlers(new
ResourceRequestHandler(new ByteArrayResource(byteArray))) in your page code.
This will stop the page rendering and will return the byte[] from this
response. You can still configure the ByteArrayResource - filename,
disposition, etc.
On
On Mon, February 18, 2013, Carl-Eric Menzel wrote:
> For generating binaries, I would *really* recommend doing this change.
> Pages simply are not a good fit for that. Also, it shouldn't be that
> big of a change, since you're writing to the Response anyway. Within
> AbstractResource's WriteCallba
On Mon, 18 Feb 2013 19:03:41 +0100
Martin Dietze wrote:
> On Mon, February 18, 2013, Carl-Eric Menzel wrote:
>
> > Is there a particular reason you're using a page?
>
> One - unfortunately - big reason: it's legacy code (most of
> which I did not even write myself). The Wicket upgrade is badly
On Mon, February 18, 2013, Carl-Eric Menzel wrote:
> Is there a particular reason you're using a page?
One - unfortunately - big reason: it's legacy code (most of
which I did not even write myself). The Wicket upgrade is badly
needed for browser compatibiy, however I don't want to change
code if
I would simply do this in a Resource (e.g. subclass AbstractResource)
rather than in a page. Resources are for binary data, Pages are for
markup. That way you don't have to mess around in any way with the
response or anything like that.
Is there a particular reason you're using a page?
Carl-Eric
