Hello,
I have an HTML markup page which has input type=text class=date
wicket:id=dateValue ONCHANGE=alert('input.onchange called')/
element. When the value in this field is set programmatically with
jQuery, e.g. $(input).val(new value) the input.onchange called
alert message pops up correctly.
Hi Robert,
Did someone offer you an answer with the fact that the class
JavaScriptFilteredIntoFooterHeaderResponse is final?
I've got the exact same question.
I mean surely I don't want ALL my JS to end up in the footer like
JavaScriptFilteredIntoFooterHeaderResponse method seems to be doing:
Hello,
We are currently migrating our applications from Wicket 1.4 to 1.5.
I have a problem with a pattern we use for logout, namely:
public class LogoutPage extends WebPage {
public LogoutPage() {
AuthenticatedWebSession session = AuthenticatedWebSession.get();
Try throwing RestartResponseException instead of calling setResponsePage.
This will stop the construction of your StopPage immediately.
I think setResponsePage is intended for use during the action part of a
request (e.g. onClick). 1.4 may just be more forgiving of its use elsewhere.
On Sun, Dec
Hi Dan,
On Sun, Dec 18, 2011 at 11:29 PM, Dan Retzlaff dretzl...@gmail.com wrote:
Try throwing RestartResponseException instead of calling setResponsePage.
This will stop the construction of your StopPage immediately.
Thanks for your answer.
Using throw new RestartResponseException(clazz);
I was able to get this to work after hours of suffering. I think the
problem was in my code that was triggering/handling change event.
Thanks
On Sun, Dec 18, 2011 at 12:28 PM, Alec Swan alecs...@gmail.com wrote:
Hello,
I have an HTML markup page which has input type=text class=date
Hi,
On Mon, Dec 19, 2011 at 12:18 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
Hello,
We are currently migrating our applications from Wicket 1.4 to 1.5.
I have a problem with a pattern we use for logout, namely:
public class LogoutPage extends WebPage {
public LogoutPage() {
