Hello,
Yes, I did, realizing that it's a bit of a coarse solution. As it happens,
my application main function is to execute scripts for automated deployment
on a WebSphere platform, so users work with a JEE-application they select
from a wicket Ajax-textfield with application build versions
Hi,
On Sat, Nov 12, 2011 at 7:15 PM, hfriederichs h.friederi...@ohra.nl wrote:
I solved the issue by many trial and error sessions. Maybe I can spare
someone else this ordeal.
In Firefox an Chrome it now works as in IE, by adding this statement in the
init() of my WicketApplication:
I solved the issue by many trial and error sessions. Maybe I can spare
someone else this ordeal.
In Firefox an Chrome it now works as in IE, by adding this statement in the
init() of my WicketApplication:
getResourceSettings().setDefaultCacheDuration(Duration.NONE);
Regards, Hans Friederichs
Made a quick start, but couldn't reproduce the issue, it worked in FireFox...
Be it on a Jetty-server, and I have to cope with WebSphere...
Well, I'll strip my application down to the essentials that I have in the
quick start, and then build up one by one, I guess.
Many thanks, so far!
--
I will try these suggestions, but I't is quite frustrating that migrating
such a simple function causes so much problems.
In the meanwhile, I read the improvements in the caching mechanisms of
Wicket 1.5 on
https://cwiki.apache.org/WICKET/caching-in-wicket-15.html
It says:
/Caching is uniformly
In adddition: it works fine in IE8!
I'm using firefox 8.0;
Chrome 11.0.696.71: same problem as Firefox...
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Migrating-a-ResourceStreamRequestTarget-to-a-ResourceStreamRequestHandler-tp3998969p4017378.html
Sent from the
Hi,
On Mon, Nov 7, 2011 at 5:20 PM, hfriederichs h.friederi...@ohra.nl wrote:
I'm experiencing strange behaviour in migrating a ResourceStreamRequestTarget
to a ResourceStreamRequestHandler.
It worked fine in Wicket 1.4.x
I have a button for downloading an installation manual. Which manual
Hi Martin,
I forgot to mention: I tried that, but to no avail.
As the onClick isn't executed, the disableCaching isn't either.
Even when the onClick executes after two refreshes, it doesn't after that
single occasion.
Hans
--
View this message in context:
On Mon, Nov 7, 2011 at 5:50 PM, hfriederichs h.friederi...@ohra.nl wrote:
Hi Martin,
I forgot to mention: I tried that, but to no avail.
As the onClick isn't executed, the disableCaching isn't either.
Even when the onClick executes after two refreshes, it doesn't after that
single occasion.
I added this to my Page:
@Override
protected void setHeaders(WebResponse response) {
response.setHeader(Pragma, no-cache);
response.setHeader(Cache-Control, no-cache, max-age=0,
must-revalidate, no-store);
}
It doesn't help.
The onClick is still only executed once after
Can anyone explain to me why an onClick() is executed only once after two
refreshes and then never again?
What blocks the firing of this event? Maybe that gives me a clue so that I
can figure it out.
--
View this message in context:
On Mon, Nov 7, 2011 at 9:35 PM, hfriederichs h.friederi...@ohra.nl wrote:
Can anyone explain to me why an onClick() is executed only once after two
refreshes and then never again?
What blocks the firing of this event? Maybe that gives me a clue so that I
can figure it out.
See Firebug's Net
12 matches
Mail list logo
