[jira] [Commented] (WICKET-6440) SecuredRemoteAddressRequestWrapperFactory doesn't make request secure

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153024#comment-16153024
 ] 

Hendy Irawan commented on WICKET-6440:
--

yes you read that same as me.

when == false is removed that becomes:

if the request is not secure and *matches* any of the secured addresses then it 
needs a wrapper.

seems straightforward to me.

> SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
> -
>
> Key: WICKET-6440
> URL: https://issues.apache.org/jira/browse/WICKET-6440
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
>Priority: Minor
>
> I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:
> {noformat}
> 2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3] 
> ecuredRemoteAddressRequestWrapperFactory : Incoming request 
> uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
>  with originalSecure='false', remoteAddr='127.0.0.1' will be seen with 
> newSecure='false'
> {noformat}
> Since remoteAddr is 127.* then it should be treated as secure, per 
> documentation.
> This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy: 
> (i.e. need to remove {{==false}})
> {code:java}
>   @Override
>   public boolean needsWrapper(final HttpServletRequest request)
>   {
>   return !request.isSecure() &&
>   matchesOne(request.getRemoteAddr(), 
> config.securedRemoteAddresses) == false;
>   }
> {code}
> Additionally, newSecure = should be {{xRequest.isSecure()}} :
> {code:java}
>   HttpServletRequest xRequest = super.getWrapper(request);
>   if (log.isDebugEnabled())
>   {
>   log.debug("Incoming request uri=" + 
> request.getRequestURI() + " with originalSecure='" +
>   request.isSecure() + "', remoteAddr='" + 
> request.getRemoteAddr() +
>   "' will be seen with newSecure='" + 
> request.isSecure() + "'");
>   }
> {code}
> Related to WICKET-3015.
> Tag [~jdonnerstag] [~pete]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6440) SecuredRemoteAddressRequestWrapperFactory doesn't make request secure

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124887#comment-16124887
 ] 

Hendy Irawan commented on WICKET-6440:
--

Not really, but I've confirmed in my own app that making the changes I 
described does result in expected behavior.

This bug is most likely a couple of unintentional typos.

> SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
> -
>
> Key: WICKET-6440
> URL: https://issues.apache.org/jira/browse/WICKET-6440
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
>Priority: Minor
>
> I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:
> {noformat}
> 2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3] 
> ecuredRemoteAddressRequestWrapperFactory : Incoming request 
> uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
>  with originalSecure='false', remoteAddr='127.0.0.1' will be seen with 
> newSecure='false'
> {noformat}
> Since remoteAddr is 127.* then it should be treated as secure, per 
> documentation.
> This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy: 
> (i.e. need to remove {{==false}})
> {code:java}
>   @Override
>   public boolean needsWrapper(final HttpServletRequest request)
>   {
>   return !request.isSecure() &&
>   matchesOne(request.getRemoteAddr(), 
> config.securedRemoteAddresses) == false;
>   }
> {code}
> Additionally, newSecure = should be {{xRequest.isSecure()}} :
> {code:java}
>   HttpServletRequest xRequest = super.getWrapper(request);
>   if (log.isDebugEnabled())
>   {
>   log.debug("Incoming request uri=" + 
> request.getRequestURI() + " with originalSecure='" +
>   request.isSecure() + "', remoteAddr='" + 
> request.getRemoteAddr() +
>   "' will be seen with newSecure='" + 
> request.isSecure() + "'");
>   }
> {code}
> Related to WICKET-3015.
> Tag [~jdonnerstag] [~pete]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (WICKET-6440) SecuredRemoteAddressRequestWrapperFactory doesn't make request secure

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6440:
-
Description: 
I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:


{noformat}
2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3] 
ecuredRemoteAddressRequestWrapperFactory : Incoming request 
uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
 with originalSecure='false', remoteAddr='127.0.0.1' will be seen with 
newSecure='false'
{noformat}

Since remoteAddr is 127.* then it should be treated as secure, per 
documentation.

This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy: (i.e. 
need to remove {{==false}})

{code:java}
@Override
public boolean needsWrapper(final HttpServletRequest request)
{
return !request.isSecure() &&
matchesOne(request.getRemoteAddr(), 
config.securedRemoteAddresses) == false;
}
{code}

Additionally, newSecure = should be {{xRequest.isSecure()}} :

{code:java}
HttpServletRequest xRequest = super.getWrapper(request);

if (log.isDebugEnabled())
{
log.debug("Incoming request uri=" + 
request.getRequestURI() + " with originalSecure='" +
request.isSecure() + "', remoteAddr='" + 
request.getRemoteAddr() +
"' will be seen with newSecure='" + 
request.isSecure() + "'");
}
{code}

Related to WICKET-3015.
Tag [~jdonnerstag] [~pete]

  was:
I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:


{noformat}
2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3] 
ecuredRemoteAddressRequestWrapperFactory : Incoming request 
uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
 with originalSecure='false', remoteAddr='127.0.0.1' will be seen with 
newSecure='false'
{noformat}

Since remoteAddr is 127.* then it should be treated as secure, per 
documentation.

This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy: (i.e. 
need to remove {{==false}})

{code:java}
@Override
public boolean needsWrapper(final HttpServletRequest request)
{
return !request.isSecure() &&
matchesOne(request.getRemoteAddr(), 
config.securedRemoteAddresses) == false;
}
{code}

Related to WICKET-3015.
Tag [~jdonnerstag] [~pete]


> SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
> -
>
> Key: WICKET-6440
> URL: https://issues.apache.org/jira/browse/WICKET-6440
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
>
> I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:
> {noformat}
> 2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3] 
> ecuredRemoteAddressRequestWrapperFactory : Incoming request 
> uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
>  with originalSecure='false', remoteAddr='127.0.0.1' will be seen with 
> newSecure='false'
> {noformat}
> Since remoteAddr is 127.* then it should be treated as secure, per 
> documentation.
> This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy: 
> (i.e. need to remove {{==false}})
> {code:java}
>   @Override
>   public boolean needsWrapper(final HttpServletRequest request)
>   {
>   return !request.isSecure() &&
>   matchesOne(request.getRemoteAddr(), 
> config.securedRemoteAddresses) == false;
>   }
> {code}
> Additionally, newSecure = should be {{xRequest.isSecure()}} :
> {code:java}
>   HttpServletRequest xRequest = super.getWrapper(request);
>   if (log.isDebugEnabled())
>   {
>   log.debug("Incoming request uri=" + 
> request.getRequestURI() + " with originalSecure='" +
>   request.isSecure() + "', remoteAddr='" + 
> request.getRemoteAddr() +
>   "' will be seen with newSecure='" + 
> request.isSecure() + "'");
>   }
> {code}
> Related to WICKET-3015.
> Tag [~jdonnerstag] [~pete]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (WICKET-6440) SecuredRemoteAddressRequestWrapperFactory doesn't make request secure

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-6440:


 Summary: SecuredRemoteAddressRequestWrapperFactory doesn't make 
request secure
 Key: WICKET-6440
 URL: https://issues.apache.org/jira/browse/WICKET-6440
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 7.8.0
Reporter: Hendy Irawan


I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:


{noformat}
2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3] 
ecuredRemoteAddressRequestWrapperFactory : Incoming request 
uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
 with originalSecure='false', remoteAddr='127.0.0.1' will be seen with 
newSecure='false'
{noformat}

Since remoteAddr is 127.* then it should be treated as secure, per 
documentation.

This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy: (i.e. 
need to remove {{==false}})

{code:java}
@Override
public boolean needsWrapper(final HttpServletRequest request)
{
return !request.isSecure() &&
matchesOne(request.getRemoteAddr(), 
config.securedRemoteAddresses) == false;
}
{code}

Related to WICKET-3015.
Tag [~jdonnerstag] [~pete]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-3015) add (even more) support for front-end proxies (schema, client ip, ...)

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117673#comment-16117673
 ] 

Hendy Irawan commented on WICKET-3015:
--

[~jdonnerstag] [~pete] Can you show me how to use this? (background: 
http://apache-wicket.1842946.n4.nabble.com/How-to-quot-force-quot-page-redirects-to-HTTPS-td4678479.html)

The JavaDoc documentation mentions {{fr.xebia.servlet.filter.XForwardedFilter}} 
which seems to be a different way.

> add (even more) support for front-end proxies (schema, client ip, ...)
> --
>
> Key: WICKET-3015
> URL: https://issues.apache.org/jira/browse/WICKET-3015
> Project: Wicket
>  Issue Type: Wish
>  Components: wicket
>Reporter: Peter Ertl
>Assignee: Juergen Donnerstag
> Fix For: 1.5-RC1
>
>
> Would be nice to have something like this
>   http://code.google.com/p/xebia-france/wiki/XForwardedFilter
> in core. People's life would be a lot easier and it's really quite easy to 
> add (actually just parsing a few headers and wrapping the original request)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless it's a 
stateless form, which then goes back to top. Either way they *still* have to 
scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with working Ajax 
will see it and only for ajax forms. Else it back to top and they won't see it. 
Either way they *still* have to scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
leave and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg!

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. There needs to be some "buffer" on top when scrolling. For example, most 
websites have a floating navbar on top, and scrolling right to a panel will 
make the panel covered by the navbar. So there should be a buffer value, 20 is 
a sane minimal value for comfort, but some websites (like mine) will need to 
adjust it to 50 or something else.

4. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

(5. I know an edge case: horizontal scrolling, yet I personally don't care 
because IMHO if there's a horizontal scroll visible the page 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless it's a 
stateless form, which then goes back to top. Either way they *still* have to 
scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with working Ajax 
will see it and only for ajax forms. Else it back to top and they won't see it. 
Either way they *still* have to scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
leave and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg!

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. There needs to be some "buffer" on top when scrolling. For example, most 
websites have a floating navbar on top, and scrolling right to a panel will 
make the panel covered by the navbar. So there should be a buffer value, 20 is 
a sane minimal value for comfort, but some websites (like mine) will need to 
adjust it to 50 or something else.

4. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

(5. I know an edge case: horizontal scrolling, yet I personally don't care 
because IMHO if there's a horizontal scroll visible the page 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless it's a 
stateless form, which then goes back to top. Either way they *still* have to 
scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with working Ajax 
will see it and only for ajax forms. Else it back to top and they won't see it. 
Either way they *still* have to scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
leave and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg!

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. There needs to be some "buffer" on top when scrolling. For example, most 
websites have a floating navbar on top, and scrolling right to a panel will 
make the panel covered by the navbar. So there should be a buffer value, 20 is 
a sane minimal value for comfort, but some websites (like mine) will need to 
adjust it to 50 or something else.

4. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

(5. I know an edge case: horizontal scrolling, yet I personally don't care 
because IMHO if there's a horizontal scroll visible the page 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg!

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. There needs to be some "buffer" on top when scrolling. For example, most 
websites have a floating navbar on top, and scrolling right to a panel will 
make the panel covered by the navbar. So there should be a buffer value, 20 is 
a sane minimal value for comfort, but some websites (like mine) will need to 
adjust it to 50 or something else.

4. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

(5. I know an edge case: horizontal scrolling, yet I personally don't 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg!

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

So I hope you accept this proposal or at least give me hints on how to do point 
1 & 2 above. If this gets implemented in Wicket this should be a flag instead 
of a new component, and I hope it's enabled by default (if not in Wicket 7 then 
hopefully for Wicket 8).

Thank you in advance Martin! :)

  was:
My use case is exactly the same as described in 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg!
!wicketscroll.jpg|thumbnail! (attachment image not shown for some reason: 
https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg)

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

So I hope you accept this proposal or at least give me hints on how to do point 
1 & 2 above. If this gets implemented in Wicket this should be a flag instead 
of a new component, and I hope it's enabled by default (if not in Wicket 7 then 
hopefully for Wicket 8).

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!wicketscroll.jpg|thumbnail! (attachment image not shown for some reason: 
https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg)

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

So I hope you accept this proposal or at least give me hints on how to do point 
1 & 2 above. If this gets implemented in Wicket this should be a flag instead 
of a new component, and I hope it's enabled by default (if not in Wicket 7 then 
hopefully for Wicket 8).

Thank you in advance Martin! :)

  was:
My use case is exactly the same as 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow (almost half of the users go 
away on the very first form) that I'd like to increase its conversion rate :)

!https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg!
!wicketscroll.jpg!

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

So I hope you accept this proposal or at least give me hints on how to do point 
1 & 2 above. If this gets implemented in Wicket this should be a flag instead 
of a new component, and I hope it's enabled by default (if not in Wicket 7 then 
hopefully for Wicket 8).

Thank you in advance Martin! :)

  was:
My use case is exactly the same as described in 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow that I'd like to increase 
its conversion rate :)

!wicketscroll.jpg|thumbnail! (attachment image not shown for some reason: 
https://issues.apache.org/jira/secure/attachment/12880581/wicketscroll.jpg)

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

So I hope you accept this proposal or at least give me hints on how to do point 
1 & 2 above. If this gets implemented in Wicket this should be a flag instead 
of a new component, and I hope it's enabled by default (if not in Wicket 7 then 
hopefully for Wicket 8).

Thank you in advance Martin! :)

  was:
My use case is exactly the same as described in 

[jira] [Updated] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6439:
-
Description: 
My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow that I'd like to increase 
its conversion rate :)

!wicketscroll.jpg|thumbnail! (attachment image not shown for some reason)

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

So I hope you accept this proposal or at least give me hints on how to do point 
1 & 2 above. If this gets implemented in Wicket this should be a flag instead 
of a new component, and I hope it's enabled by default (if not in Wicket 7 then 
hopefully for Wicket 8).

Thank you in advance Martin! :)

  was:
My use case is exactly the same as described in 

[jira] [Created] (WICKET-6439) Support auto-scroll for (Fenced)FeedbackPanel

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-6439:


 Summary: Support auto-scroll for (Fenced)FeedbackPanel
 Key: WICKET-6439
 URL: https://issues.apache.org/jira/browse/WICKET-6439
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 7.8.0
Reporter: Hendy Irawan
Priority: Minor
 Attachments: wicketscroll.jpg

My use case is exactly the same as described in 
https://stackoverflow.com/questions/27172854/how-to-automatically-scroll-up-a-wicket-panel-when-wicket-feedbackpanel-is-trigg

Allow me to elaborate.

Assuming a mobile browser or any viewport size that can't display the full 
page: When user clicks the (ajax) Submit button and there's error, without this 
functionality, there are two scenarios:

1. If the FeedbackPanel is on top, the user won't see it. Unless they're using 
a traditional browser such as Opera Mini, which then goes back to top. Either 
way they *still* have to scroll up or down to find the field.
2. If the FeedbackPanel is right above the button, only users with modern 
browser will see it. Unless they're using a traditional browser such as Opera 
Mini, which goes back to top and won't see it. Either way they *still* have to 
scroll up or down to find the field.

Some users find this disorienting and I suspect this is the cause some people 
and never come back.

Just for the sake of argument here's one goal flow that I'd like to increase 
its conversion rate :)

!wicketscroll.jpg|thumbnail!

Proposed solution is simple, scroll to the FeedbackPanel message, which is 
optimally placed right on top of the first offending field (in case there are 
several). But some problems I encountered while trying to get solve this:

1. With {{Form.onError()}} it's trivial to do this when there's only one 
FeedbackPanel. But with multiple {{FencedFeedbackPanel}}s there needs to be 
some logic to (1) know which of the FeedbackPanels gets which message, and (2) 
determine the "top-most" (based on component hierarchy), before (3) appending 
JavaScript to scroll there.
2. Even with point 1 solved, I still need to duplicate that logic on every form 
on every page. It'd be great if this logic can be put directly in the 
FeedbackPanel itself. I've tried it using hint from 
https://stackoverflow.com/questions/19246892/how-to-get-the-ajaxrequesttarget-inside-wickets-onbeforerender-method-of-a-co
 but I can't even get any messages, any method I try simply gave either null or 
Array[] :

{code:java}
public class ScrollNotificationPanel extends NotificationPanel {
@Override
protected void onInitialize() {
super.onInitialize();
setOutputMarkupId(true);
}

@Override
protected void onAfterRender() {
super.onAfterRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horaXy', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

@Override
protected void onBeforeRender() {
super.onBeforeRender();
final AjaxRequestTarget target = 
getRequestCycle().find(AjaxRequestTarget.class);
if (null != target) {
final Object modelObject = newFeedbackMessagesModel().getObject();
//final List feedbackMessages = 
getFeedbackMessagesModel().getObject();
final String msgs = JsonUtils.asJson(modelObject);
target.appendJavaScript("console.log('horay', " + msgs + ");");
}
if (null != target && 
getFeedbackMessages().hasMessage(FeedbackMessage.ERROR)) {
String scrollScript = "$('html, body').animate({scrollTop:$('#" + 
getMarkupId() + "').offset().top - 20}, 'slow');\n";
target.appendJavaScript(scrollScript);
}
}

}
{code}

3. Added bonus if this can work with non-JavaScript (i.e. 
Button/AjaxFallbackButton) / stateless forms. Technically it's possible by 
using the URL fragment, i.e. FeedbackPanel's outputMarkupId will need to be 
true, and the "next" page need to redirect to a fragment. However I have no 
idea how to do this robustly.

So I hope you accept this proposal or at least give me hints on how to do point 
1 & 2 above. If this gets implemented in Wicket this should be a flag instead 
of a new component, and I hope it's enabled by default (if not in Wicket 7 then 
hopefully for Wicket 8).

[jira] [Comment Edited] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105832#comment-16105832
 ] 

Hendy Irawan edited comment on WICKET-6431 at 7/28/17 11:04 PM:


Ok, I've made a quickstart that's at least a part of what's been driving me 
crazy the past 36 hours or so. :p

It's a Spring Boot app so just run the main class DaemonApp.

so the app has a stateless form, feedback panel, fileupload, stateless link, 
and stateless button.

clicking the link gives error.
clicking the button has no error, but I don't see any feedback, not from the 
"required" fileupload, not from component-scoped nor session-scoped info() call.

