Hans,
Something like the following will probably work better for you. The key
concept is changing the request target. Sorry if my previous suggestion put
you down a dead end.
add(new Link<DeployVersion>("manualLink", deployVersionModel) {
@Override
public void onClick() {
IResourceStream manualStream = getManualStream(getModelObject());
if (manualStream == null) {
error("no manual, sorry!");
}
else {
RequestCycle.get().setRequestTarget(new
ResourceStreamRequestTarget(manualStream));
}
}
});
Regards,
Dan
On Thu, Aug 18, 2011 at 8:06 AM, hfriederichs <h.friederi...@ohra.nl> wrote:
> Firstly, thank you very much for your advice, it helps to a certain extend,
> but it also raises new questions.
>
> Unfortunately, there's only one way to determine whether a zip-file
> contains
> an installation manual. Since the zip-file is on another server (where the
> nexus repository resides), I have to read it from an InputStream. If there
> isn't an installation manual, this reading can take up to 10 seconds.
> Initially - when there's not a user entry yet, I can disable the
> download-button. But once an application code is entered, I only render
> meta
> information from all the zip-file versions, so the user can pick a desired
> version (usually the most recent build). Only when the form is submitted,
> or
> the new download button pressed, the corresponding zip-file is read, and
> only then I can determine whether it contains an installation manual. But I
> have to enable the button if there is a user entry. That can be a very
> disapointing user experience. He/she starts the appication, the button is
> disabled. He/she then enters an application code, en presses the now
> enabled
> button, only to find out that there isn't an installation manual...
>
> One question that comes to mind is: is my use case so exceptional? A button
> for a resource is pressed, all I want is a nice feedback in case a resource
> isn't available...
> Personally, I'm not a great fan of disabling or 'invisibling' buttons. I
> adhere to the five-year-old-boy-philosophy concerning buttons: you should
> /allways/ be able to press them, that's what buttons are for.
>
> Your alternative (using the RestartResponseException) solves the 'white
> screen-problem', but there are a few drawbacks:
> - The URL of my application after pressing the button changes from
> http://localhost:9081/deploy/ to
>
> http://localhost:9081/deploy/?wicket:interface=:3:deploytabs:panel:deployForm:downloadinstallationmanual::IResourceListener:
> :.
> I really like Wicket, but this is so annoying. Who wants this? I just want
> my original url back - and yes, I read all the posts on mount strategies.
> - What's worse, the user has entered an application code that generates
> other field values (like a dropdownlists for the versions). When the page
> is
> reloaded after a RestartResponseException, I want to initialize it with the
> afore entered data. I managed to do that using PageParameters (or the
> Session), but in that case the refresh button will always generate a
> 'prefilled' page, with the values of the lat entered application code.
>
> Regards, Hans Friederichs
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/How-to-Handle-ResourceStreamNotFoundException-tp3749331p3752826.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
