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 > >