I really hope this is my own stupidity and not a Wicket bug.

Thanks a lot [~mgrigorov] :) :) :)

BTW adding {{form1.setMultiPart(true);}} has no effect (at least at this point).


was (Author: ceefour):
Ok, I've made a quickstart that's at least a part of what's been driving me 
crazy the past 36 hours or so. :p

It's a Spring Boot app so just run the main class DaemonApp.

so the app has a stateless form, feedback panel, fileupload, stateless link, 
and stateless button.

clicking the link gives error.
clicking the button has no error, but I don't see any feedback, not from the 
"required" fileupload, not from component-scoped nor session-scoped info() call.

I really hope this is my own stupidity and not a Wicket bug.

Thanks a lot [~mgrigorov] :) :) :)

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: statelessbug.zip, wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6431:
-
Attachment: statelessbug.zip

Ok, I've made a quickstart that's at least a part of what's been driving me 
crazy the past 36 hours or so. :p

It's a Spring Boot app so just run the main class DaemonApp.

so the app has a stateless form, feedback panel, fileupload, stateless link, 
and stateless button.

clicking the link gives error.
clicking the button has no error, but I don't see any feedback, not from the 
"required" fileupload, not from component-scoped nor session-scoped info() call.

I really hope this is my own stupidity and not a Wicket bug.

Thanks a lot [~mgrigorov] :) :) :)

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: statelessbug.zip, wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105281#comment-16105281
 ] 

Hendy Irawan commented on WICKET-6431:
--

With 2 components on a page: stateless form and stateless link (both sibling 
and as child), ID increment is 2.
but if stateless form is removed, ID increment 1.

but these 2 scenarios still make stateless link onClick work.

however, my more complex page has 2 stateless links using the exact same class, 
but even in that same page, one stateless link (nested deep) is not working, 
while the other stateless link (more outer) is working.

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105229#comment-16105229
 ] 

Hendy Irawan edited comment on WICKET-6431 at 7/28/17 4:21 PM:
---

It turns out that disabling some components of the page can reduce the "ID 
increment"... I hope this ID increment mechanism (and what factors affect it) 
can be explained in more detail in the manual..


was (Author: ceefour):
It turns out that disabling some components of the page can reduce the "ID 
increment"... I hope this ID increment mechanism (and what factors affect it) 
is better explained in the manual..

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105229#comment-16105229
 ] 

Hendy Irawan commented on WICKET-6431:
--

It turns out that disabling some components of the page can reduce the "ID 
increment"... I hope this ID increment mechanism (and what factors affect it) 
is better explained in the manual..

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105137#comment-16105137
 ] 

Hendy Irawan edited comment on WICKET-6431 at 7/28/17 3:53 PM:
---

I noticed that in my complex page, the stateless component HTML IDs increase by 
5 everytime, i.e. a0, then aa. Is this normal?

However, when I try a new virgin ID, the stateless component ID only increase 
by 1.

Can you give a hint? If skipping IDs by 5 is not normal then perhaps I should 
try to make it go back to increasing by 1 again before further actions.

I also get this, both in console and Wicket Ajax Debug, while trying to 
target.add() a stateless component within a stateless page:

{code}
Wicket.Ajax.Call.processComponent: Component with id [[fileBorderb5]] was not 
found while trying to perform markup update. Make sure you called 
component.setOutputMarkupId(true) on the component whose markup you are trying 
to update.
(next call:)
Wicket.Ajax.Call.processComponent: Component with id [[fileBorderb7]] was not 
found while trying to perform markup update. Make sure you called 
component.setOutputMarkupId(true) on the component whose markup you are trying 
to update.
(consistent on every ajax call)
{code}

Suggestions very welcome.


was (Author: ceefour):
I noticed that in my complex page, the stateless component HTML IDs increase by 
5 everytime, i.e. a0, then aa. Is this normal?

However, when I try a new virgin ID, the stateless component ID only increase 
by 1.

Can you give a hint? If skipping IDs by 5 is not normal then perhaps I should 
try to make it go back to increasing by 1 again before further actions.

I also get this, both in console and Wicket AJax Debug:
Wicket.Ajax.Call.processComponent: Component with id [[fileBorderb5]] was not 
found while trying to perform markup update. Make sure you called 
component.setOutputMarkupId(true) on the component whose markup you are trying 
to update.
Wicket.Ajax.Call.processComponent: Component with id [[fileBorderb7]] was not 
found while trying to perform markup update. Make sure you called 
component.setOutputMarkupId(true) on the component whose markup you are trying 
to update.

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105137#comment-16105137
 ] 

Hendy Irawan edited comment on WICKET-6431 at 7/28/17 3:52 PM:
---

I noticed that in my complex page, the stateless component HTML IDs increase by 
5 everytime, i.e. a0, then aa. Is this normal?

However, when I try a new virgin ID, the stateless component ID only increase 
by 1.

Can you give a hint? If skipping IDs by 5 is not normal then perhaps I should 
try to make it go back to increasing by 1 again before further actions.

I also get this, both in console and Wicket AJax Debug:
Wicket.Ajax.Call.processComponent: Component with id [[fileBorderb5]] was not 
found while trying to perform markup update. Make sure you called 
component.setOutputMarkupId(true) on the component whose markup you are trying 
to update.
Wicket.Ajax.Call.processComponent: Component with id [[fileBorderb7]] was not 
found while trying to perform markup update. Make sure you called 
component.setOutputMarkupId(true) on the component whose markup you are trying 
to update.


was (Author: ceefour):
I noticed that in my complex page, the stateless component HTML IDs increase by 
5 everytime, i.e. a0, then aa. Is this normal?

However, when I try a new virgin ID, the stateless component ID only increase 
by 1.

Can you give a hint? If skipping IDs by 5 is not normal then perhaps I should 
try to make it go back to increasing by 1 again before further actions.

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105137#comment-16105137
 ] 

Hendy Irawan commented on WICKET-6431:
--

I noticed that in my complex page, the stateless component HTML IDs increase by 
5 everytime, i.e. a0, then aa. Is this normal?

However, when I try a new virgin ID, the stateless component ID only increase 
by 1.

Can you give a hint? If skipping IDs by 5 is not normal then perhaps I should 
try to make it go back to increasing by 1 again before further actions.

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104625#comment-16104625
 ] 

Hendy Irawan commented on WICKET-6431:
--

I should clarify my use case. The stateless link / button that I want to use is 
on a navbar. 

I'd like the navbar itself to be stateless, since the navbar gets used on both 
stateless and stateful pages.
However this doesn't work.

If I use stateless components the navbar won't work on stateful pages.

I'm thinking of explicitly creating two versions of navbar, stateful and 
stateless, but this seems to become a burden to update multiple navbars which 
have same visuals and functionality. I also plan to separate anonymos and user 
navbars, getting total navbars to 4...

Is there another alternative. Or is it really that stateless components are 
never supposed to work in stateful pages? If so, then probably the component 
needs to come with a warning or even exception when used within a stateful 
page... (just like the checker can throw exception when stateful component used 
within stateless page)


> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104283#comment-16104283
 ] 

Hendy Irawan commented on WICKET-6431:
--

I think kind of have a hunch why this happens.

It starts because the page always increases its page ID on every request (I 
don't know why yet).

So I believe that stateless component works by creating a new page instance, 
doing the action, then disposing the page. But that in a stateless page.

In a stateful page, I think it does it by comparing the current instance vs a 
new instance. if the current instance is "different" (as in my case) then it 
does not execute the action, and prefers to just render the page, and let the 
user redo the action again. probably my assumption is wrong. but in practice 
the user is forced to repeat the action.



> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104269#comment-16104269
 ] 

Hendy Irawan edited comment on WICKET-6431 at 7/28/17 1:17 AM:
---

I noticed the submitted stateless form's ID (in the request body) keeps 
changing on every page refresh ... hmm

oh and the page ID keeps increasing too on every click
(this probably because what the page does rather than the form, but still, 
regardless of what the page does, I expect a stateless button to always work 
unless it's not visible etc.)


was (Author: ceefour):
I noticed the submitted stateless form's ID (in the request body) keeps 
changing on every page refresh ... hmm

oh and the page ID keeps increasing too on every click
(this probably because what the page does rather than the form)

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104269#comment-16104269
 ] 

Hendy Irawan edited comment on WICKET-6431 at 7/28/17 1:16 AM:
---

I noticed the submitted stateless form's ID (in the request body) keeps 
changing on every page refresh ... hmm

oh and the page ID keeps increasing too on every click
(this probably because what the page does rather than the form)


was (Author: ceefour):
I noticed the submitted stateless form's ID (in the request body) keeps 
changing on every page refresh ... hmm

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104269#comment-16104269
 ] 

Hendy Irawan commented on WICKET-6431:
--

I noticed the submitted stateless form's ID (in the request body) keeps 
changing on every page refresh ... hmm

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6431:
-
Description: 
Markup:

{code:xml}

Keluar

{code}

Inside a **stateful** Page, This works:

{code:java}
final StatelessForm navbarForm = new StatelessForm("navbarForm") {
@Override
protected void onSubmit() {
super.onSubmit();
log.info("navbarForm onSubmit");
}
};
navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
log.info("Uw");
super.onSubmit(target, form);
log.info("Aw");
}
});
{code}

adding to the AjaxButton makes it not working:

{code:java}
@Override
protected boolean getStatelessHint() {
return true;
}
{code}

By "not working" it means directly redirects to this page again, no onSubmit 
behavior is called (neither for the form nor the button).

This is the HTTP request that gets sent when (made stateless) button is clicked:

!wicketbug1.jpg|thumbnail!
(show should attachment image, Jira bug?)

So to my mind it seems that the sending page is behaving "correctly" (since it 
sends the form), but the receiving page is not reacting correctly, and seems to 
ignore submitted form.

I observed similar behavior with StatelessLink, but I don't want to conflate 
issues. This could very well be my own fault.

  was:
Markup:

{code:xml}

Keluar

{code}

Inside a **stateful** Page, This works:

{code:java}
final StatelessForm navbarForm = new StatelessForm("navbarForm") {
@Override
protected void onSubmit() {
super.onSubmit();
log.info("navbarForm onSubmit");
}
};
navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
log.info("Uw");
super.onSubmit(target, form);
log.info("Aw");
}
});
{code}

adding to the AjaxButton makes it not working:

{code:java}
@Override
protected boolean getStatelessHint() {
return true;
}
{code}

By "not working" it means directly redirects to this page again, no onSubmit 
behavior is called (neither for the form nor the button).

This is the HTTP request that gets sent when (made stateless) button is clicked:

!wicketbug1.jpg|thumbnail!

So to my mind it seems that the sending page is behaving "correctly" (since it 
sends the form), but the receiving page is not reacting correctly, and seems to 
ignore submitted form.

I observed similar behavior with StatelessLink, but I don't want to conflate 
issues. This could very well be my own fault.


> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> (show should attachment image, Jira bug?)
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (WICKET-6431) In a stateful Page, Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6431:
-
Summary: In a stateful Page, Making AjaxButton stateless makes it not 
working  (was: Making AjaxButton stateless makes it not working)

> In a stateful Page, Making AjaxButton stateless makes it not working
> 
>
> Key: WICKET-6431
> URL: https://issues.apache.org/jira/browse/WICKET-6431
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
> Attachments: wicketbug1.jpg
>
>
> Markup:
> {code:xml}
> 
> Keluar
> 
> {code}
> Inside a **stateful** Page, This works:
> {code:java}
> final StatelessForm navbarForm = new StatelessForm("navbarForm") {
> @Override
> protected void onSubmit() {
> super.onSubmit();
> log.info("navbarForm onSubmit");
> }
> };
> navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
> @Override
> protected void onSubmit(AjaxRequestTarget target, Form form) {
> log.info("Uw");
> super.onSubmit(target, form);
> log.info("Aw");
> }
> });
> {code}
> adding to the AjaxButton makes it not working:
> {code:java}
> @Override
> protected boolean getStatelessHint() {
> return true;
> }
> {code}
> By "not working" it means directly redirects to this page again, no onSubmit 
> behavior is called (neither for the form nor the button).
> This is the HTTP request that gets sent when (made stateless) button is 
> clicked:
> !wicketbug1.jpg|thumbnail!
> So to my mind it seems that the sending page is behaving "correctly" (since 
> it sends the form), but the receiving page is not reacting correctly, and 
> seems to ignore submitted form.
> I observed similar behavior with StatelessLink, but I don't want to conflate 
> issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (WICKET-6431) Making AjaxButton stateless makes it not working

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-6431:


 Summary: Making AjaxButton stateless makes it not working
 Key: WICKET-6431
 URL: https://issues.apache.org/jira/browse/WICKET-6431
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 7.8.0
Reporter: Hendy Irawan
 Attachments: wicketbug1.jpg

Markup:

{code:xml}

Keluar

{code}

Inside a **stateful** Page, This works:

{code:java}
final StatelessForm navbarForm = new StatelessForm("navbarForm") {
@Override
protected void onSubmit() {
super.onSubmit();
log.info("navbarForm onSubmit");
}
};
navbarForm.add(new AjaxButton("logoutLink0", navbarForm) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
log.info("Uw");
super.onSubmit(target, form);
log.info("Aw");
}
});
{code}

adding to the AjaxButton makes it not working:

{code:java}
@Override
protected boolean getStatelessHint() {
return true;
}
{code}

By "not working" it means directly redirects to this page again, no onSubmit 
behavior is called (neither for the form nor the button).

This is the HTTP request that gets sent when (made stateless) button is clicked:

!wicketbug1.jpg|thumbnail!

So to my mind it seems that the sending page is behaving "correctly" (since it 
sends the form), but the receiving page is not reacting correctly, and seems to 
ignore submitted form.

I observed similar behavior with StatelessLink, but I don't want to conflate 
issues. This could very well be my own fault.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6183) Improve stateless support for AJAX

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099534#comment-16099534
 ] 

Hendy Irawan commented on WICKET-6183:
--

Thanks everyone!  :) :)

> Improve stateless support for AJAX
> --
>
> Key: WICKET-6183
> URL: https://issues.apache.org/jira/browse/WICKET-6183
> Project: Wicket
>  Issue Type: Improvement
>Affects Versions: 7.3.0
>Reporter: Andrea Del Bene
>Assignee: Andrea Del Bene
> Fix For: 8.0.0-M1, 7.4.0
>
>
> At the moment implementing stateless AJAX components and behaviors is 
> possible,  albeit difficult as it requires a good knowledge of Wicket 
> internal code. This issue is meant to improve stateless AJAX support using 
> some of the code from the  stateless [AJAX 
> module|https://github.com/wicketstuff/core/tree/master/stateless-parent] of 
> WicketStuff.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-5610) Introduce IApplicationSettings.useCdnResources() that will serve jQuery from CDN and can be used by 3rd party libs

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094486#comment-16094486
 ] 

Hendy Irawan commented on WICKET-5610:
--

Can JQueryCdnResourceReference be part of the main distribution? It's a great 
idea, especially because the "pick version" logic is needed.

> Introduce IApplicationSettings.useCdnResources() that will serve jQuery from 
> CDN and can be used by 3rd party libs
> --
>
> Key: WICKET-5610
> URL: https://issues.apache.org/jira/browse/WICKET-5610
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 6.15.0
>Reporter: Hendy Irawan
>Assignee: Martin Grigorov
> Attachments: use-cdn-app.tgz
>
>
> wicket-bootstrap has a 
> [IBootstrapSettings.useCdnResources()|https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/bootstrap-parent-0.9.3/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java]
>  which is a great idea.
> Wicket should adopt this setting in core. And when true, Wicket JS libraries 
> such as jQuery should use public CDN.
> This setting will default to true on {{DEPLOYMENT}}, and false for 
> {{DEVELOPMENT}} (but of course, can be set to true programmatically).
> wicket-bootstrap will then can use CDN settings from wicket core.
> In addition, I would suggest a variant of {{JavaScriptResourceReference}} 
> that also has an additional parameter for {{cdnUrl}} (which can be {{String}} 
> for convenience or {{Url}} for strictness, up to you), e.g. :
> {code}
>   public HowlerJavaScriptReference() {
>   super(HowlerJavaScriptReference.class, "howler.js", 
> "//cdnjs.cloudflare.com/ajax/libs/howler/1.1.17/howler.min.js");
>   }
> {code}
> its behavior will switch based on {{useCdnResources}} setting, and very easy 
> and practical to code this way. :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WICKET-6168) NULL Object Model in Radio Group

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15290401#comment-15290401
 ] 

Hendy Irawan commented on WICKET-6168:
--

Thanks Anton for isolated test case.

The problem is model object becomes null during onSubmit, instead of real 
sering content.

I hope this is just misusage instead of real bug.

> NULL Object Model in Radio Group
> 
>
> Key: WICKET-6168
> URL: https://issues.apache.org/jira/browse/WICKET-6168
> Project: Wicket
>  Issue Type: Bug
>Affects Versions: 7.3.0
> Environment: {code}
> # apache-tomcat-8.0.35
> # java 8
> {code}
>Reporter: Anton Kurniawan
> Attachments: myproject.zip
>
>
> Creating project use (http://wicket.apache.org/start/quickstart.html):
> {code}
> mvn archetype:generate -DarchetypeGroupId=org.apache.wicket 
> -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=7.3.0 
> -DgroupId=com.mycompany -DartifactId=myproject 
> -DarchetypeRepository=https://repository.apache.org/ -DinteractiveMode=false
> {code}
> Change java version:
> {code}
> :
> 
> :
> 
>   true
>   org.apache.maven.plugins
>   maven-compiler-plugin
>   3.1
>   
>   *1.8*
>   *1.8*
>   UTF-8
> :
> {code}
> Add a field:
> {code}
> private final IModel stringModel = new Model<>("A");
> {code}
> Add some codes in constructor {{Home.java}}:
> {code}
> /*RADIO GROUP TEST*/
> callMe();
> final Form form = new Form<>("form");
> form.add(new RadioGroup<>("stringRg", stringModel));
> form.add(new AjaxButton("btnTest") {
>   @Override
>   protected void onSubmit(AjaxRequestTarget target, Form form) {
>   super.onSubmit(target, form);
>   callMe();
>   }
> });
> add(form);
> /*END OF RADIO GROUP TEST*/
> {code}
> And in HTML:
> {code}
> 
> 
>   
>   TEST
> 
> 
> {code}
> Add mymethod in {{Home.java}}:
> {code}
> private void callMe() {
>   System.out.println(String.format("String object: %s", 
> stringModel.getObject()));
>   }
> {code}
> The output:
> {code}
> String object: A --> called by constructor
> String object: null --> called by {button test}}
> {code}
> tag : [~ceefour] [~ceefour...@gmail.com]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (WICKET-6151) DebugBar/PageSizeDebugPanel throws NullPointerException (need wrapper exception with more detail)

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6151:
-
Description: 
Probably due to unserializable model somewhere... in which case Wicket should 
give an explanation error.

{noformat}
org.apache.wicket.WicketRuntimeException
Exception in rendering component: [Component id = data]
at org.apache.wicket.Component.internalRenderComponent(Component.java:2589)
at org.apache.wicket.markup.html.WebComponent.onRender(WebComponent.java:60)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1657)
at 
org.apache.wicket.markup.html.link.AbstractLink.onComponentTagBody(AbstractLink.java:82)
at 
org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:70)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:797)
at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:77)
at 
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1657)
at 
org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:70)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.markup.html.list.ListView.renderItem(ListView.java:584)
at org.apache.wicket.markup.html.list.ListView.renderChild(ListView.java:573)
at 
org.apache.wicket.markup.repeater.AbstractRepeater.onRender(AbstractRepeater.java:102)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1657)
at 
org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:70)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:797)
at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:77)
at 
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at 

[jira] [Updated] (WICKET-6151) DebugBar/PageSizeDebugPanel throws NullPointerException (need wrapper exception with more detail)

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6151:
-
Description: 
Probably due to unserializable model somewhere... in which case Wicket should 
give an explanation error.

{noformat}
org.apache.wicket.WicketRuntimeException
Exception in rendering component: [Component id = data]
at org.apache.wicket.Component.internalRenderComponent(Component.java:2589)
at org.apache.wicket.markup.html.WebComponent.onRender(WebComponent.java:60)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1657)
at 
org.apache.wicket.markup.html.link.AbstractLink.onComponentTagBody(AbstractLink.java:82)
at 
org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:70)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:797)
at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:77)
at 
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1657)
at 
org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:70)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.markup.html.list.ListView.renderItem(ListView.java:584)
at org.apache.wicket.markup.html.list.ListView.renderChild(ListView.java:573)
at 
org.apache.wicket.markup.repeater.AbstractRepeater.onRender(AbstractRepeater.java:102)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1657)
at 
org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:70)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at org.apache.wicket.Component.internalRender(Component.java:2380)
at org.apache.wicket.Component.render(Component.java:2308)
at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1524)
at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1759)
at 
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1734)
at 
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:797)
at 
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:77)
at 
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at org.apache.wicket.Component.internalRenderComponent(Component.java:2565)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1698)
at 

[jira] [Created] (WICKET-6151) DebugBar/PageSizeDebugPanel throws NullPointerException (need wrapper exception with more detail)

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-6151:


 Summary: DebugBar/PageSizeDebugPanel throws NullPointerException 
(need wrapper exception with more detail)
 Key: WICKET-6151
 URL: https://issues.apache.org/jira/browse/WICKET-6151
 Project: Wicket
  Issue Type: Bug
  Components: wicket-devutils
Affects Versions: 7.2.0
 Environment: Tomcat 7, JDK 8, Linux Mint 17.3 64bit, Spring 4.2.5
Reporter: Hendy Irawan
Priority: Minor


Probably due to unserializable model somewhere... in which case Wicket should 
give an explanation error.

Follow-up to WICKET-5807



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-6134) NPE when using ListView with missing markup

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15251711#comment-15251711
 ] 

Hendy Irawan commented on WICKET-6134:
--

Thanks you [~bitstorm] [~marc-g] , I just got this too today

> NPE when using ListView with missing markup
> ---
>
> Key: WICKET-6134
> URL: https://issues.apache.org/jira/browse/WICKET-6134
> Project: Wicket
>  Issue Type: Bug
>Affects Versions: 7.2.0
>Reporter: Marc G.
>Assignee: Andrea Del Bene
> Fix For: 7.3.0, 8.0.0-M1
>
> Attachments: myproject.7z
>
>
> Instead of getting the hint that you've added a component and missing the 
> reference in the markup you get an NPE:
> Unexpected RuntimeException
> Last cause: null
> WicketMessage: Error attaching this container for rendering: [Page class = 
> com.mycompany.HomePage, id = 0, render count = 1]
> Stacktrace
> Root cause:
> java.lang.NullPointerException
>  at org.apache.wicket.DequeueContext.nextTag(DequeueContext.java:143)
>  at org.apache.wicket.DequeueContext.(DequeueContext.java:71)
>  at 
> org.apache.wicket.markup.html.list.ListItem.newDequeueContext(ListItem.java:106)
>  at org.apache.wicket.MarkupContainer.dequeue(MarkupContainer.java:2029)
>  at 
> org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:1049)
>  at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:239)
>  at 
> org.apache.wicket.markup.html.list.ListView.onPopulate(ListView.java:519)
>  at 
> org.apache.wicket.markup.repeater.AbstractRepeater.onBeforeRender(AbstractRepeater.java:124)
>  at org.apache.wicket.Component.internalBeforeRender(Component.java:949)
>  at org.apache.wicket.Component.beforeRender(Component.java:1017)
>  at 
> org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1866)
>  at org.apache.wicket.Component.onBeforeRender(Component.java:3877)
>  at org.apache.wicket.Page.onBeforeRender(Page.java:801)
>  at org.apache.wicket.Component.internalBeforeRender(Component.java:949)
>  at org.apache.wicket.Component.beforeRender(Component.java:1017)
>  at 
> org.apache.wicket.Component.internalPrepareForRender(Component.java:2215)
>  at org.apache.wicket.Page.internalPrepareForRender(Page.java:242)
>  at org.apache.wicket.Component.render(Component.java:2304)
>  at org.apache.wicket.Page.renderPage(Page.java:1018)
>  at 
> org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:124)
>  at 
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:236)
>  at 
> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
>  at 
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:895)
>  at 
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>  at 
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
>  at 
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
>  at 
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
>  at 
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
>  at 
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
>  at 
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284)
>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>  at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>  at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>  at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>  at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>  at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>  at org.eclipse.jetty.server.Server.handle(Server.java:499)

[jira] [Commented] (WICKET-6100) Upgrade jQuery to 1.12.1

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15162835#comment-15162835
 ] 

Hendy Irawan commented on WICKET-6100:
--

1.21.1 also fixes https://github.com/jquery/jquery/issues/2866

> Upgrade jQuery to 1.12.1
> 
>
> Key: WICKET-6100
> URL: https://issues.apache.org/jira/browse/WICKET-6100
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 7.2.0, 6.22.0
>Reporter: Anton Kurniawan
>Priority: Trivial
>
> We're hit by https://github.com/telerik/kendo-ui-core/issues/1375 / 
> https://github.com/jquery/jquery/issues/2836#issuecomment-171900265 (which 
> also affects Chrome in a way, not just IE). 1.12.1 did fix this problem.
> {noformat}
>  Uncaught TypeError: Cannot read property 'opener' of null
>  jquery-1.12.0-ver-1456109363000.js:6704 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970634#comment-14970634
 ] 

Hendy Irawan commented on WICKET-6002:
--

[~mgrigorov] Here's the quickstart, please reopen: 
https://github.com/ceefour/wicket-6002

In code for {{HomePage.java}} you can add {{fileFld.setVisible(false);}} which 
will make the {{TextField}} "work" again.

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>Assignee: Martin Grigorov
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Accept: application/xml, text/xml, */*; q=0.01
> X-Requested-With: XMLHttpRequest
> Wicket-Ajax: true
> Wicket-Ajax-BaseURL: chaincode?0
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: 

[jira] [Comment Edited] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960525#comment-14960525
 ] 

Hendy Irawan edited comment on WICKET-6002 at 10/18/15 9:27 AM:


Workaround described in WICKET-5924 
(https://issues.apache.org/jira/browse/WICKET-5924?focusedCommentId=14586051=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14586051):
 either {{(exclude = MultipartAutoConfiguration.class)}} or 
{{multipart.enabled=false}} *works!*


was (Author: ceefour):
--I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, 
bug still occurs--

Workaround described in WICKET-5924 
(https://issues.apache.org/jira/browse/WICKET-5924?focusedCommentId=14586051=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14586051):
 either {{(exclude = MultipartAutoConfiguration.class)}} or 
{{multipart.enabled=false}} *works!*

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>Assignee: Martin Grigorov
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> 

[jira] [Commented] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14962244#comment-14962244
 ] 

Hendy Irawan commented on WICKET-6002:
--

Sorry about that, the main class is DaemonApp.

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>Assignee: Martin Grigorov
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Accept: application/xml, text/xml, */*; q=0.01
> X-Requested-With: XMLHttpRequest
> Wicket-Ajax: true
> Wicket-Ajax-BaseURL: chaincode?0
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> form21_hf_0==0=1
> {noformat}
> "Probably" related with WICKET-5924, but I don't have issue with 
> FileUploadField, my issue is 

[jira] [Issue Comment Deleted] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6002:
-
Comment: was deleted

(was: --*Any* workaround (other than separating forms) is welcome, because we 
need to submit the image and the form components simultaneously...-- see above)

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>Assignee: Martin Grigorov
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Accept: application/xml, text/xml, */*; q=0.01
> X-Requested-With: XMLHttpRequest
> Wicket-Ajax: true
> Wicket-Ajax-BaseURL: chaincode?0
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> form21_hf_0==0=1
> {noformat}
> 

[jira] [Updated] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6002:
-
Description: 
First form: (not working)

{code:java}
final Form form = new Form<>("form");

final ListModel filesModel = new ListModel<>();
final FileUploadField fileFld = new FileUploadField("fileFld", 
filesModel);
form.add(fileFld);

final Model modeImageModel = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage = new 
RadioChoice<>("modeImage",
modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
form.add(modeImage);

form.add(new AjaxButton("loadBtn2") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form 
form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImageModel.getObject());
}
});
add(form);
{code}

Second form: exactly same as above, but remove the fileUploadField.

{code:java}
final Form form2 = new Form<>("form2");
final Model modeImage2Model = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
form2.add(modeImage2);
form2.add(new AjaxButton("loadBtn3") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImage2Model.getObject());
}
});
add(form2);
{code}

Markup:

{code}

Original



Mode:


Load Biasa




Original


Mode:


Load 3


{code}

With the non-working form, the request is multipart. This seems to cause all 
form components' model.getObject() become null.

{noformat}
POST 
/chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 576
Cache-Control: max-age=0
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: multipart/form-data; 
boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="form3_hf_0"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="fileFld"; filename=""
Content-Type: application/octet-stream


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="modeImage"

0
--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="msgImage"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="loadBtn2"

1
--WebKitFormBoundaryv78rJ8mvP8YbHtBy--
{noformat}

With the working form, the request is urlencoded form:

{noformat}
POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 36
Origin: http://localhost:8080
Wicket-FocusedElementId: loadBtn32
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: application/xml, text/xml, */*; q=0.01
X-Requested-With: XMLHttpRequest
Wicket-Ajax: true
Wicket-Ajax-BaseURL: chaincode?0
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

form21_hf_0==0=1
{noformat}

"Probably" related with WICKET-5924, but I don't have issue with 
FileUploadField, my issue is with other form components in the same form as 
FileUploadField. Probably related to: 
http://stackoverflow.com/questions/28784942/fileupload-field-wicket-error

*Test case:*

{code}
git clone https://github.com/tmdgitb/pengenalan_pola_shih.git -t WICKET-6002
{code}

1. Run {{DaemonApp}}
2. Go to "ChainCode" page 
3. click "Load Biasa" on the left, you'll see "modeimageModel: null". --> not 
working: using FileUploadField + multipart
4. click "Load 3" on the right, you'll see "modeimageModel: WHITE_ON_BLACK" --> 
works: using urlencoded


  was:
First form: (not working)

{code:java}
final Form form = new Form<>("form");

final ListModel filesModel = new ListModel<>();
final FileUploadField fileFld = new FileUploadField("fileFld", 
filesModel);
form.add(fileFld);

  

[jira] [Commented] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14962311#comment-14962311
 ] 

Hendy Irawan commented on WICKET-6002:
--

Can you check that you use the WICKET-6002 tag? From your description it seems 
you use the master branch instead.

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>Assignee: Martin Grigorov
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Accept: application/xml, text/xml, */*; q=0.01
> X-Requested-With: XMLHttpRequest
> Wicket-Ajax: true
> Wicket-Ajax-BaseURL: chaincode?0
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> form21_hf_0==0=1
> {noformat}
> "Probably" related with 

[jira] [Updated] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6002:
-
Description: 
First form: (not working)

{code:java}
final Form form = new Form<>("form");

final ListModel filesModel = new ListModel<>();
final FileUploadField fileFld = new FileUploadField("fileFld", 
filesModel);
form.add(fileFld);

final Model modeImageModel = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage = new 
RadioChoice<>("modeImage",
modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
form.add(modeImage);

form.add(new AjaxButton("loadBtn2") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form 
form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImageModel.getObject());
}
});
add(form);
{code}

Second form: exactly same as above, but remove the fileUploadField.

{code:java}
final Form form2 = new Form<>("form2");
final Model modeImage2Model = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
form2.add(modeImage2);
form2.add(new AjaxButton("loadBtn3") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImage2Model.getObject());
}
});
add(form2);
{code}

Markup:

{code}

Original



Mode:


Load Biasa




Original


Mode:


Load 3


{code}

With the non-working form, the request is multipart. This seems to cause all 
form components' model.getObject() become null.

{noformat}
POST 
/chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 576
Cache-Control: max-age=0
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: multipart/form-data; 
boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="form3_hf_0"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="fileFld"; filename=""
Content-Type: application/octet-stream


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="modeImage"

0
--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="msgImage"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="loadBtn2"

1
--WebKitFormBoundaryv78rJ8mvP8YbHtBy--
{noformat}

With the working form, the request is urlencoded form:

{noformat}
POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 36
Origin: http://localhost:8080
Wicket-FocusedElementId: loadBtn32
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: application/xml, text/xml, */*; q=0.01
X-Requested-With: XMLHttpRequest
Wicket-Ajax: true
Wicket-Ajax-BaseURL: chaincode?0
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

form21_hf_0==0=1
{noformat}

"Probably" related with WICKET-5924, but I don't have issue with 
FileUploadField, my issue is with other form components in the same form as 
FileUploadField. Probably related to: 
http://stackoverflow.com/questions/28784942/fileupload-field-wicket-error

**Test case:**

{code:bash}
git clone https://github.com/tmdgitb/pengenalan_pola_shih.git -t WICKET-6002
{code}

1. Go to "ChainCode" page 
2. click "Load Biasa" on the left, you'll see "modeimageModel: null". --> not 
working: using FileUploadField + multipart
3. click "Load 3" on the right, you'll see "modeimageModel: WHITE_ON_BLACK" --> 
works: using urlencoded


  was:
First form: (not working)

{code:java}
final Form form = new Form<>("form");

final ListModel filesModel = new ListModel<>();
final FileUploadField fileFld = new FileUploadField("fileFld", 
filesModel);
form.add(fileFld);

final Model 

[jira] [Comment Edited] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960525#comment-14960525
 ] 

Hendy Irawan edited comment on WICKET-6002 at 10/16/15 11:34 AM:
-

I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, 
bug still occurs

Workaround described in WICKET-5924 
(https://issues.apache.org/jira/browse/WICKET-5924?focusedCommentId=14586051=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14586051):
 either {{(exclude = MultipartAutoConfiguration.class)}} or 
{{multipart.enabled=false}} works!


was (Author: ceefour):
I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, bug 
still occurs

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: 

[jira] [Comment Edited] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960525#comment-14960525
 ] 

Hendy Irawan edited comment on WICKET-6002 at 10/16/15 11:34 AM:
-

--I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, 
bug still occurs--

Workaround described in WICKET-5924 
(https://issues.apache.org/jira/browse/WICKET-5924?focusedCommentId=14586051=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14586051):
 either {{(exclude = MultipartAutoConfiguration.class)}} or 
{{multipart.enabled=false}} *works!*


was (Author: ceefour):
--I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, 
bug still occurs--

Workaround described in WICKET-5924 
(https://issues.apache.org/jira/browse/WICKET-5924?focusedCommentId=14586051=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14586051):
 either {{(exclude = MultipartAutoConfiguration.class)}} or 
{{multipart.enabled=false}} works!

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: 

[jira] [Comment Edited] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960525#comment-14960525
 ] 

Hendy Irawan edited comment on WICKET-6002 at 10/16/15 11:34 AM:
-

--I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, 
bug still occurs--

Workaround described in WICKET-5924 
(https://issues.apache.org/jira/browse/WICKET-5924?focusedCommentId=14586051=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14586051):
 either {{(exclude = MultipartAutoConfiguration.class)}} or 
{{multipart.enabled=false}} works!


was (Author: ceefour):
I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, 
bug still occurs

Workaround described in WICKET-5924 
(https://issues.apache.org/jira/browse/WICKET-5924?focusedCommentId=14586051=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14586051):
 either {{(exclude = MultipartAutoConfiguration.class)}} or 
{{multipart.enabled=false}} works!

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: 

[jira] [Updated] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-6002:
-
Description: 
First form: (not working)

{code:java}
final Form form = new Form<>("form");

final ListModel filesModel = new ListModel<>();
final FileUploadField fileFld = new FileUploadField("fileFld", 
filesModel);
form.add(fileFld);

final Model modeImageModel = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage = new 
RadioChoice<>("modeImage",
modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
form.add(modeImage);

form.add(new AjaxButton("loadBtn2") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form 
form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImageModel.getObject());
}
});
add(form);
{code}

Second form: exactly same as above, but remove the fileUploadField.

{code:java}
final Form form2 = new Form<>("form2");
final Model modeImage2Model = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
form2.add(modeImage2);
form2.add(new AjaxButton("loadBtn3") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImage2Model.getObject());
}
});
add(form2);
{code}

Markup:

{code}

Original



Mode:


Load Biasa




Original


Mode:


Load 3


{code}

With the non-working form, the request is multipart. This seems to cause all 
form components' model.getObject() become null.

{noformat}
POST 
/chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 576
Cache-Control: max-age=0
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: multipart/form-data; 
boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="form3_hf_0"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="fileFld"; filename=""
Content-Type: application/octet-stream


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="modeImage"

0
--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="msgImage"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="loadBtn2"

1
--WebKitFormBoundaryv78rJ8mvP8YbHtBy--
{noformat}

With the working form, the request is urlencoded form:

{noformat}
POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 36
Origin: http://localhost:8080
Wicket-FocusedElementId: loadBtn32
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: application/xml, text/xml, */*; q=0.01
X-Requested-With: XMLHttpRequest
Wicket-Ajax: true
Wicket-Ajax-BaseURL: chaincode?0
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

form21_hf_0==0=1
{noformat}

"Probably" related with WICKET-5924, but I don't have issue with 
FileUploadField, my issue is with other form components in the same form as 
FileUploadField. Probably related to: 
http://stackoverflow.com/questions/28784942/fileupload-field-wicket-error

*Test case:*

{code}
git clone https://github.com/tmdgitb/pengenalan_pola_shih.git -t WICKET-6002
{code}

1. Go to "ChainCode" page 
2. click "Load Biasa" on the left, you'll see "modeimageModel: null". --> not 
working: using FileUploadField + multipart
3. click "Load 3" on the right, you'll see "modeimageModel: WHITE_ON_BLACK" --> 
works: using urlencoded


  was:
First form: (not working)

{code:java}
final Form form = new Form<>("form");

final ListModel filesModel = new ListModel<>();
final FileUploadField fileFld = new FileUploadField("fileFld", 
filesModel);
form.add(fileFld);

final Model 

[jira] [Commented] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960525#comment-14960525
 ] 

Hendy Irawan commented on WICKET-6002:
--

I've tried {{(exclude = MultipartAutoConfiguration.class)}} --> no effect, bug 
still occurs

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Accept: application/xml, text/xml, */*; q=0.01
> X-Requested-With: XMLHttpRequest
> Wicket-Ajax: true
> Wicket-Ajax-BaseURL: chaincode?0
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> form21_hf_0==0=1
> {noformat}
> "Probably" related with WICKET-5924, but I don't have issue with 
> FileUploadField, my 

[jira] [Created] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-6002:


 Summary: FileUploadField makes form-component models become null 
on submit
 Key: WICKET-6002
 URL: https://issues.apache.org/jira/browse/WICKET-6002
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 7.0.0
 Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
Reporter: Hendy Irawan


First form: (not working)

{code:java}
final Form form = new Form<>("form");

final ListModel filesModel = new ListModel<>();
final FileUploadField fileFld = new FileUploadField("fileFld", 
filesModel);
form.add(fileFld);

final Model modeImageModel = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage = new 
RadioChoice<>("modeImage",
modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
form.add(modeImage);

form.add(new AjaxButton("loadBtn2") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form 
form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImageModel.getObject());
}
});
add(form);
{code}

Second form: exactly same as above, but remove the fileUploadField.

{code:java}
final Form form2 = new Form<>("form2");
final Model modeImage2Model = new 
Model<>(GrayscaleMode.WHITE_ON_BLACK);
final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
form2.add(modeImage2);
form2.add(new AjaxButton("loadBtn3") {
@Override
protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
super.onAfterSubmit(target, form);
log.info("modeimageModel: {}", modeImage2Model.getObject());
}
});
add(form2);
{code}

Markup:

{code}

Original



Mode:


Load Biasa




Original


Mode:


Load 3


{code}

With the non-working form, the request is multipart. This seems to cause all 
form components' model.getObject() become null.

{noformat}
POST 
/chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 576
Cache-Control: max-age=0
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: multipart/form-data; 
boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="form3_hf_0"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="fileFld"; filename=""
Content-Type: application/octet-stream


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="modeImage"

0
--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="msgImage"


--WebKitFormBoundaryv78rJ8mvP8YbHtBy
Content-Disposition: form-data; name="loadBtn2"

1
--WebKitFormBoundaryv78rJ8mvP8YbHtBy--
{noformat}

With the working form, the request is urlencoded form:

{noformat}
POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 36
Origin: http://localhost:8080
Wicket-FocusedElementId: loadBtn32
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: application/xml, text/xml, */*; q=0.01
X-Requested-With: XMLHttpRequest
Wicket-Ajax: true
Wicket-Ajax-BaseURL: chaincode?0
Referer: http://localhost:8080/chaincode?0
Accept-Encoding: gzip, deflate
Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7

form21_hf_0==0=1
{noformat}

"Probably" related with WICKET-5924, but I don't have issue with 
FileUploadField, my issue is with other form components in the same form as 
FileUploadField. Probably related to: 
http://stackoverflow.com/questions/28784942/fileupload-field-wicket-error

TODO: test case coming soon



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960532#comment-14960532
 ] 

Hendy Irawan edited comment on WICKET-6002 at 10/16/15 11:35 AM:
-

--*Any* workaround (other than separating forms) is welcome, because we need to 
submit the image and the form components simultaneously...-- see above


was (Author: ceefour):
*Any* workaround (other than separating forms) is welcome, because we need to 
submit the image and the form components simultaneously...

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Accept: application/xml, text/xml, */*; q=0.01
> X-Requested-With: XMLHttpRequest
> Wicket-Ajax: true
> Wicket-Ajax-BaseURL: chaincode?0
> Referer: 

[jira] [Commented] (WICKET-6002) FileUploadField makes form-component models become null on submit

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14960532#comment-14960532
 ] 

Hendy Irawan commented on WICKET-6002:
--

*Any* workaround (other than separating forms) is welcome, because we need to 
submit the image and the form components simultaneously...

> FileUploadField makes form-component models become null on submit
> -
>
> Key: WICKET-6002
> URL: https://issues.apache.org/jira/browse/WICKET-6002
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.0.0
> Environment: Spring Boot 1.2.6, wicket-bootstrap 0.10.3, Tomcat 8
>Reporter: Hendy Irawan
>
> First form: (not working)
> {code:java}
> final Form form = new Form<>("form");
> final ListModel filesModel = new ListModel<>();
> final FileUploadField fileFld = new FileUploadField("fileFld", 
> filesModel);
> form.add(fileFld);
> final Model modeImageModel = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage = new 
> RadioChoice<>("modeImage",
> modeImageModel, ImmutableList.copyOf(GrayscaleMode.values()));
> form.add(modeImage);
> form.add(new AjaxButton("loadBtn2") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form 
> form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImageModel.getObject());
> }
> });
> add(form);
> {code}
> Second form: exactly same as above, but remove the fileUploadField.
> {code:java}
> final Form form2 = new Form<>("form2");
> final Model modeImage2Model = new 
> Model<>(GrayscaleMode.WHITE_ON_BLACK);
> final RadioChoice modeImage2 = new RadioChoice<>("modeImage2",
> modeImage2Model, ImmutableList.copyOf(GrayscaleMode.values()));
> form2.add(modeImage2);
> form2.add(new AjaxButton("loadBtn3") {
> @Override
> protected void onAfterSubmit(AjaxRequestTarget target, Form form) {
> super.onAfterSubmit(target, form);
> log.info("modeimageModel: {}", modeImage2Model.getObject());
> }
> });
> add(form2);
> {code}
> Markup:
> {code}
> 
> Original
> 
> 
> 
> Mode:
> 
> 
> Load Biasa
> 
> 
> 
> Original
> 
> 
> Mode:
> 
> 
> Load 3
> 
> 
> {code}
> With the non-working form, the request is multipart. This seems to cause all 
> form components' model.getObject() become null.
> {noformat}
> POST 
> /chaincode?0-1.IBehaviorListener.0-form-loadBtn2=true=chaincode%3F0
>  HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 576
> Cache-Control: max-age=0
> Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Origin: http://localhost:8080
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: multipart/form-data; 
> boundary=WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="form3_hf_0"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="fileFld"; filename=""
> Content-Type: application/octet-stream
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="modeImage"
> 0
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="msgImage"
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy
> Content-Disposition: form-data; name="loadBtn2"
> 1
> --WebKitFormBoundaryv78rJ8mvP8YbHtBy--
> {noformat}
> With the working form, the request is urlencoded form:
> {noformat}
> POST /chaincode?0-1.IBehaviorListener.0-form2-loadBtn3 HTTP/1.1
> Host: localhost:8080
> Connection: keep-alive
> Content-Length: 36
> Origin: http://localhost:8080
> Wicket-FocusedElementId: loadBtn32
> User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> Accept: application/xml, text/xml, */*; q=0.01
> X-Requested-With: XMLHttpRequest
> Wicket-Ajax: true
> Wicket-Ajax-BaseURL: chaincode?0
> Referer: http://localhost:8080/chaincode?0
> Accept-Encoding: gzip, deflate
> Accept-Language: id,en-US;q=0.8,en;q=0.6,ms;q=0.4
> Cookie: JSESSIONID=746B6931A8791427E02FCE5C1D20F1B7
> form21_hf_0==0=1
> {noformat}
> "Probably" related with WICKET-5924, but I 

[jira] [Commented] (WICKET-5930) Upgrade Atmosphere to 2.2.7

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599440#comment-14599440
 ] 

Hendy Irawan commented on WICKET-5930:
--

Thank you very much Martin!

Sorry to hear about atmosphere problems..

 Upgrade Atmosphere to 2.2.7
 ---

 Key: WICKET-5930
 URL: https://issues.apache.org/jira/browse/WICKET-5930
 Project: Wicket
  Issue Type: Improvement
  Components: wicket-atmosphere
Affects Versions: 6.20.0
Reporter: Hendy Irawan
Assignee: Martin Grigorov
 Fix For: 6.21.0, 7.0.0-M7


 Upgrade Atmosphere + {{jquery-atmosphere}} to 2.2.7
 also:
 * upgrade wicket-webjars to 0.4.6
 * upgrade jsr305 to 3.0.0 (if applicable)
 * upgrade guava to 18.0 (if applicable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (WICKET-5930) Upgrade Atmosphere to 2.2.7

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-5930:
-
Priority: Major  (was: Trivial)

 Upgrade Atmosphere to 2.2.7
 ---

 Key: WICKET-5930
 URL: https://issues.apache.org/jira/browse/WICKET-5930
 Project: Wicket
  Issue Type: Improvement
  Components: wicket-atmosphere
Affects Versions: 6.20.0
Reporter: Hendy Irawan
Assignee: Emond Papegaaij

 Upgrade Atmosphere + {{jquery-atmosphere}} to 2.2.7
 also:
 * upgrade wicket-webjars to 0.4.6
 * upgrade jsr305 to 3.0.0 (if applicable)
 * upgrade guava to 18.0 (if applicable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (WICKET-5930) Upgrade Atmosphere to 2.2.7

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5930:


 Summary: Upgrade Atmosphere to 2.2.7
 Key: WICKET-5930
 URL: https://issues.apache.org/jira/browse/WICKET-5930
 Project: Wicket
  Issue Type: Improvement
  Components: wicket-atmosphere
Affects Versions: 6.20.0
Reporter: Hendy Irawan
Assignee: Emond Papegaaij
Priority: Trivial


Upgrade Atmosphere + {{jquery-atmosphere}} to 2.2.7

also:

* upgrade wicket-webjars to 0.4.6
* upgrade jsr305 to 3.0.0 (if applicable)
* upgrade guava to 18.0 (if applicable)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5807) Add diagnostic messages on java.io.NotSerializableException on DebugBar's StandardDebugPanel, path = 1:dev:content:contributors:3:contrib:link:data.Label

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283129#comment-14283129
 ] 

Hendy Irawan commented on WICKET-5807:
--

The exception does *not* mention the field and class that is not serializable.

It only mentions the component data.Label as I described. But I have no such 
component! It's only part of the DebugBar.

What I propose is give information about the *original* component that causes 
DebugBar to fail. In addition, it'd be nice if DebugBar itself shouldn't fail 
at all.

An analogy is SLF4J, a log.debug() call is pretty much guaranteed to never 
fail. It may log an error or even do nothing as silence, but it'll never throw 
an Exception and disrupt the app. Since it's used to debug an app, its behavior 
need to be consistent.

 Add diagnostic messages on java.io.NotSerializableException on DebugBar's 
 StandardDebugPanel, path = 
 1:dev:content:contributors:3:contrib:link:data.Label
 -

 Key: WICKET-5807
 URL: https://issues.apache.org/jira/browse/WICKET-5807
 Project: Wicket
  Issue Type: Improvement
  Components: wicket-devutils
Affects Versions: 6.18.0
Reporter: ahmadfarsiado

 If my Component has incorrectly non-serializable model and I add DebugBar to 
 this Page, I get the Exception below.
 While it's definitely my fault, the Exception currently is not helpful in 
 diagnosing the problem, because it mentions the DebugBar component as the 
 culprit.
 It'd be great if it mentions:
 componentClass + componentPath + modelClass
 (this seems to happen during render phase of the DebugBar, so it may need 
 some DebugBar pre-render logic to check the properness of the models)
 {code}
 Unexpected RuntimeException
 Last cause: org.soluvas.category.impl.CategoryImpl
 WicketMessage: Exception in rendering component: [Component id = data]
 Stacktrace
 Root cause:
 java.io.NotSerializableException: org.soluvas.category.impl.CategoryImpl
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
 at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
 at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
 at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
 at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1378)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
 at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
 at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
 at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1378)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
 at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
 at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
 at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1378)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
 at 

[jira] [Created] (WICKET-5803) Reduce log for o.a.w.r.PropertiesFactory | Loading properties files from ...

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5803:


 Summary: Reduce log for o.a.w.r.PropertiesFactory | Loading 
properties files from ...
 Key: WICKET-5803
 URL: https://issues.apache.org/jira/browse/WICKET-5803
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Hendy Irawan
Priority: Trivial


This log is nice, but I think it should be DEBUG level, not INFO (just like 
loading html, css, js, etc. are not INFO-logged)

{code}
o.a.w.r.PropertiesFactory| Loading properties files from 
jar:file:/home/bippoapp/tomcat_bipporeg_prd/webapps/ROOT/WEB-INF/lib/id.co.bippo.payment.web-6.0.0-SNAPSHOT.jar!/id/co/bippo/payment/web/pub/ConfirmationPaymentPage_in.properties
 with loader 
org.apache.wicket.resource.IsoPropertiesFilePropertiesLoader@5fc092f1
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5795) LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT) to support convenient lambda instantiation in Java8

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268868#comment-14268868
 ] 

Hendy Irawan commented on WICKET-5795:
--

Thanks for letting me know of wicket-lambdamodel, yes it fills partial use case.

For {{LoadableDetachableModel}} still requires the Wicket implementation, while 
it's possible to create/copy a new implementation, it's more straightforward to 
add a static method to existing implementations.

 LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT) to support 
 convenient lambda instantiation in Java8
 --

 Key: WICKET-5795
 URL: https://issues.apache.org/jira/browse/WICKET-5795
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Hendy Irawan

 I propose adding static method 
 {{LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT)}} so this 
 can be used to quickly create ad-hoc models in Java8 using lambda syntax. 
 (but does not require Java8 in any way). [{{Supplier}} is from Guava 
 library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].
 Sample usage:
 {code}
 add(new Label(slug, 
 LoadableDetachableModel.of( () - personRepo.slugFor(getModelObject()) 
 )));
 {code}
 Similar approach for other abstract classes can also be useful for 
 implementing typically single methods like {{onSubmit}}, {{onClick}}, 
 {{onConfigure}}, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5290) History API support for navigable AJAX pages/components

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262065#comment-14262065
 ] 

Hendy Irawan commented on WICKET-5290:
--

The [wicket-stateless 
project|https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/stateless-parent]
 contains some useful stuff 

 History API support for navigable AJAX pages/components
 ---

 Key: WICKET-5290
 URL: https://issues.apache.org/jira/browse/WICKET-5290
 Project: Wicket
  Issue Type: New Feature
  Components: wicket
Affects Versions: 7.0.0-M1
Reporter: Hendy Irawan

 I wonder if Wicket 6/7 has or planned for good history API support, i.e. 
 navigable ajax updates a la Twitter/Facebook?
 If not then I'd like to propose... It'd make Wicket not only very relevant 
 but a breakthrough in a *post*-HTML5 world.
 Originally posted at 
 https://issues.apache.org/jira/browse/WICKET-3813?focusedCommentId=13720564page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13720564
 [~mgrigorov] responded:
  Do you know of a good JS History library ?
  All I have tried have issues for different browsers.
 What I ever used is Backbone. Which is a great all around library. 
 Snippet from http://backbonejs.org/#Router : 
 blockquote 
 Web applications often provide linkable, bookmarkable, shareable URLs for 
 important locations in the app. Until recently, hash fragments (#page) were 
 used to provide these permalinks, but with the arrival of the History API, 
 it's now possible to use standard URLs (/page). Backbone.Router provides 
 methods for routing client-side pages, and connecting them to actions and 
 events. For browsers which don't yet support the History API, the Router 
 handles graceful fallback and transparent translation to the fragment version 
 of the URL. 
 /blockquote 
 Breadcrumb components would benefit greatly from History API support (and is 
 probably its main use case).
 Although any parameterizable page will benefit from this.  For example we're 
 developing an analytics app so the parameters include date range, precision, 
 and selected sections. Those can be encoded in URI. Although while selecting 
 these things we immediately perform AJAX updates, with bookmarkable URI it'd 
 great. So the page stays stateless instead of stateful. Just like how 
 Google Analytics UI does it.
 **Use Cases**
 1. **Page parameters** (usually for stateless pages). Most probably very 
 common use case, why make a page stateful just to save a few variables? Just 
 define a few page params and let LoadableDetachableModel load the rest. 
 Instead of storing the page in the session, store the page state in the URL 
 and let history API manage that state.
 2. **BreadCrumb(Panel) components**. Navigable components, but still inside a 
 single page
 3. **Inter-page navigation**. Page navigation but only target several 
 components. Perhaps via whitelisting or blacklisting or a combination of 
 both. This seems most challenging compared to the two cases above.
 History API libraries include:
 1. http://backbonejs.org/#Router
 2. https://github.com/browserstate/history.js/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (WICKET-5290) History API support for navigable AJAX pages/components

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262065#comment-14262065
 ] 

Hendy Irawan edited comment on WICKET-5290 at 12/31/14 9:49 AM:


The [wicket-stateless 
project|https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/stateless-parent]
 contains some useful stuff:

* StatelessAjaxFormComponentUpdatingBehavior
* StatelessAjaxFallbackLink
* StatelessAjaxEventBehavior
* StatelessLink
* Url org.wicketstuff.stateless.StatelessEncoder.mergeParameters(Url url, 
PageParameters params)



was (Author: ceefour):
The [wicket-stateless 
project|https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/stateless-parent]
 contains some useful stuff 

 History API support for navigable AJAX pages/components
 ---

 Key: WICKET-5290
 URL: https://issues.apache.org/jira/browse/WICKET-5290
 Project: Wicket
  Issue Type: New Feature
  Components: wicket
Affects Versions: 7.0.0-M1
Reporter: Hendy Irawan

 I wonder if Wicket 6/7 has or planned for good history API support, i.e. 
 navigable ajax updates a la Twitter/Facebook?
 If not then I'd like to propose... It'd make Wicket not only very relevant 
 but a breakthrough in a *post*-HTML5 world.
 Originally posted at 
 https://issues.apache.org/jira/browse/WICKET-3813?focusedCommentId=13720564page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13720564
 [~mgrigorov] responded:
  Do you know of a good JS History library ?
  All I have tried have issues for different browsers.
 What I ever used is Backbone. Which is a great all around library. 
 Snippet from http://backbonejs.org/#Router : 
 blockquote 
 Web applications often provide linkable, bookmarkable, shareable URLs for 
 important locations in the app. Until recently, hash fragments (#page) were 
 used to provide these permalinks, but with the arrival of the History API, 
 it's now possible to use standard URLs (/page). Backbone.Router provides 
 methods for routing client-side pages, and connecting them to actions and 
 events. For browsers which don't yet support the History API, the Router 
 handles graceful fallback and transparent translation to the fragment version 
 of the URL. 
 /blockquote 
 Breadcrumb components would benefit greatly from History API support (and is 
 probably its main use case).
 Although any parameterizable page will benefit from this.  For example we're 
 developing an analytics app so the parameters include date range, precision, 
 and selected sections. Those can be encoded in URI. Although while selecting 
 these things we immediately perform AJAX updates, with bookmarkable URI it'd 
 great. So the page stays stateless instead of stateful. Just like how 
 Google Analytics UI does it.
 **Use Cases**
 1. **Page parameters** (usually for stateless pages). Most probably very 
 common use case, why make a page stateful just to save a few variables? Just 
 define a few page params and let LoadableDetachableModel load the rest. 
 Instead of storing the page in the session, store the page state in the URL 
 and let history API manage that state.
 2. **BreadCrumb(Panel) components**. Navigable components, but still inside a 
 single page
 3. **Inter-page navigation**. Page navigation but only target several 
 components. Perhaps via whitelisting or blacklisting or a combination of 
 both. This seems most challenging compared to the two cases above.
 History API libraries include:
 1. http://backbonejs.org/#Router
 2. https://github.com/browserstate/history.js/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5693) setVersioned(false) should force single Page Version

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259991#comment-14259991
 ] 

Hendy Irawan commented on WICKET-5693:
--

I too am confused with the behavior of {{setVersioned(false)}}

True to turn on versioning for this component, false to turn it off for this 
component and any children.

I see no effect on setting (on a stateful page, of course) this to false at all.

What's the intended behavior, so I can confirm that {{setVersioned(false)}} is 
indeed working as the contract (i.e. Javadoc) suggested? I can't be sure, but 
if {{setVersioned()}} is not working at all, then it should be both deprecated 
and Javadoc corrected such that this has no effect, stateful components are 
always versioned.

 setVersioned(false) should force single Page Version
 

 Key: WICKET-5693
 URL: https://issues.apache.org/jira/browse/WICKET-5693
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.16.0
 Environment: All
Reporter: Bernard

 After a form submit, we want the browser's back button to show the page 
 before the form not the form page. That is a business requirement to prevent 
 double submits.
 A web application can, via the use of Post-Redirect-Get, respond with the 
 same URL as the form page's request URL, and let the browser history replace 
 the form page with the form submit result page.
 In Wicket, we can attempt to achieve this behaviour by using the same page 
 class for form and response - replacing a form panel with a response panel.
 Still Wicket creates multiple versions of the page which show as version 
 numbers in the URL. To fix this, we call setVersioned(false).
 But still, the page is served with different URLs. This needs to be fixed in 
 some way.
 We need full core framework support for this, without having to code 
 workarounds. We have coded workarounds in the past, but these were broken by 
 subsequent Wicket releases, even minor releases.
 We might need the URL to be version-free because the page's initial URL, 
 being bookmarkable, would not have a version number. The only limitation 
 should be the case where the browser does not have a cookie for the site, 
 where the first page visited is the form page, having jsessionid in the URL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (WICKET-5795) LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT) to support convenient lambda instantiation in Java8

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5795:


 Summary: LoadableDetachableModel/AbstractReadOnlyModel 
.of(SupplierT) to support convenient lambda instantiation in Java8
 Key: WICKET-5795
 URL: https://issues.apache.org/jira/browse/WICKET-5795
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Hendy Irawan


I propose adding static method {{LoadableDetachableModel/AbstractReadOnlyModel 
.of(SupplierT)}} so this can be used to quickly create ad-hoc models in Java8 
using lambda syntax. (but does not require Java8 in any way). [{{Supplier}} is 
from Guava 
library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].

Sample usage:

{code}
add(new Label(slug, LoadableDetachableModel.of( () - 
personRepo.slugFor(getModelObject()) )));
{code}

Similar approach for other abstract classes can also be useful for implementing 
typically single methods like {{onSubmit}}, {{onClick}}, {{onConfigure}}, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (WICKET-5795) LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT) to support convenient lambda instantiation in Java8

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-5795:
-
Description: 
I propose adding static method {{LoadableDetachableModel/AbstractReadOnlyModel 
.of(SupplierT)}} so this can be used to quickly create ad-hoc models in Java8 
using lambda syntax. (but does not require Java8 in any way). [{{Supplier}} is 
from Guava 
library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].

Sample usage:

{code}
add(new Label(slug, 
  LoadableDetachableModel.of( () - personRepo.slugFor(getModelObject()) )));
{code}

Similar approach for other abstract classes can also be useful for implementing 
typically single methods like {{onSubmit}}, {{onClick}}, {{onConfigure}}, etc.

  was:
I propose adding static method {{LoadableDetachableModel/AbstractReadOnlyModel 
.of(SupplierT)}} so this can be used to quickly create ad-hoc models in Java8 
using lambda syntax. (but does not require Java8 in any way). [{{Supplier}} is 
from Guava 
library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].

Sample usage:

{code}
add(new Label(slug, LoadableDetachableModel.of( () - 
personRepo.slugFor(getModelObject()) )));
{code}

Similar approach for other abstract classes can also be useful for implementing 
typically single methods like {{onSubmit}}, {{onClick}}, {{onConfigure}}, etc.


 LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT) to support 
 convenient lambda instantiation in Java8
 --

 Key: WICKET-5795
 URL: https://issues.apache.org/jira/browse/WICKET-5795
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Hendy Irawan

 I propose adding static method 
 {{LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT)}} so this 
 can be used to quickly create ad-hoc models in Java8 using lambda syntax. 
 (but does not require Java8 in any way). [{{Supplier}} is from Guava 
 library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].
 Sample usage:
 {code}
 add(new Label(slug, 
   LoadableDetachableModel.of( () - personRepo.slugFor(getModelObject()) )));
 {code}
 Similar approach for other abstract classes can also be useful for 
 implementing typically single methods like {{onSubmit}}, {{onClick}}, 
 {{onConfigure}}, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (WICKET-5795) LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT) to support convenient lambda instantiation in Java8

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-5795:
-
Description: 
I propose adding static method {{LoadableDetachableModel/AbstractReadOnlyModel 
.of(SupplierT)}} so this can be used to quickly create ad-hoc models in Java8 
using lambda syntax. (but does not require Java8 in any way). [{{Supplier}} is 
from Guava 
library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].

Sample usage:

{code}
add(new Label(slug, 
LoadableDetachableModel.of( () - personRepo.slugFor(getModelObject()) )));
{code}

Similar approach for other abstract classes can also be useful for implementing 
typically single methods like {{onSubmit}}, {{onClick}}, {{onConfigure}}, etc.

  was:
I propose adding static method {{LoadableDetachableModel/AbstractReadOnlyModel 
.of(SupplierT)}} so this can be used to quickly create ad-hoc models in Java8 
using lambda syntax. (but does not require Java8 in any way). [{{Supplier}} is 
from Guava 
library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].

Sample usage:

{code}
add(new Label(slug, 
  LoadableDetachableModel.of( () - personRepo.slugFor(getModelObject()) )));
{code}

Similar approach for other abstract classes can also be useful for implementing 
typically single methods like {{onSubmit}}, {{onClick}}, {{onConfigure}}, etc.


 LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT) to support 
 convenient lambda instantiation in Java8
 --

 Key: WICKET-5795
 URL: https://issues.apache.org/jira/browse/WICKET-5795
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Hendy Irawan

 I propose adding static method 
 {{LoadableDetachableModel/AbstractReadOnlyModel .of(SupplierT)}} so this 
 can be used to quickly create ad-hoc models in Java8 using lambda syntax. 
 (but does not require Java8 in any way). [{{Supplier}} is from Guava 
 library|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Supplier.html].
 Sample usage:
 {code}
 add(new Label(slug, 
 LoadableDetachableModel.of( () - personRepo.slugFor(getModelObject()) 
 )));
 {code}
 Similar approach for other abstract classes can also be useful for 
 implementing typically single methods like {{onSubmit}}, {{onClick}}, 
 {{onConfigure}}, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5776) Please wrap Exception mentioning the component path during Error detaching RequestHandler in Component.detachModel[s]

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246740#comment-14246740
 ] 

Hendy Irawan commented on WICKET-5776:
--

[~svenmeier] wow, I didn't think of that :)

 Please wrap Exception mentioning the component path during Error detaching 
 RequestHandler in Component.detachModel[s]
 ---

 Key: WICKET-5776
 URL: https://issues.apache.org/jira/browse/WICKET-5776
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Anton Kurniawan
Priority: Minor

 I got error like this:
 {code}
 org.apache.wicket.request.RequestHandlerStack : Error detaching RequestHandler
 java.lang.ClassCastException: id.co.bippo.product.impl.VariedProductImpl 
 cannot be cast to java.util.List
   at org.soluvas.web.site.EmfListModel.onDetach(EmfListModel.java:60) 
 ~[classes/:na]
   at 
 org.apache.wicket.model.LoadableDetachableModel.detach(LoadableDetachableModel.java:99)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModel(Component.java:3585) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModels(Component.java:1242) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1172) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.PageProvider.detach(PageProvider.java:327)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.RenderPageRequestHandler.detach(RenderPageRequestHandler.java:156)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:873)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180)
  ~[wicket-request-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:636) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:589) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  [catalina.jar:7.0.42]
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
  [catalina.jar:7.0.42]
   at 
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 
 [tomcat-embed-websocket-7.0.56.jar:7.0.56]
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  

[jira] [Commented] (WICKET-5786) Include org.apache.wicket.resource.JQueryPluginUrlResourceReference (from wicket-bootstrap-core)

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14238954#comment-14238954
 ] 

Hendy Irawan commented on WICKET-5786:
--

Thank you Martin. I just thought it useful, maybe why no one asks for it is 
because they're creating one for themselves. That's what we were doing for a 
year or so till we found wicket bootstrap's class.

If one is writing a jquery-dependant library (but not depend on bootstrap) it'd 
be easier and less error prone to use this class than write their own.

That said it's up to you. I'm fine either way.

 Include org.apache.wicket.resource.JQueryPluginUrlResourceReference (from 
 wicket-bootstrap-core)
 

 Key: WICKET-5786
 URL: https://issues.apache.org/jira/browse/WICKET-5786
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Hendy Irawan
Priority: Trivial

 {{de.agilecoders.wicket.core.markup.html.references.JQueryPluginUrlResourceReference}}
  is very useful and I propose its inclusion in wicket-core.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5776) Please wrap Exception mentioning the component path during Error detaching RequestHandler in Component.detachModel[s]

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235159#comment-14235159
 ] 

Hendy Irawan commented on WICKET-5776:
--

Yes I guess what you described is how the implementation would work:

{code}
void detach() {
  try {
// detachChildren
  } catch (ComponentDetachException cde) {
throw cde;
  } catch (Exception e) {
throw new ComponentDetachException(Cannot detach component  + getPath(), 
e);
  }  
}
{code}

I think that such code is relatively concise and expresses its purpose 
appropriately.


 Please wrap Exception mentioning the component path during Error detaching 
 RequestHandler in Component.detachModel[s]
 ---

 Key: WICKET-5776
 URL: https://issues.apache.org/jira/browse/WICKET-5776
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Anton Kurniawan
Priority: Minor

 I got error like this:
 {code}
 org.apache.wicket.request.RequestHandlerStack : Error detaching RequestHandler
 java.lang.ClassCastException: id.co.bippo.product.impl.VariedProductImpl 
 cannot be cast to java.util.List
   at org.soluvas.web.site.EmfListModel.onDetach(EmfListModel.java:60) 
 ~[classes/:na]
   at 
 org.apache.wicket.model.LoadableDetachableModel.detach(LoadableDetachableModel.java:99)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModel(Component.java:3585) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModels(Component.java:1242) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1172) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.PageProvider.detach(PageProvider.java:327)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.RenderPageRequestHandler.detach(RenderPageRequestHandler.java:156)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:873)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180)
  ~[wicket-request-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:636) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:589) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  [catalina.jar:7.0.42]
   at 
 

[jira] [Comment Edited] (WICKET-5776) Please wrap Exception mentioning the component path during Error detaching RequestHandler in Component.detachModel[s]

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235159#comment-14235159
 ] 

Hendy Irawan edited comment on WICKET-5776 at 12/5/14 6:33 AM:
---

Yes I guess what you described is how the implementation would work:

{code}
void detach() {
  try {
// detachChildren
  } catch (ComponentDetachException cde) {
throw cde;
  } catch (Exception e) {
throw new ComponentDetachException(Error detaching component  + getPath() 
+
  (getDefaultModel() != null ?  with a  + 
getDefaultModel().getClass().getName() +  model : ) + :  + e, e);
  }  
}
{code}

I think that such code is relatively concise and expresses its purpose 
appropriately.



was (Author: ceefour):
Yes I guess what you described is how the implementation would work:

{code}
void detach() {
  try {
// detachChildren
  } catch (ComponentDetachException cde) {
throw cde;
  } catch (Exception e) {
throw new ComponentDetachException(Error detaching component  + getPath() 
+ :  + e, e);
  }  
}
{code}

I think that such code is relatively concise and expresses its purpose 
appropriately.


 Please wrap Exception mentioning the component path during Error detaching 
 RequestHandler in Component.detachModel[s]
 ---

 Key: WICKET-5776
 URL: https://issues.apache.org/jira/browse/WICKET-5776
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Anton Kurniawan
Priority: Minor

 I got error like this:
 {code}
 org.apache.wicket.request.RequestHandlerStack : Error detaching RequestHandler
 java.lang.ClassCastException: id.co.bippo.product.impl.VariedProductImpl 
 cannot be cast to java.util.List
   at org.soluvas.web.site.EmfListModel.onDetach(EmfListModel.java:60) 
 ~[classes/:na]
   at 
 org.apache.wicket.model.LoadableDetachableModel.detach(LoadableDetachableModel.java:99)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModel(Component.java:3585) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModels(Component.java:1242) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1172) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.PageProvider.detach(PageProvider.java:327)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.RenderPageRequestHandler.detach(RenderPageRequestHandler.java:156)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:873)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180)
  ~[wicket-request-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:636) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:589) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 

[jira] [Commented] (WICKET-2876) bookmarkable paging navigator

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230892#comment-14230892
 ] 

Hendy Irawan commented on WICKET-2876:
--

this is weird... why create this issue and immediately close it?

seems very useful for me (and a lot of users), see 
http://techiesinsight.blogspot.com/2013/02/custom-pagingnavigator-for-seo-friendly.html

 bookmarkable paging navigator
 -

 Key: WICKET-2876
 URL: https://issues.apache.org/jira/browse/WICKET-2876
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
 Environment: web dev environment: wicket1.4.7 jdk1.6 tomcat6.0 
 system environment: Windows xp
Reporter: cleverpig
  Labels: bookmarkable, navigator, paging, restful
 Attachments: code.zip


 Thanks Igor Vaynberg and every sharer!
 I checked a variety url coding strategies, but did not find one that is very 
 appropriate when using datatable and navigator in page.
 HybridUrlCodingStrategy might also be, but it can not display the page 
 parameter in url, can not be true bookmarkable.
 And the version number int its url will make the user confused.
 So I look forward to using MixedParamUrlCodingStrategy, which may need to 
 find out navigation links parameter name in the navigator,such 
 as:first,next,etc!
 Maybe we should not do the same thing to reinvent the wheel.
 After a morning of thinking and programming, I wrote a few simple restful 
 navigator implement!
 Here are main 4 classes:
 1.BookmarkablePagingNavigator
 2.BookmarkablePagingNavigation
 3.BookmarkablePagingNavigationLink
 4.BookmarkablePagingNavigationIncrementLink
 Core idea is to override PagingNavigator and PagingNavigation classes' 
 newPagingNavigationLink and newPagingNavigationIncrementLink methods.
 BookmarkablePagingNavigationLink extends from PagingNavigationLink.
 BookmarkablePagingNavigationLink's work depends on CharSequence getURL() 
 method:
 protected CharSequence getURL () (
   if (getPopupSettings ()! = null)
throw new IllegalStateException (You cannot specify popup 
 settings and a page map);
PageParameters parameters = getPageParameters ();
if (getPopupSettings ()! = null)
return urlFor (getPopupSettings (). getPageMap (this),
 getPageClass (), parameters);
else
return urlFor (getPageClass (), parameters);
 )
 I'm so glad to give my gift:I put these classes as attachment with this 
 mail,please share it~
 TO FIX: it can not handle the search bar of the parameters or other 
 parameters of DataTable Headers(such as sort param).
 Here is our discuss track:
 http://apache-wicket.1842946.n4.nabble.com/Which-url-coding-strategy-to-make-more-restful-in-page-with-navigator-tp2197248p2197248.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5776) Please wrap Exception mentioning the component path during Error detaching RequestHandler in Component.detachModel[s]

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227536#comment-14227536
 ] 

Hendy Irawan commented on WICKET-5776:
--

Thanks [~AntonKurniawan] for reporting. Yup this would be very helpful ! :)

 Please wrap Exception mentioning the component path during Error detaching 
 RequestHandler in Component.detachModel[s]
 ---

 Key: WICKET-5776
 URL: https://issues.apache.org/jira/browse/WICKET-5776
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.18.0
Reporter: Anton Kurniawan
Priority: Minor

 I got error like this:
 {code}
 org.apache.wicket.request.RequestHandlerStack : Error detaching RequestHandler
 java.lang.ClassCastException: id.co.bippo.product.impl.VariedProductImpl 
 cannot be cast to java.util.List
   at org.soluvas.web.site.EmfListModel.onDetach(EmfListModel.java:60) 
 ~[classes/:na]
   at 
 org.apache.wicket.model.LoadableDetachableModel.detach(LoadableDetachableModel.java:99)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModel(Component.java:3585) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detachModels(Component.java:1242) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1172) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.MarkupContainer.detachChildren(MarkupContainer.java:1609) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at org.apache.wicket.Component.detach(Component.java:1179) 
 ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.PageProvider.detach(PageProvider.java:327)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.core.request.handler.RenderPageRequestHandler.detach(RenderPageRequestHandler.java:156)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.detach(RequestCycle.java:873)
  ~[wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:180)
  ~[wicket-request-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:636) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:589) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
  [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) 
 [wicket-core-6.18.0.jar:6.18.0]
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  [catalina.jar:7.0.42]
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
  [catalina.jar:7.0.42]
   at 
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 
 [tomcat-embed-websocket-7.0.56.jar:7.0.56]
   at 
 

[jira] [Commented] (WICKET-5709) When clicking IndicatingAjaxButton: java.lang.StackOverflowError at org.apache.wicket.util.visit.Visits.visitChildren

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14154604#comment-14154604
 ] 

Hendy Irawan commented on WICKET-5709:
--

[~mgrigorov] I truly wish that's the issue, unfortunately BootstrapPage is only 
553 lines: 
https://github.com/soluvas/soluvas-web/blob/918ca438fc2f2440f9125bdd3e98a3a98d263729/bootstrap/src/main/java/org/soluvas/web/bootstrap/BootstrapPage.java


 When clicking IndicatingAjaxButton: java.lang.StackOverflowError at 
 org.apache.wicket.util.visit.Visits.visitChildren
 -

 Key: WICKET-5709
 URL: https://issues.apache.org/jira/browse/WICKET-5709
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.17.0
 Environment: Tomcat 7, Spring 4.0.7, Oracle JDK 8u20 64-bit, Ubuntu 
 14.04 64-bit
Reporter: Rudi Wijaya
 Attachments: 
 wicket-stackoverflow-in-DedicatedLoginPage-loginvianavbar.pdf


 We have a page named {{DedicatedLoginPage}}, and when clicking a 
 {{LoginButton}} (which essentially is an {{IndicatingAjaxButton}}) with path 
 {{navbar:loginDropdown:loginForm:login}}, throws a {{StackOverflowError}} 
 without additional explanation.
 {code}
 java.lang.StackOverflowError
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy.searchMarkupInTransparentResolvers(AbstractMarkupSourcingStrategy.java:65)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:100)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.Component.getMarkup(Component.java:755) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:82)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy$1.component(AbstractMarkupSourcingStrategy.java:72)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy$1.component(AbstractMarkupSourcingStrategy.java:66)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
 
 repeats a couple hundred times
 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy.searchMarkupInTransparentResolvers(AbstractMarkupSourcingStrategy.java:65)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:100)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.Component.getMarkup(Component.java:755) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:82)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 

[jira] [Comment Edited] (WICKET-5709) When clicking IndicatingAjaxButton: java.lang.StackOverflowError at org.apache.wicket.util.visit.Visits.visitChildren

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14154604#comment-14154604
 ] 

Hendy Irawan edited comment on WICKET-5709 at 10/1/14 9:38 AM:
---

[~mgrigorov] I truly wish that's the issue, unfortunately [BootstrapPage.java 
is only 553 lines| 
https://github.com/soluvas/soluvas-web/blob/918ca438fc2f2440f9125bdd3e98a3a98d263729/bootstrap/src/main/java/org/soluvas/web/bootstrap/BootstrapPage.java]


was (Author: ceefour):
[~mgrigorov] I truly wish that's the issue, unfortunately BootstrapPage is only 
553 lines: 
https://github.com/soluvas/soluvas-web/blob/918ca438fc2f2440f9125bdd3e98a3a98d263729/bootstrap/src/main/java/org/soluvas/web/bootstrap/BootstrapPage.java


 When clicking IndicatingAjaxButton: java.lang.StackOverflowError at 
 org.apache.wicket.util.visit.Visits.visitChildren
 -

 Key: WICKET-5709
 URL: https://issues.apache.org/jira/browse/WICKET-5709
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.17.0
 Environment: Tomcat 7, Spring 4.0.7, Oracle JDK 8u20 64-bit, Ubuntu 
 14.04 64-bit
Reporter: Rudi Wijaya
 Attachments: 
 wicket-stackoverflow-in-DedicatedLoginPage-loginvianavbar.pdf


 We have a page named {{DedicatedLoginPage}}, and when clicking a 
 {{LoginButton}} (which essentially is an {{IndicatingAjaxButton}}) with path 
 {{navbar:loginDropdown:loginForm:login}}, throws a {{StackOverflowError}} 
 without additional explanation.
 {code}
 java.lang.StackOverflowError
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy.searchMarkupInTransparentResolvers(AbstractMarkupSourcingStrategy.java:65)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:100)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.Component.getMarkup(Component.java:755) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:82)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy$1.component(AbstractMarkupSourcingStrategy.java:72)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy$1.component(AbstractMarkupSourcingStrategy.java:66)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
 
 repeats a couple hundred times
 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy.searchMarkupInTransparentResolvers(AbstractMarkupSourcingStrategy.java:65)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:100)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 

[jira] [Commented] (WICKET-5603) OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in Chrome v35

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153020#comment-14153020
 ] 

Hendy Irawan commented on WICKET-5603:
--

I'd like to add that {{wicket-select2}} no longer works with 6.17's 
{{OnChangeAjaxBehavior}} (previously works with 6.16).

I had to use {{new AjaxFormComponentUpdatingBehavior('change')}} instead for 
6.17.

 OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in 
 Chrome v35
 

 Key: WICKET-5603
 URL: https://issues.apache.org/jira/browse/WICKET-5603
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.9.1, 7.0.0-M1
 Environment: Chrome 35.0.1916.114
Reporter: Andrey Krasnopolsky
Assignee: Andrea Del Bene
 Fix For: 7.0.0-M3, 6.17.0

 Attachments: test.zip, wicket.patch


 I have a DropDownChoice with attached OnChangeAjaxBehavior, like this:
 {code:borderStyle=solid}
 new DropDownChoice(dd, new Model(), Arrays.asList( First, Second))
 .add( new OnChangeAjaxBehavior() {
 @Override
 protected void onUpdate(AjaxRequestTarget target) {
 System.out.println( update );
 }
 });
 {code}
 When selecting any of drop down options, two Ajax requests being generated.
 It behaves OK in IE, FF and Chrome v34, only Chrome v35 is affected 
  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (WICKET-5603) OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in Chrome v35

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153020#comment-14153020
 ] 

Hendy Irawan edited comment on WICKET-5603 at 9/30/14 9:45 AM:
---

I'd like to add that {{wicket-select2}} no longer works with 6.17's 
{{OnChangeAjaxBehavior}} (previously works with 6.16).

I had to use {{new AjaxFormComponentUpdatingBehavior(change)}} instead for 
6.17.


was (Author: ceefour):
I'd like to add that {{wicket-select2}} no longer works with 6.17's 
{{OnChangeAjaxBehavior}} (previously works with 6.16).

I had to use {{new AjaxFormComponentUpdatingBehavior('change')}} instead for 
6.17.

 OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in 
 Chrome v35
 

 Key: WICKET-5603
 URL: https://issues.apache.org/jira/browse/WICKET-5603
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.9.1, 7.0.0-M1
 Environment: Chrome 35.0.1916.114
Reporter: Andrey Krasnopolsky
Assignee: Andrea Del Bene
 Fix For: 7.0.0-M3, 6.17.0

 Attachments: test.zip, wicket.patch


 I have a DropDownChoice with attached OnChangeAjaxBehavior, like this:
 {code:borderStyle=solid}
 new DropDownChoice(dd, new Model(), Arrays.asList( First, Second))
 .add( new OnChangeAjaxBehavior() {
 @Override
 protected void onUpdate(AjaxRequestTarget target) {
 System.out.println( update );
 }
 });
 {code}
 When selecting any of drop down options, two Ajax requests being generated.
 It behaves OK in IE, FF and Chrome v34, only Chrome v35 is affected 
  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WICKET-5709) When clicking IndicatingAjaxButton: java.lang.StackOverflowError at org.apache.wicket.util.visit.Visits.visitChildren

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146113#comment-14146113
 ] 

Hendy Irawan commented on WICKET-5709:
--

Is it possible to enable some kind of TRACE logging of some sort to know what 
children Wicket visits multiple times? Or maybe to have Wicket impose an 
internal limit of visitor recursion depth, so it can spit a more thorough 
exception rather than the JDK default ambiguous StackOverflowError?

A Wicket SNAPSHOT or branch with additional diagnostic code would be helpful...

 When clicking IndicatingAjaxButton: java.lang.StackOverflowError at 
 org.apache.wicket.util.visit.Visits.visitChildren
 -

 Key: WICKET-5709
 URL: https://issues.apache.org/jira/browse/WICKET-5709
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.17.0
 Environment: Tomcat 7, Spring 4.0.7, Oracle JDK 8u20 64-bit, Ubuntu 
 14.04 64-bit
Reporter: Rudi Wijaya
 Attachments: 
 wicket-stackoverflow-in-DedicatedLoginPage-loginvianavbar.pdf


 We have a page named {{DedicatedLoginPage}}, and when clicking a 
 {{LoginButton}} (which essentially is an {{IndicatingAjaxButton}}) with path 
 {{navbar:loginDropdown:loginForm:login}}, throws a {{StackOverflowError}} 
 without additional explanation.
 {code}
 java.lang.StackOverflowError
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:134) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy.searchMarkupInTransparentResolvers(AbstractMarkupSourcingStrategy.java:65)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:100)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.Component.getMarkup(Component.java:755) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:82)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy$1.component(AbstractMarkupSourcingStrategy.java:72)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy$1.component(AbstractMarkupSourcingStrategy.java:66)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) 
 ~[wicket-util-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
 
 repeats a couple hundred times
 
 org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.AbstractMarkupSourcingStrategy.searchMarkupInTransparentResolvers(AbstractMarkupSourcingStrategy.java:65)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:100)
  ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.MarkupContainer.getMarkup(MarkupContainer.java:451) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at org.apache.wicket.Component.getMarkup(Component.java:755) 
 ~[wicket-core-6.17.0.jar:6.17.0]
   at 
 org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.getMarkup(DefaultMarkupSourcingStrategy.java:82)
  

[jira] [Commented] (WICKET-5686) @Inject should require the bean dependency instead of setting null

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14113589#comment-14113589
 ] 

Hendy Irawan commented on WICKET-5686:
--

Thank you [~mgrigorov]


 @Inject should require the bean dependency instead of setting null
 --

 Key: WICKET-5686
 URL: https://issues.apache.org/jira/browse/WICKET-5686
 Project: Wicket
  Issue Type: Bug
  Components: wicket-spring
Affects Versions: 6.16.0
 Environment: Spring 4.0.6
Reporter: Anton Kurniawan
Assignee: Martin Grigorov
 Fix For: 7.0.0-M3, 6.17.0


 When using {{@SpringBean}}, if the bean cannot be injected then Wicket will 
 throw {{Exception}}.
 However current behavior if when using {{@Inject}} inside component, the 
 field will be left as null. This is inconsistent behavior with what CDI spec 
 and how the real Spring does it.
 Wicket should change its behavior so that {{@Inject}} is always required. If 
 the dependency is optional the user can use {{@SpringBean(required=false)}} 
 as always.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5661) IRequestHandler implementation for RestartResponseAtInterceptPageException

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088722#comment-14088722
 ] 

Hendy Irawan commented on WICKET-5661:
--

Thank you for the tip :)

 IRequestHandler implementation for RestartResponseAtInterceptPageException
 --

 Key: WICKET-5661
 URL: https://issues.apache.org/jira/browse/WICKET-5661
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.16.0
Reporter: Hendy Irawan
Priority: Minor

 I'd like to throw e.g. {{NotLoggedInException}} which will be handled by 
 {{onException}} which then does a {{RestartResponseAtInterceptPage}}:
 {code}
 private final class NotLoggedInRequestCycleListener extends 
 AbstractRequestCycleListener {
   @Override
   public IRequestHandler onException(RequestCycle cycle, Exception ex) {
   // Since our actual exception is wrapped, we need to find based 
 on the chain
   final ListThrowable chain = Throwables.getCausalChain(ex);
   final NotLoggedInException notLoggedInException = 
 Iterables.getFirst(
   Iterables.filter(chain, 
 NotLoggedInException.class), null);
   if (notLoggedInException != null) {
   final Url url = cycle.getRequest().getClientUrl();
   log.debug(Got exception  + 
 notLoggedInException.getClass().getName() +  on  + url, ex);
   final SoluvasWebSession session = (SoluvasWebSession) 
 Session.get();
   session.setOriginalUrl(url);
   session.info(Please log in);
   session.dirty();
   throw new 
 RestartResponseAtInterceptPageException(DedicatedLoginPage.class);
   } else {
   return super.onException(cycle, ex);
   }
   }
 }
 {code}
 which doesn't work:
 {code}
 Caused by: javax.servlet.ServletException: Cannot process filter: 
 org.apache.wicket.RestartResponseAtInterceptPageException
   at 
 org.soluvas.web.site.SecuredWicketAtmosphereHandler$CustomFilterChain.doFilter(SecuredWicketAtmosphereHandler.java:201)
   at 
 org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
   at 
 org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
   at 
 org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
   at 
 org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
   at 
 org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
   at 
 org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
   at 
 org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
   at 
 org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344)
   at 
 org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261)
   at 
 org.soluvas.web.site.SecuredWicketAtmosphereHandler$CustomFilterChain.doFilter(SecuredWicketAtmosphereHandler.java:199)
   ... 25 more
 Caused by: org.apache.wicket.RestartResponseAtInterceptPageException
 {code}
 because Wicket requires an {{IRequestHandler}} instead in this phase.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5662) @SpringBean(name=something, required=false) still throws org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'something' is defined

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088721#comment-14088721
 ] 

Hendy Irawan commented on WICKET-5662:
--

Thanks Martin for resolving it quickly :)

 @SpringBean(name=something, required=false) still throws 
 org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean 
 named 'something' is defined
 

 Key: WICKET-5662
 URL: https://issues.apache.org/jira/browse/WICKET-5662
 Project: Wicket
  Issue Type: Bug
  Components: wicket-spring
Affects Versions: 6.16.0
Reporter: Hendy Irawan
Assignee: Martin Grigorov
 Fix For: 7.0.0-M3, 6.17.0


 Example:
 {code}
 public class TwitterLoginLink extends StatelessLinkVoid {
   
   @SpringBean(name=twitterMgr, required=false)
   private TwitterManager twitterMgr;
 {code}
 still throws:
 {code}
 org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean 
 named 'twitterMgr' is defined
 at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:641)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1159)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.isSingleton(AbstractBeanFactory.java:418)
 at 
 org.springframework.context.support.AbstractApplicationContext.isSingleton(AbstractApplicationContext.java:1002)
 at 
 org.apache.wicket.spring.SpringBeanLocator.isSingletonBean(SpringBeanLocator.java)
 at 
 org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue(AnnotProxyFieldValueFactory.java:141)
 at org.apache.wicket.injection.Injector.inject(Injector.java:111)
 at 
 org.apache.wicket.spring.injection.annot.SpringComponentInjector.inject(SpringComponentInjector.java:124)
 at 
 org.apache.wicket.spring.injection.annot.SpringComponentInjector.onInstantiation(SpringComponentInjector.java:130)
 at 
 org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:38)
 at 
 org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:34)
 at 
 org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
 at 
 org.apache.wicket.application.ComponentInstantiationListenerCollection.onInstantiation(ComponentInstantiationListenerCollection.java:33)
 at org.apache.wicket.Component.init(Component.java:686)
 at org.apache.wicket.MarkupContainer.init(MarkupContainer.java:121)
 at 
 org.apache.wicket.markup.html.WebMarkupContainer.init(WebMarkupContainer.java:52)
 at 
 org.apache.wicket.markup.html.link.AbstractLink.init(AbstractLink.java:57)
 at 
 org.apache.wicket.markup.html.link.AbstractLink.init(AbstractLink.java:44)
 at org.apache.wicket.markup.html.link.Link.init(Link.java:105)
 at 
 org.apache.wicket.markup.html.link.StatelessLink.init(StatelessLink.java:42)
 at 
 org.soluvas.web.login.twitter.TwitterLoginLink.init(TwitterLoginLink.java:40)
 at 
 org.soluvas.web.login.DedicatedLoginPanel$FormSignIn.init(DedicatedLoginPanel.java:90)
 at 
 org.soluvas.web.login.DedicatedLoginPanel.onInitialize(DedicatedLoginPanel.java:58)
 at org.apache.wicket.Component.fireInitialize(Component.java:876)
 at org.apache.wicket.MarkupContainer$3.component(MarkupContainer.java:967)
 at org.apache.wicket.MarkupContainer$3.component(MarkupContainer.java:963)
 at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
 at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
 at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
 at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:875)
 at 
 org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:962)
 at org.apache.wicket.Page.isPageStateless(Page.java:463)
 at 
 org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.getPageInfo(AbstractBookmarkableMapper.java:447)
 at 
 org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapHandler(AbstractBookmarkableMapper.java:391)
 at 
 org.apache.wicket.core.request.mapper.MountedMapper.mapHandler(MountedMapper.java:395)
 at 
 org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:215)
 at 
 org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:429)
 at 
 org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:273)
 at 
 org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
 at 
 

[jira] [Created] (WICKET-5661) IRequestHandler implementation for RestartResponseAtInterceptPageException

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5661:


 Summary: IRequestHandler implementation for 
RestartResponseAtInterceptPageException
 Key: WICKET-5661
 URL: https://issues.apache.org/jira/browse/WICKET-5661
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.16.0
Reporter: Hendy Irawan
Priority: Minor


I'd like to throw e.g. {{NotLoggedInException}} which will be handled by 
{{onException}} which then does a {{RestartResponseAtInterceptPage}}:

{code}
private final class NotLoggedInRequestCycleListener extends 
AbstractRequestCycleListener {
@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
// Since our actual exception is wrapped, we need to find based 
on the chain
final ListThrowable chain = Throwables.getCausalChain(ex);
final NotLoggedInException notLoggedInException = 
Iterables.getFirst(
Iterables.filter(chain, 
NotLoggedInException.class), null);
if (notLoggedInException != null) {
final Url url = cycle.getRequest().getClientUrl();
log.debug(Got exception  + 
notLoggedInException.getClass().getName() +  on  + url, ex);
final SoluvasWebSession session = (SoluvasWebSession) 
Session.get();
session.setOriginalUrl(url);
session.info(Please log in);
session.dirty();
throw new 
RestartResponseAtInterceptPageException(DedicatedLoginPage.class);
} else {
return super.onException(cycle, ex);
}
}
}
{code}

which doesn't work:

{code}
Caused by: javax.servlet.ServletException: Cannot process filter: 
org.apache.wicket.RestartResponseAtInterceptPageException
at 
org.soluvas.web.site.SecuredWicketAtmosphereHandler$CustomFilterChain.doFilter(SecuredWicketAtmosphereHandler.java:201)
at 
org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at 
org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at 
org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at 
org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at 
org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at 
org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at 
org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at 
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344)
at 
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261)
at 
org.soluvas.web.site.SecuredWicketAtmosphereHandler$CustomFilterChain.doFilter(SecuredWicketAtmosphereHandler.java:199)
... 25 more
Caused by: org.apache.wicket.RestartResponseAtInterceptPageException
{code}

because Wicket requires an {{IRequestHandler}} instead in this phase.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (WICKET-5662) @SpringBean(name=something, required=false) still throws org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'something' is defined

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5662:


 Summary: @SpringBean(name=something, required=false) still 
throws org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean 
named 'something' is defined
 Key: WICKET-5662
 URL: https://issues.apache.org/jira/browse/WICKET-5662
 Project: Wicket
  Issue Type: Bug
  Components: wicket-spring
Affects Versions: 6.16.0
Reporter: Hendy Irawan


Example:

{code}
public class TwitterLoginLink extends StatelessLinkVoid {

@SpringBean(name=twitterMgr, required=false)
private TwitterManager twitterMgr;
{code}

still throws:

{code}
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 
'twitterMgr' is defined
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:641)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1159)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.isSingleton(AbstractBeanFactory.java:418)
at 
org.springframework.context.support.AbstractApplicationContext.isSingleton(AbstractApplicationContext.java:1002)
at 
org.apache.wicket.spring.SpringBeanLocator.isSingletonBean(SpringBeanLocator.java)
at 
org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue(AnnotProxyFieldValueFactory.java:141)
at org.apache.wicket.injection.Injector.inject(Injector.java:111)
at 
org.apache.wicket.spring.injection.annot.SpringComponentInjector.inject(SpringComponentInjector.java:124)
at 
org.apache.wicket.spring.injection.annot.SpringComponentInjector.onInstantiation(SpringComponentInjector.java:130)
at 
org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:38)
at 
org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:34)
at 
org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
at 
org.apache.wicket.application.ComponentInstantiationListenerCollection.onInstantiation(ComponentInstantiationListenerCollection.java:33)
at org.apache.wicket.Component.init(Component.java:686)
at org.apache.wicket.MarkupContainer.init(MarkupContainer.java:121)
at 
org.apache.wicket.markup.html.WebMarkupContainer.init(WebMarkupContainer.java:52)
at org.apache.wicket.markup.html.link.AbstractLink.init(AbstractLink.java:57)
at org.apache.wicket.markup.html.link.AbstractLink.init(AbstractLink.java:44)
at org.apache.wicket.markup.html.link.Link.init(Link.java:105)
at 
org.apache.wicket.markup.html.link.StatelessLink.init(StatelessLink.java:42)
at 
org.soluvas.web.login.twitter.TwitterLoginLink.init(TwitterLoginLink.java:40)
at 
org.soluvas.web.login.DedicatedLoginPanel$FormSignIn.init(DedicatedLoginPanel.java:90)
at 
org.soluvas.web.login.DedicatedLoginPanel.onInitialize(DedicatedLoginPanel.java:58)
at org.apache.wicket.Component.fireInitialize(Component.java:876)
at org.apache.wicket.MarkupContainer$3.component(MarkupContainer.java:967)
at org.apache.wicket.MarkupContainer$3.component(MarkupContainer.java:963)
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:875)
at 
org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:962)
at org.apache.wicket.Page.isPageStateless(Page.java:463)
at 
org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.getPageInfo(AbstractBookmarkableMapper.java:447)
at 
org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapHandler(AbstractBookmarkableMapper.java:391)
at 
org.apache.wicket.core.request.mapper.MountedMapper.mapHandler(MountedMapper.java:395)
at 
org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:215)
at org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:429)
at 
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:273)
at 
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at 
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)

[jira] [Created] (WICKET-5635) Provide a way to modify ResourceReferenceRegistry.DefaultResourceReferenceFactory externally to be used by wicket-bootstrap-less

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5635:


 Summary: Provide a way to modify 
ResourceReferenceRegistry.DefaultResourceReferenceFactory externally to be used 
by wicket-bootstrap-less
 Key: WICKET-5635
 URL: https://issues.apache.org/jira/browse/WICKET-5635
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.16.0
Reporter: Hendy Irawan


As described in 
https://github.com/l0rdn1kk0n/wicket-bootstrap/issues/409#issuecomment-48505042 
:

Add

{code}
@Override
protected ResourceReferenceRegistry newResourceReferenceRegistry() {
return new LessAwareRR(super.newResourceReferenceRegistry());
}

private static class LessAwareRR extends ResourceReferenceRegistry {
private final ResourceReferenceRegistry delegate;

private LessAwareRR(ResourceReferenceRegistry delegate) {
this.delegate = delegate;
}

@Override
protected ResourceReference 
createDefaultResourceReference(ResourceReference.Key key) {
if (key.getName().endsWith(.less)) {
return new LessResourceReference(key);
}
return super.createDefaultResourceReference(key);
}
}
{code}

to WicketApplication.java and it starts to work as desired.

Another way to do the same is:

{code}
@Override
protected ResourceReferenceRegistry newResourceReferenceRegistry() {
return new ResourceReferenceRegistry(new LessRRFactory());
}

private static class LessRRFactory extends 
ResourceReferenceRegistry.DefaultResourceReferenceFactory {

@Override
public ResourceReference create(ResourceReference.Key key) {
if (key.getName().endsWith(.less)) {
return new LessResourceReference(key);
} else {
return super.create(key);
}
}
}
{code}

Unfortunately at the moment there is no way to do this automatically with 
{{de.agilecoders.wicket.less.BootstrapLess#install(Appllication)}}.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5610) Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047079#comment-14047079
 ] 

Hendy Irawan commented on WICKET-5610:
--

One of the issues that need to be handled if using [~mgrigorov]'s [suggested 
method 
here|https://issues.apache.org/jira/browse/WICKET-4466?focusedCommentId=13238192page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13238192],
 which I use as follows :

{code}
// Use CDN jQuery if we're in production
IBootstrapSettings bootstrapSettings = Bootstrap.getSettings(this);
if (bootstrapSettings.useCdnResources()) {
getJavaScriptLibrarySettings().setJQueryReference(new 
UrlResourceReference(

Url.parse(//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js)));
}
{code}

Is reminding myself to change the jQuery version when Wicket's jQuery version 
changes...

...and this applies to any JavaScript/CSS library I use from CDN.

Having the {{useCdnResources}} setting in Wicket which, if enabled, will allow 
Wicket to use Google's CDN as default as [~mgrigorov] [suggested 
above|https://issues.apache.org/jira/browse/WICKET-5610?focusedCommentId=14032558page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14032558],
 is a great solution. :)

 Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap
 --

 Key: WICKET-5610
 URL: https://issues.apache.org/jira/browse/WICKET-5610
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan

 wicket-bootstrap has a 
 [IBootstrapSettings.useCdnResources()|https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/bootstrap-parent-0.9.3/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java]
  which is a great idea.
 Wicket should adopt this setting in core. And when true, Wicket JS libraries 
 such as jQuery should use public CDN.
 This setting will default to true on {{DEPLOYMENT}}, and false for 
 {{DEVELOPMENT}} (but of course, can be set to true programmatically).
 wicket-bootstrap will then can use CDN settings from wicket core.
 In addition, I would suggest a variant of {{JavaScriptResourceReference}} 
 that also has an additional parameter for {{cdnUrl}} (which can be {{String}} 
 for convenience or {{Url}} for strictness, up to you), e.g. :
 {code}
   public HowlerJavaScriptReference() {
   super(HowlerJavaScriptReference.class, howler.js, 
 //cdnjs.cloudflare.com/ajax/libs/howler/1.1.17/howler.min.js);
   }
 {code}
 its behavior will switch based on {{useCdnResources}} setting, and very easy 
 and practical to code this way. :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (WICKET-5621) Store more information to/with BufferedWebResponse that survives multi-RequestCycle redirect

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-5621:
-

Issue Type: Improvement  (was: Bug)

 Store more information to/with BufferedWebResponse that survives 
 multi-RequestCycle redirect
 

 Key: WICKET-5621
 URL: https://issues.apache.org/jira/browse/WICKET-5621
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.16.0
Reporter: Hendy Irawan

 From [~mgrigorov] :
 It seems {{org.apache.wicket.response.filter.ServerAndClientTimeFilter}} and 
 the other similar filters lie because they use the current request cycle's 
 begin time. The processing time when there is a buffered 
 response should be quite small. 
 The reported time at the moment is not very useful. 
 It seems we need to store more information to/with BufferedWebResponse to 
 be able to cover the requirements in this mail thread and 
 WICKET-5129.
 Original thread and use case: 
 http://apache-wicket.1842946.n4.nabble.com/How-to-get-PageClass-from-BufferedResponseRequestHandler-And-how-to-quot-link-quot-related-requests-td4666247.html



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (WICKET-5621) Store more information to/with BufferedWebResponse that survives multi-RequestCycle redirect

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5621:


 Summary: Store more information to/with BufferedWebResponse that 
survives multi-RequestCycle redirect
 Key: WICKET-5621
 URL: https://issues.apache.org/jira/browse/WICKET-5621
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.16.0
Reporter: Hendy Irawan


From [~mgrigorov] :

It seems {{org.apache.wicket.response.filter.ServerAndClientTimeFilter}} and 
the other similar filters lie because they use the current request cycle's 
begin time. The processing time when there is a buffered 
response should be quite small. 

The reported time at the moment is not very useful. 
It seems we need to store more information to/with BufferedWebResponse to 
be able to cover the requirements in this mail thread and 
WICKET-5129.

Original thread and use case: 
http://apache-wicket.1842946.n4.nabble.com/How-to-get-PageClass-from-BufferedResponseRequestHandler-And-how-to-quot-link-quot-related-requests-td4666247.html




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (WICKET-5621) Store more information to/with BufferedWebResponse that survives multi-RequestCycle redirect

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-5621:
-

Description: 
From [~mgrigorov] :

It seems {{org.apache.wicket.response.filter.ServerAndClientTimeFilter}} and 
the other similar filters lie because they use the current request cycle's 
begin time. The processing time when there is a buffered response should be 
quite small. 

The reported time at the moment is not very useful. 
It seems we need to store more information to/with {{BufferedWebResponse}} to 
be able to cover the requirements in this mail thread and WICKET-5129.

Original thread and use case: 
http://apache-wicket.1842946.n4.nabble.com/How-to-get-PageClass-from-BufferedResponseRequestHandler-And-how-to-quot-link-quot-related-requests-td4666247.html


  was:
From [~mgrigorov] :

It seems {{org.apache.wicket.response.filter.ServerAndClientTimeFilter}} and 
the other similar filters lie because they use the current request cycle's 
begin time. The processing time when there is a buffered 
response should be quite small. 

The reported time at the moment is not very useful. 
It seems we need to store more information to/with BufferedWebResponse to 
be able to cover the requirements in this mail thread and 
WICKET-5129.

Original thread and use case: 
http://apache-wicket.1842946.n4.nabble.com/How-to-get-PageClass-from-BufferedResponseRequestHandler-And-how-to-quot-link-quot-related-requests-td4666247.html



 Store more information to/with BufferedWebResponse that survives 
 multi-RequestCycle redirect
 

 Key: WICKET-5621
 URL: https://issues.apache.org/jira/browse/WICKET-5621
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.16.0
Reporter: Hendy Irawan

 From [~mgrigorov] :
 It seems {{org.apache.wicket.response.filter.ServerAndClientTimeFilter}} and 
 the other similar filters lie because they use the current request cycle's 
 begin time. The processing time when there is a buffered response should be 
 quite small. 
 The reported time at the moment is not very useful. 
 It seems we need to store more information to/with {{BufferedWebResponse}} to 
 be able to cover the requirements in this mail thread and WICKET-5129.
 Original thread and use case: 
 http://apache-wicket.1842946.n4.nabble.com/How-to-get-PageClass-from-BufferedResponseRequestHandler-And-how-to-quot-link-quot-related-requests-td4666247.html



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5610) Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14032567#comment-14032567
 ] 

Hendy Irawan commented on WICKET-5610:
--

Yay! :)

I agree, Google CDN is default when {{useCdnResources}} is enabled, but it's 
just as easy to switch to any other CDN (or switch back to a local jQuery) if 
desired by the app developer.

Thanks [~mgrigorov] :)

 Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap
 --

 Key: WICKET-5610
 URL: https://issues.apache.org/jira/browse/WICKET-5610
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan

 wicket-bootstrap has a 
 [IBootstrapSettings.useCdnResources()|https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/bootstrap-parent-0.9.3/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java]
  which is a great idea.
 Wicket should adopt this setting in core. And when true, Wicket JS libraries 
 such as jQuery should use public CDN.
 This setting will default to true on {{DEPLOYMENT}}, and false for 
 {{DEVELOPMENT}} (but of course, can be set to true programmatically).
 wicket-bootstrap will then can use CDN settings from wicket core.
 In addition, I would suggest a variant of {{JavaScriptResourceReference}} 
 that also has an additional parameter for {{cdnUrl}} (which can be {{String}} 
 for convenience or {{Url}} for strictness, up to you), e.g. :
 {code}
   public HowlerJavaScriptReference() {
   super(HowlerJavaScriptReference.class, howler.js, 
 //cdnjs.cloudflare.com/ajax/libs/howler/1.1.17/howler.min.js);
   }
 {code}
 its behavior will switch based on {{useCdnResources}} setting, and very easy 
 and practical to code this way. :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5603) OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in Chrome v35

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027672#comment-14027672
 ] 

Hendy Irawan commented on WICKET-5603:
--

I was hoping this to get into 6.16 :( but anyway, if 6.16 has been released, I 
haven't seen it in maven.org yet?

 OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in 
 Chrome v35
 

 Key: WICKET-5603
 URL: https://issues.apache.org/jira/browse/WICKET-5603
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.9.1, 7.0.0-M1
 Environment: Chrome 35.0.1916.114
Reporter: Andrey Krasnopolsky
Assignee: Andrea Del Bene
 Fix For: 7.0.0-M3, 6.17.0

 Attachments: test.zip, wicket.patch


 I have a DropDownChoice with attached OnChangeAjaxBehavior, like this:
 {code:borderStyle=solid}
 new DropDownChoice(dd, new Model(), Arrays.asList( First, Second))
 .add( new OnChangeAjaxBehavior() {
 @Override
 protected void onUpdate(AjaxRequestTarget target) {
 System.out.println( update );
 }
 });
 {code}
 When selecting any of drop down options, two Ajax requests being generated.
 It behaves OK in IE, FF and Chrome v34, only Chrome v35 is affected 
  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5610) Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019662#comment-14019662
 ] 

Hendy Irawan commented on WICKET-5610:
--

bq. Now it sounds to me like we can add a simple boolean setting in 
{{IResourceSettings}} ({{useCdnResources}}) and that's all in Wicket code.
bq. Third party libs and apps can use this setting to do their best to use any 
CDN for their needs.

Agreed :))

bq. I still don't like Wicket itself to:
bq. 1) set useCdnResources to true in deployment mode

Agreed also, on second thought this was a bad proposition on my part. 
Especially true because Wicket websites can be intranet apps without internet 
connection, and they still count as {{deployment}}.

bq. 2) to set a default CDN url for JQuery

This is entirely up to you. Although, why not? Since it depends on 
{{useCdnResources}} (which is false by default) anyway (with all its gotchas). 
And with/without {{useCdnResources}}, appdev can still 
resourcereference-replace jQuery with his own preference.

 Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap
 --

 Key: WICKET-5610
 URL: https://issues.apache.org/jira/browse/WICKET-5610
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan

 wicket-bootstrap has a 
 [IBootstrapSettings.useCdnResources()|https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/bootstrap-parent-0.9.3/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java]
  which is a great idea.
 Wicket should adopt this setting in core. And when true, Wicket JS libraries 
 such as jQuery should use public CDN.
 This setting will default to true on {{DEPLOYMENT}}, and false for 
 {{DEVELOPMENT}} (but of course, can be set to true programmatically).
 wicket-bootstrap will then can use CDN settings from wicket core.
 In addition, I would suggest a variant of {{JavaScriptResourceReference}} 
 that also has an additional parameter for {{cdnUrl}} (which can be {{String}} 
 for convenience or {{Url}} for strictness, up to you), e.g. :
 {code}
   public HowlerJavaScriptReference() {
   super(HowlerJavaScriptReference.class, howler.js, 
 //cdnjs.cloudflare.com/ajax/libs/howler/1.1.17/howler.min.js);
   }
 {code}
 its behavior will switch based on {{useCdnResources}} setting, and very easy 
 and practical to code this way. :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5611) Add AjaxChannel.DEFAULT constant = 0

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019957#comment-14019957
 ] 

Hendy Irawan commented on WICKET-5611:
--

[~svenmeier] my use case is for {{AutoDisableAjaxButton}}. So by using 
{{Type.ACTIVE}}, I'd like the second click of the button (or any other Ajax 
activity) will not do anything.

I tried using my own channel before, but then I stumbled upon a side effect of 
WICKET-5603. But even if it's fixed, the problem is I don't want 2 concurrent 
ajax requests to happen. I'd like only a single running ajax, if there's 
already an ajax then the button should do nothing.

 Add AjaxChannel.DEFAULT constant = 0
 --

 Key: WICKET-5611
 URL: https://issues.apache.org/jira/browse/WICKET-5611
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan
Priority: Trivial

  Can I request AjaxChannel.DEFAULT public static constant with a value of 0 
 ? I don't feel comfortable typing 0 there, I much prefer a constant. 
 http://apache-wicket.1842946.n4.nabble.com/ListenerInvocationNotAllowedException-and-EmptyRequestHandler-tp4663618p4666126.html



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5611) Add AjaxChannel.DEFAULT constant = 0

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14020693#comment-14020693
 ] 

Hendy Irawan commented on WICKET-5611:
--

perhaps you meant the channel will switch...

(note to self: perhaps I should question the need for using {{ACTIVE}}? since 
the button will be _disabled_ (without visual indication) if there's e.g. 
{{onchange}} event but what you actually want to do is wait for {{onchange}} to 
finish _then_ trigger the submit)

 Add AjaxChannel.DEFAULT constant = 0
 --

 Key: WICKET-5611
 URL: https://issues.apache.org/jira/browse/WICKET-5611
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan
Priority: Trivial

  Can I request AjaxChannel.DEFAULT public static constant with a value of 0 
 ? I don't feel comfortable typing 0 there, I much prefer a constant. 
 http://apache-wicket.1842946.n4.nabble.com/ListenerInvocationNotAllowedException-and-EmptyRequestHandler-tp4663618p4666126.html



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5610) Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14018730#comment-14018730
 ] 

Hendy Irawan commented on WICKET-5610:
--

It's OK if Wicket uses default jQuery in any case.

My suggestion was to add {{useCdnResources}} setting, and additionally a 
{{JavaScriptResourceReference}} variant that developers can use.

So, this less about Wicket's jQuery and more about standardized way to provide 
CDN awareness in Wicket libraries such as 
[wicket-bootstrap|https://github.com/l0rdn1kk0n/wicket-bootstrap] and 
[soluvas-web|https://github.com/soluvas/soluvas-web].

 Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap
 --

 Key: WICKET-5610
 URL: https://issues.apache.org/jira/browse/WICKET-5610
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan

 wicket-bootstrap has a 
 [IBootstrapSettings.useCdnResources()|https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/bootstrap-parent-0.9.3/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java]
  which is a great idea.
 Wicket should adopt this setting in core. And when true, Wicket JS libraries 
 such as jQuery should use public CDN.
 This setting will default to true on {{DEPLOYMENT}}, and false for 
 {{DEVELOPMENT}} (but of course, can be set to true programmatically).
 wicket-bootstrap will then can use CDN settings from wicket core.
 In addition, I would suggest a variant of {{JavaScriptResourceReference}} 
 that also has an additional parameter for {{cdnUrl}} (which can be {{String}} 
 for convenience or {{Url}} for strictness, up to you), e.g. :
 {code}
   public HowlerJavaScriptReference() {
   super(HowlerJavaScriptReference.class, howler.js, 
 //cdnjs.cloudflare.com/ajax/libs/howler/1.1.17/howler.min.js);
   }
 {code}
 its behavior will switch based on {{useCdnResources}} setting, and very easy 
 and practical to code this way. :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (WICKET-5612) If Wicket JS libs are moved to footer, AbstractAutoCompleteBehavior throws Uncaught ReferenceError: Wicket is not defined

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-5612:
-

Attachment: wicketrefe.png

 If Wicket JS libs are moved to footer, AbstractAutoCompleteBehavior throws 
 Uncaught ReferenceError: Wicket is not defined
 ---

 Key: WICKET-5612
 URL: https://issues.apache.org/jira/browse/WICKET-5612
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
 Environment: wicket-bootstrap
Reporter: Hendy Irawan
 Attachments: wicketrefe.png


 I'm moving all JS libs to footer (using wicket-bootstrap also), which works 
 very well because Wicket's {{ResourceReference}} has {{getDependencies()}} 
 (thanks!! :) ).
 However {{AutoCompleteTextField}} is giving JavaScript error, particularly in 
 {{AbstractAutoCompleteBehavior}} here:
 {code}
   private void renderAutocompleteHead(final IHeaderResponse response)
   {
   
 response.render(JavaScriptHeaderItem.forReference(AUTOCOMPLETE_JS));
   final String id = getComponent().getMarkupId();
   String indicatorId = findIndicatorId();
   if (Strings.isEmpty(indicatorId))
   {
   indicatorId = null;
   }
   else
   {
   indicatorId = ' + indicatorId + ';
   }
   String initJS = String.format(new 
 Wicket.AutoComplete('%s','%s',%s,%s);, id,
   getCallbackUrl(), constructSettingsJS(), indicatorId);
   final OnDomReadyHeaderItem onDomReady = 
 OnDomReadyHeaderItem.forScript(initJS);
   response.render(new WrappedHeaderItem(onDomReady));
   }
 {code}
 Error:
 {code}
 Uncaught ReferenceError: Wicket is not defined ?3:6
 (anonymous function) ?3:6
 {code}
 First lines of rendered HTML:
 {code}
 !DOCTYPE html
 html lang=
 headlink rel=stylesheet type=text/css 
 href=../wicket/resource/org.apache.wicket.devutils.debugbar.DebugBar/wicket-debugbar-ver-1399102536000.css
  /
 script type=text/javascript 
 /*![CDATA[*/
 Wicket.Event.add(window, domready, function(event) { new 
 Wicket.AutoComplete('searchTexte','./?3-1.IBehaviorListener.1-navbar-searchForm-searchText',{preselect:
  false,maxHeight: -1,adjustInputWidth: true,useSmartPositioning: 
 false,useHideShowCoveredIEFix: true,showListOnEmptyInput: 
 false,ignoreBordersWhenPositioning: true,showListOnFocusGain: 
 false,throttleDelay: 300,minInputLength: 1,parameterName: 
 'q',showCompleteListOnFocusGain: false},null);;});
 /*]]*/
 /script
 ...
 {code}
 Suggestion: Change to {{OnLoadHeaderItem}} instead, or a way to make sure the 
 script executes after Wicket libraries are loaded.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (WICKET-5612) If Wicket JS libs are moved to footer, AbstractAutoCompleteBehavior throws Uncaught ReferenceError: Wicket is not defined

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5612:


 Summary: If Wicket JS libs are moved to footer, 
AbstractAutoCompleteBehavior throws Uncaught ReferenceError: Wicket is not 
defined
 Key: WICKET-5612
 URL: https://issues.apache.org/jira/browse/WICKET-5612
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
 Environment: wicket-bootstrap
Reporter: Hendy Irawan
 Attachments: wicketrefe.png

I'm moving all JS libs to footer (using wicket-bootstrap also), which works 
very well because Wicket's {{ResourceReference}} has {{getDependencies()}} 
(thanks!! :) ).

However {{AutoCompleteTextField}} is giving JavaScript error, particularly in 
{{AbstractAutoCompleteBehavior}} here:

{code}
private void renderAutocompleteHead(final IHeaderResponse response)
{

response.render(JavaScriptHeaderItem.forReference(AUTOCOMPLETE_JS));
final String id = getComponent().getMarkupId();

String indicatorId = findIndicatorId();
if (Strings.isEmpty(indicatorId))
{
indicatorId = null;
}
else
{
indicatorId = ' + indicatorId + ';
}

String initJS = String.format(new 
Wicket.AutoComplete('%s','%s',%s,%s);, id,
getCallbackUrl(), constructSettingsJS(), indicatorId);

final OnDomReadyHeaderItem onDomReady = 
OnDomReadyHeaderItem.forScript(initJS);

response.render(new WrappedHeaderItem(onDomReady));
}
{code}

Error:

{code}
Uncaught ReferenceError: Wicket is not defined ?3:6
(anonymous function) ?3:6
{code}

First lines of rendered HTML:

{code}
!DOCTYPE html
html lang=
headlink rel=stylesheet type=text/css 
href=../wicket/resource/org.apache.wicket.devutils.debugbar.DebugBar/wicket-debugbar-ver-1399102536000.css
 /
script type=text/javascript 
/*![CDATA[*/
Wicket.Event.add(window, domready, function(event) { new 
Wicket.AutoComplete('searchTexte','./?3-1.IBehaviorListener.1-navbar-searchForm-searchText',{preselect:
 false,maxHeight: -1,adjustInputWidth: true,useSmartPositioning: 
false,useHideShowCoveredIEFix: true,showListOnEmptyInput: 
false,ignoreBordersWhenPositioning: true,showListOnFocusGain: 
false,throttleDelay: 300,minInputLength: 1,parameterName: 
'q',showCompleteListOnFocusGain: false},null);;});
/*]]*/
/script
...
{code}

Suggestion: Change to {{OnLoadHeaderItem}} instead, or a way to make sure the 
script executes after Wicket libraries are loaded.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (WICKET-5585) Wicket Extension Automplete does not work well with JavaScriptFilteredIntoFooterHeaderResponse

[Hendy Irawan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WICKET-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendy Irawan updated WICKET-5585:
-

Attachment: mantapgan.jpg

Thank you [~mgrigorov] !

!mantapgan.jpg!

Awesome... or as us Indonesians say, mantap gan!! [~rudi] :)

 Wicket Extension Automplete does not work well with 
 JavaScriptFilteredIntoFooterHeaderResponse
 --

 Key: WICKET-5585
 URL: https://issues.apache.org/jira/browse/WICKET-5585
 Project: Wicket
  Issue Type: Improvement
  Components: wicket-extensions
Affects Versions: 6.15.0
 Environment: Ubuntu Java 7
Reporter: Thibault Kruse
Assignee: Martin Grigorov
Priority: Minor
 Fix For: 6.16.0, 7.0.0-M2

 Attachments: mantapgan.jpg, wicket-autocomplete.tar.gz


 When using JavaScriptFilteredIntoFooterHeaderResponse to render JS items at 
 the bottom of the document body, this does not affect OnDomReadyHeaderItems. 
 Wicket Extensions Autocomplete Textfield relies on such a 
 OnDomReadyHeaderItem. As a consequence, when using both, the first item in 
 the document HEAD calls Wicket.AutoComplete before the respective wicket js 
 file has been loaded, breaking the Autocomplete Textfield. 
 Additionally JavaScriptFilteredIntoFooterHeaderResponse is final, so it 
 cannot be trivially patched. our current workaround was to copy  paste 
 JavaScriptFilteredIntoFooterHeaderResponse using a custom filter.
 Not sure how best to fix this.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5610) Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019505#comment-14019505
 ] 

Hendy Irawan commented on WICKET-5610:
--

Basically to save typing and finding things.

While Wicket already has a mechanism to use CDN, it _requires_ both 
programmatic coding (I think configurability is great and very flexible, just 
as the rest of Wicket is.) and a {{useCdnResources()}} flag somewhere.

The {{useCdnResources()}} flag is my primary suggestion here, let it be on 
wicket-core, so that it can be reused by any library/code that wants it. 
Currently wicket-bootstrap and webjars use their own {{useCdnResources()}}, it 
would be great if it can set the default value based on wicket's 
{{useCdnResources()}} (my preference would be to just remove it and use 
Wicket's, but it's up to the library creator for that decision). Of course 
appdev can still set any of these flags manually.

IMHO a nice side-effect of {{useCdnResources()}} is ability to just turn 
everything off. During diagnostics, rather by knowing which setting for each 
library to turn it on/off (and a library may even depend on 
{{isDeploymentConfig()}} which is too broad and isn't ideal to turn it off), 
setting {{useCdnResources(false)}} would be sufficient to switch everything 
back to local and see if the problem persists.

My second suggestion is to provide a way to specify _default_ CDNs by just 
turning {{useCdnResources()}}.
It's true that some people will use Google CDNs, other Akamai's, other 
JQuery's own one, other a private one, so the default is not a forced one, but 
still can be changed as always been, via resource replacement or any other 
means.

 Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap
 --

 Key: WICKET-5610
 URL: https://issues.apache.org/jira/browse/WICKET-5610
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan

 wicket-bootstrap has a 
 [IBootstrapSettings.useCdnResources()|https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/bootstrap-parent-0.9.3/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java]
  which is a great idea.
 Wicket should adopt this setting in core. And when true, Wicket JS libraries 
 such as jQuery should use public CDN.
 This setting will default to true on {{DEPLOYMENT}}, and false for 
 {{DEVELOPMENT}} (but of course, can be set to true programmatically).
 wicket-bootstrap will then can use CDN settings from wicket core.
 In addition, I would suggest a variant of {{JavaScriptResourceReference}} 
 that also has an additional parameter for {{cdnUrl}} (which can be {{String}} 
 for convenience or {{Url}} for strictness, up to you), e.g. :
 {code}
   public HowlerJavaScriptReference() {
   super(HowlerJavaScriptReference.class, howler.js, 
 //cdnjs.cloudflare.com/ajax/libs/howler/1.1.17/howler.min.js);
   }
 {code}
 its behavior will switch based on {{useCdnResources}} setting, and very easy 
 and practical to code this way. :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (WICKET-5610) Adopt IApplicationSettings.useCdnResources() from wicket-bootstrap

[Hendy Irawan (JIRA)]

Hendy Irawan created WICKET-5610:


 Summary: Adopt IApplicationSettings.useCdnResources() from 
wicket-bootstrap
 Key: WICKET-5610
 URL: https://issues.apache.org/jira/browse/WICKET-5610
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 6.15.0
Reporter: Hendy Irawan


wicket-bootstrap has a 
[IBootstrapSettings.useCdnResources()|https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/bootstrap-parent-0.9.3/bootstrap-core/src/main/java/de/agilecoders/wicket/core/settings/IBootstrapSettings.java]
 which is a great idea.

Wicket should adopt this setting in core. And when true, Wicket JS libraries 
such as jQuery should use public CDN.

This setting will default to true on DEPLOYMENT, and false for DEVELOPMENT (but 
of course, can be set to true programmatically).

wicket-bootstrap will then can use CDN settings from wicket core.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (WICKET-5603) OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in Chrome v35

[Hendy Irawan (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14018440#comment-14018440
 ] 

Hendy Irawan commented on WICKET-5603:
--

Hopefully this gets fixed in Wicket 6.16. We're using {{OnChangeAjaxBehavior}} 
extensively :)

[~bitstorm] Thanks for the workaround. 

 OnChangeAjaxBehavior attached to DropDownChoice produces two Ajax requests in 
 Chrome v35
 

 Key: WICKET-5603
 URL: https://issues.apache.org/jira/browse/WICKET-5603
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 6.9.1
 Environment: Chrome 35.0.1916.114
Reporter: Andrey Krasnopolsky
Assignee: Andrea Del Bene
 Attachments: test.zip


 I have a DropDownChoice with attached OnChangeAjaxBehavior, like this:
 {code:borderStyle=solid}
 new DropDownChoice(dd, new Model(), Arrays.asList( First, Second))
 .add( new OnChangeAjaxBehavior() {
 @Override
 protected void onUpdate(AjaxRequestTarget target) {
 System.out.println( update );
 }
 });
 {code}
 When selecting any of drop down options, two Ajax requests being generated.
 It behaves OK in IE, FF and Chrome v34, only Chrome v35 is affected 
  



--
This message was sent by Atlassian JIRA
(v6.2#6252)