date:20111215

[jira] [Updated] (WICKET-4273) Rendering of resources in the header with dependency resolving and support for bundles

2011-12-15 Thread Emond Papegaaij (Updated) (JIRA)

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

Emond Papegaaij updated WICKET-4273:

Attachment: WICKET-4273.patch

This patch contains all the work described in this ticket, including the fix
for WICKET-4091 and WICKET-4247.

Rendering of resources in the header with dependency resolving and support
for bundles
--

Key: WICKET-4273
URL: https://issues.apache.org/jira/browse/WICKET-4273
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 6.0.0
Reporter: Emond Papegaaij
Attachments: WICKET-4273.patch

The current API for resources does not allow resources to define dependencies
nor does it provide native support for bundles. In short, a resource
reference should be able to define that it requires other resources to be
available as well, much like AbstractResourceDependentResourceReference does.
This support should be part of ResourceReference itself and should not be
limited to just references (anything that can be added to a header can be a
dependency).
Furthermore, many have requested support for resource bundles. A bundle
combines several resources of the same type into one. When a bundle is
rendered, all resources that are part of the bundle should not be rendered,
otherwise you'll end up with duplicate resources. Although it is often
requested that all resources should be combined into one (or two, a js and a
css), I do not believe this is a good solution as there is no way of knowing
which page requires which resources. In the worst case, this will cause every
page to contain a different permutation of resources, requiring the user to
download all resources again and again for every page. Therefore, the bundles
require the developer to manually register bundles. If one resource from a
bundle is required, the bundle will rendered instead.
Finally, the default HeaderResponse renders many script tags for onDomReady
and onLoad scripts. These scripts should be combined into one or two script
tags.
I'm currently working on implementing these features at Github. My progress
can be found at https://github.com/papegaaij/wicket/tree/wicket+wiquery

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4273) Rendering of resources in the header with dependency resolving and support for bundles

2011-12-15 Thread Emond Papegaaij (Updated) (JIRA)

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

Emond Papegaaij updated WICKET-4273:

Attachment: (was: WICKET-4273.patch)

Rendering of resources in the header with dependency resolving and support
for bundles
--

[jira] [Updated] (WICKET-4273) Rendering of resources in the header with dependency resolving and support for bundles

2011-12-15 Thread Emond Papegaaij (Updated) (JIRA)

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

Emond Papegaaij updated WICKET-4273:

Attachment: WICKET-4273.patch

Revised patch that fixes testcase failures and adds some Args.notNull checks

Rendering of resources in the header with dependency resolving and support
for bundles
--

svn commit: r1214702 [7/7] - in /wicket/trunk: wicket-core/src/main/java/org/apache/wicket/ wicket-core/src/main/java/org/apache/wicket/ajax/ wicket-core/src/main/java/org/apache/wicket/ajax/form/ wic

2011-12-15 Thread mgrigorov

Added: 
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceB.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceB.java?rev=1214702view=auto
==
--- 
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceB.java
 (added)
+++ 
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceB.java
 Thu Dec 15 11:14:20 2011
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.resource.aggregator;
+
+import static 
org.apache.wicket.resource.header.JavaScriptHeaderItem.forReference;
+
+import java.util.Collections;
+
+import org.apache.wicket.request.resource.JavaScriptResourceReference;
+import org.apache.wicket.resource.header.HeaderItem;
+
+/**
+ * js resource with dep on A
+ */
+public class ResourceReferenceB extends JavaScriptResourceReference
+{
+   private static final long serialVersionUID = 1L;
+
+   /**
+* Construct.
+*/
+   public ResourceReferenceB()
+   {
+   super(ResourceAggregatorTest.class, b.js);
+   }
+
+   @Override
+   public Iterable? extends HeaderItem getDependencies()
+   {
+   return Collections.singletonList(forReference(new 
ResourceReferenceA()));
+   }
+}
\ No newline at end of file

Added: 
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceC.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceC.java?rev=1214702view=auto
==
--- 
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceC.java
 (added)
+++ 
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceC.java
 Thu Dec 15 11:14:20 2011
@@ -0,0 +1,46 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.resource.aggregator;
+
+import static 
org.apache.wicket.resource.header.JavaScriptHeaderItem.forReference;
+
+import java.util.Collections;
+
+import org.apache.wicket.request.resource.JavaScriptResourceReference;
+import org.apache.wicket.resource.header.HeaderItem;
+
+/**
+ * another js resource with dep on A
+ */
+public class ResourceReferenceC extends JavaScriptResourceReference
+{
+   private static final long serialVersionUID = 1L;
+
+   /**
+* Construct.
+*/
+   public ResourceReferenceC()
+   {
+   super(ResourceAggregatorTest.class, c.js);
+   }
+
+   @Override
+   public Iterable? extends HeaderItem getDependencies()
+   {
+   return Collections.singletonList(forReference(new 
ResourceReferenceA()));
+   }
+}
\ No newline at end of file

Added: 
wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceCirc1.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/resource/aggregator/ResourceReferenceCirc1.java?rev=1214702view=auto
==
---

[jira] [Created] (WICKET-4295) Allow outer forms to optionally participate in a nested form's submit

2011-12-15 Thread Carl-Eric Menzel (Created) (JIRA)

Allow outer forms to optionally participate in a nested form's submit
-

 Key: WICKET-4295
 URL: https://issues.apache.org/jira/browse/WICKET-4295
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.5.3, 1.4.19, 6.0.0
Reporter: Carl-Eric Menzel


When a nested form is submitted via a submitting component such as a Button, 
the browser submits the entire form, and Wicket then determines the correct 
nested form based on the submitting component's request parameter. Then the 
nested form is the only one to be processed.

This is a good default, but sometimes it is desirable to have the outer form 
submitted as well. For example, a panel that can be used on its own will have a 
form of its own and also submit button, but it could also be integrated in a 
larger form.

The inner form could be modified to allow submitting an outer form, but this 
seems to be rather inelegant, especially for more widely re-used components. It 
becomes especially unwieldy when you have a deep component hierarchy.

Resource string resolution is done in a way that the surrounding containers and 
the page can override a particular component's strings. I propose that Form 
gets a new boolean overridable method wantSubmitOnNestedFormSubmit that 
returns false by default to keep behavior the same as in previous versions. 
onFormSubmitted will then check from the nested submitted form outwards to find 
the outermost form where this flag is true. This outermost form, if any, will 
then be submitted.

This way, an outer form can decide it wants to join the inner form's submit 
without the inner form having to be modified.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4295) Allow outer forms to optionally participate in a nested form's submit

2011-12-15 Thread Carl-Eric Menzel (Updated) (JIRA)

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

Carl-Eric Menzel updated WICKET-4295:
-

Attachment:
WICKET-4295-trunk-allow-outer-forms-to-participate-in-the-submit-of-ne.patch

WICKET-4295-1.5-allow-outer-forms-to-participate-in-the-submit-of-ne.patch

WICKET-4295-1.4-allow-outer-forms-to-participate-in-the-submit-of-ne.patch

A set of patches for wicket-1.4.x, wicket-1.5.x and trunk that add the new
method to Form as described above. The changes to Form include full comments. I
also provide a test that demonstrates the new flag's behavior. The build still
runs cleanly, so I assume nothing is broken by this.

Allow outer forms to optionally participate in a nested form's submit
-

Key: WICKET-4295
URL: https://issues.apache.org/jira/browse/WICKET-4295
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.4.19, 1.5.3, 6.0.0
Reporter: Carl-Eric Menzel
Attachments:
WICKET-4295-1.4-allow-outer-forms-to-participate-in-the-submit-of-ne.patch,
WICKET-4295-1.5-allow-outer-forms-to-participate-in-the-submit-of-ne.patch,
WICKET-4295-trunk-allow-outer-forms-to-participate-in-the-submit-of-ne.patch

When a nested form is submitted via a submitting component such as a Button,
the browser submits the entire form, and Wicket then determines the correct
nested form based on the submitting component's request parameter. Then the
nested form is the only one to be processed.
This is a good default, but sometimes it is desirable to have the outer form
submitted as well. For example, a panel that can be used on its own will have
a form of its own and also submit button, but it could also be integrated in
a larger form.
The inner form could be modified to allow submitting an outer form, but this
seems to be rather inelegant, especially for more widely re-used components.
It becomes especially unwieldy when you have a deep component hierarchy.
Resource string resolution is done in a way that the surrounding containers
and the page can override a particular component's strings. I propose that
Form gets a new boolean overridable method wantSubmitOnNestedFormSubmit
that returns false by default to keep behavior the same as in previous
versions. onFormSubmitted will then check from the nested submitted form
outwards to find the outermost form where this flag is true. This outermost
form, if any, will then be submitted.
This way, an outer form can decide it wants to join the inner form's submit
without the inner form having to be modified.

svn commit: r1214729 - /wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java

2011-12-15 Thread mgrigorov

Author: mgrigorov
Date: Thu Dec 15 12:36:19 2011
New Revision: 1214729

URL: http://svn.apache.org/viewvc?rev=1214729view=rev
Log:
WICKET-4293
UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy 
on GlassFish

Cache the input stream to be able to close it when the connection creates a new 
stream for each call of #getInputStream().


Modified:

wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java

Modified: 
wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java?rev=1214729r1=1214728r2=1214729view=diff
==
--- 
wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
 (original)
+++ 
wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
 Thu Dec 15 12:36:19 2011
@@ -23,6 +23,7 @@ import java.net.URLConnection;
 
 import org.apache.wicket.Application;
 import org.apache.wicket.util.io.Connections;
+import org.apache.wicket.util.io.IOUtils;
 import org.apache.wicket.util.lang.Args;
 import org.apache.wicket.util.lang.Bytes;
 import org.apache.wicket.util.lang.Objects;
@@ -66,6 +67,9 @@ public class UrlResourceStream extends A
{
private URLConnection connection;
 
+   /** The stream read from this connection */
+   private InputStream inputStream;
+
/** Length of stream. */
private long contentLength;
 
@@ -139,6 +143,10 @@ public class UrlResourceStream extends A
if (data != null)
{
Connections.closeQuietly(data.connection);
+   if (data.inputStream != null)
+   {
+   IOUtils.closeQuietly(data.inputStream);
+   }
streamData = null;
}
}
@@ -151,7 +159,9 @@ public class UrlResourceStream extends A
{
try
{
-   return getData(true).connection.getInputStream();
+   StreamData data = getData(true);
+   data.inputStream = data.connection.getInputStream();
+   return data.inputStream;
}
catch (IOException e)
{

svn commit: r1214733 - /wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java

2011-12-15 Thread mgrigorov

Author: mgrigorov
Date: Thu Dec 15 12:44:03 2011
New Revision: 1214733

URL: http://svn.apache.org/viewvc?rev=1214733view=rev
Log:
WICKET-4293
UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy 
on GlassFish

Cache the input stream to be able to close it when the connection creates a new 
stream for each call of #getInputStream().


Modified:

wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java

Modified: 
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java?rev=1214733r1=1214732r2=1214733view=diff
==
--- 
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
 (original)
+++ 
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
 Thu Dec 15 12:44:03 2011
@@ -23,6 +23,7 @@ import java.net.URLConnection;
 
 import org.apache.wicket.Application;
 import org.apache.wicket.util.io.Connections;
+import org.apache.wicket.util.io.IOUtils;
 import org.apache.wicket.util.lang.Args;
 import org.apache.wicket.util.lang.Bytes;
 import org.apache.wicket.util.lang.Objects;
@@ -66,6 +67,9 @@ public class UrlResourceStream extends A
{
private URLConnection connection;
 
+   /** The stream read from this connection */
+   private InputStream inputStream;
+
/** Length of stream. */
private long contentLength;
 
@@ -140,6 +144,10 @@ public class UrlResourceStream extends A
if (data != null)
{
Connections.closeQuietly(data.connection);
+   if (data.inputStream != null)
+   {
+   IOUtils.closeQuietly(data.inputStream);
+   }
streamData = null;
}
}
@@ -153,7 +161,9 @@ public class UrlResourceStream extends A
{
try
{
-   return getData(true).connection.getInputStream();
+   StreamData data = getData(true);
+   data.inputStream = data.connection.getInputStream();
+   return data.inputStream;
}
catch (IOException e)
{

[jira] [Resolved] (WICKET-4293) UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

2011-12-15 Thread Martin Grigorov (Resolved) (JIRA)

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

Martin Grigorov resolved WICKET-4293.
-

Resolution: Fixed
Fix Version/s: 6.0.0
1.5.4
Assignee: Martin Grigorov

We have test for this situation but it doesn't open a new input stream for each
call: org.apache.wicket.util.resource.UrlResourceStreamTest.loadJustOnce()

I just committed an improvement that should do what you need.
Try it and give us feedback,
Also try to break/improve the test if you can.
Thanks!

UrlResourceStream closes incorrect InputStream causing stacktraces on
undeploy on GlassFish
---

Key: WICKET-4293
URL: https://issues.apache.org/jira/browse/WICKET-4293
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.3
Environment: GlassFish v2.1.1 and GlassFish v.3.1
java version 1.6.0_29
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
Mac OS X 10.7.2
Reporter: Pepijn de Geus
Assignee: Martin Grigorov
Labels: core, ear, glassfish, resource
Fix For: 1.5.4, 6.0.0

Attachments: Wicket153-bug.zip, patch.txt

The UrlResourceStream, used by PackageResources, uses
URLConnection#getInputStream() to get file contents. This method is called in
UrlResourceStream#getInputStream(), but also when closing the resource in
UrlResourceStream#close(). At least on GlassFish v2 and v3, the second call
to URLConnection#getInputStream() returns a new stream, so the one created to
retrieve the file contents is never closed properly.
This results in a warning of the container when the classes are
garbage-collected, for example on undeploy.
The problem is not triggered in all situations. It can be reproduced by using
Wicket in a multi-module project consisting of an EAR, WAR and JAR. The JAR
must contain a resource (CSS, image, ...) and a Behavior. Inside the
Behavior, a static ResourceReference must be created for the resource file.
When using this Behavior from inside the WAR project by loading a page the
resource is loaded properly. On undeploy however, the described problem will
show up.
The problem does not exists in Wicket 1.4.x, because a reference to the
InputStream is stored. A quickstart and patch for 1.5 is available, will try
to attach it :)

[jira] [Resolved] (WICKET-4291) Problem in Chrome when adding panel with modal windows to ajax request target

2011-12-15 Thread Martin Grigorov (Resolved) (JIRA)

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

Martin Grigorov resolved WICKET-4291.
-

Resolution: Cannot Reproduce

Your app behaves the same way in Chrome 17.x and Firefox 8.
The EmptyPanel is replaced with SimplePanel without any problems. Since there
is no code that calls modalWindow.show(target) the modal itself is never shown.

I needed to recreate the quickstart because your attachment was broken
somehow...

Problem in Chrome when adding panel with modal windows to ajax request target
-

Key: WICKET-4291
URL: https://issues.apache.org/jira/browse/WICKET-4291
Project: Wicket
Issue Type: Bug
Components: wicket, wicket-extensions
Affects Versions: 1.5.3
Environment: Chromium 8.0 Ubuntu 10/10
Reporter: Martín Bigio
Attachments: sga-ajaxqs.zip

When trying to replace an empty panel with one that contains a modal window
during an AJAX request the DOM insn't modified. The wicket ajax debug windows
shows that the request is being made and the answert, but when trying to
apply the changes to the DOM the debug windows hangs after this message:
INFO: Response parsed. Now invoking steps If I press F5 to refresh, the
chages are shown indicating that the request was processed correctly and the
changes in the page hierarchy were persisted. However if I click again in the
link that fires the ajax request the wicket debug windows shows this message:
INFO: Channel busy - postponing
We couldn't reproduce this issue in firefox. I'll attach a quickstart for
reproducing the problem. When running it locally if I click in the link the
DOM isn't updated as suppossed to.

[jira] [Created] (WICKET-4296) In Firefox the auto complete dialog will not be closed when clicking besides it.

2011-12-15 Thread Johan Compagner (Created) (JIRA)

In Firefox the auto complete dialog will not be closed when clicking besides it.


 Key: WICKET-4296
 URL: https://issues.apache.org/jira/browse/WICKET-4296
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.19
Reporter: Johan Compagner
Assignee: Johan Compagner
 Fix For: 1.4.20, 1.5.5


Currently we do:

obj.onblur=function(event){ 
if(mouseactive==1){
ignoreOneFocusGain = true;
Wicket.$(elementId).focus();
return killEvent(event);
}
hideAutoComplete();
if(typeof objonblur==function) return 
objonblur.apply(this,[event]);
}


somhow we override then onblur behavior because that one is never called in FF 
to hide the auto complete
if i use the Wicket.Event add listeners:

Wicket.Event.add(obj,'blur',function(event){
if(mouseactive==1){
ignoreOneFocusGain = true;
Wicket.$(elementId).focus();
return killEvent(event);
}
hideAutoComplete();
});  

it works fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1214748 - /wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js

2011-12-15 Thread jcompagner

Author: jcompagner
Date: Thu Dec 15 13:41:57 2011
New Revision: 1214748

URL: http://svn.apache.org/viewvc?rev=1214748view=rev
Log:
In Firefox the auto complete dialog will not be closed when clicking besides it.

Wicket autocomplete when click right into the popup list without moving the 
mouse will not selelect the item under the mouse
Issue: WICKET-4297,4296

Modified:

wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js

Modified: 
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js?rev=1214748r1=1214747r2=1214748view=diff
==
--- 
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 (original)
+++ 
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 Thu Dec 15 13:41:57 2011
@@ -47,7 +47,6 @@ Wicket.AutoComplete=function(elementId, 
 
// pointers of the browser events
var objonkeydown;
-   var objonblur;
var objonkeyup;
var objonkeypress;
var objonchange;
@@ -93,7 +92,6 @@ Wicket.AutoComplete=function(elementId, 
initialElement = obj;

 objonkeydown=obj.onkeydown;
-objonblur=obj.onblur;
 objonkeyup=obj.onkeyup;
 objonkeypress=obj.onkeypress;
 objonfocus=obj.onfocus;
@@ -105,17 +103,16 @@ Wicket.AutoComplete=function(elementId, 
if(typeof objonchangeoriginal==function) return 
objonchangeoriginal.apply(this,[event]);
}
 objonchange=obj.onchange;
-
-   obj.onblur=function(event){ 
+
+Wicket.Event.add(obj,'blur',function(event){   
if(mouseactive==1){
 ignoreOneFocusGain = true;
Wicket.$(elementId).focus();
return killEvent(event);
}
-   hideAutoComplete();
-   if(typeof objonblur==function) return 
objonblur.apply(this,[event]);
-}
-   
+   window.setTimeout( hideAutoComplete, 500);
+}); 
+
obj.onfocus=function(event){
 if (mouseactive==1) {
 ignoreOneFocusGain = false;

[jira] [Created] (WICKET-4297) Wicket autocomplete when click right into the popup list without moving the mouse will not selelect the item under the mouse

2011-12-15 Thread Johan Compagner (Created) (JIRA)

Wicket autocomplete when click right into the popup list without moving the 
mouse will not selelect the item under the mouse


 Key: WICKET-4297
 URL: https://issues.apache.org/jira/browse/WICKET-4297
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.19
Reporter: Johan Compagner
Assignee: Johan Compagner
 Fix For: 1.4.20, 1.5.5


instead of just doing this:

hideAutoComplete();

we need to do:

window.setTimeout( hideAutoComplete, 500);

so that the mouse events are handled first before the window is removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1214750 - in /wicket/branches/wicket-1.5.x: wicket-core/ wicket-extensions/ wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.

2011-12-15 Thread jcompagner

Author: jcompagner
Date: Thu Dec 15 13:45:06 2011
New Revision: 1214750

URL: http://svn.apache.org/viewvc?rev=1214750view=rev
Log:
In Firefox the auto complete dialog will not be closed when clicking besides it.

Wicket autocomplete when click right into the popup list without moving the 
mouse will not selelect the item under the mouse
Issue: WICKET-4297,4296

Modified:
wicket/branches/wicket-1.5.x/wicket-core/   (props changed)
wicket/branches/wicket-1.5.x/wicket-extensions/   (props changed)

wicket/branches/wicket-1.5.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js

Propchange: wicket/branches/wicket-1.5.x/wicket-core/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Dec 15 13:45:06 2011
@@ -1,5 +1,5 @@
 
/wicket/branches/wicket-1.3.x/jdk-1.4/wicket:653208,653212,653215,653226,653231,654304,655446,655466,655786,658141,658189,659118,659120,662360,663058,671549,671885,687144-688996,698530-698577,701132-701133,701843,701850-701877,704231,708127,722099-722105,726536,728467-728490,731960,734478,739647,739951,745468-745497,749817,755171-755176,759905,760374,764756,769389,769440,774373,781715,781719,790879
-/wicket/branches/wicket-1.4.x/wicket:963681,998663,1005194-1005196,1005201,1005205,1024347,1027877
+/wicket/branches/wicket-1.4.x/wicket:963681,998663,1005194-1005196,1005201,1005205,1024347,1027877,1210482
 
/wicket/sandbox/jthomerson/experimental/wicket-devutils/wicket:760296-760351,760353-760355
 /wicket/trunk/wicket:1005201
 /wicket/trunk/wicket-core:1204836,1204865,1211037

Propchange: wicket/branches/wicket-1.5.x/wicket-extensions/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Dec 15 13:45:06 2011
@@ -1,5 +1,5 @@
 
/wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions:659248,661657,662360,677853,688992,698612,700502,701879,725634,760368,769440,772653,786424,790850
-/wicket/branches/wicket-1.4.x/wicket-extensions:963681,1206142,1206154
+/wicket/branches/wicket-1.4.x/wicket-extensions:963681,1206142,1206154,1214748
 
/wicket/sandbox/jthomerson/experimental/wicket-devutils/wicket-extensions:760296-760351,760353-760355
 /wicket/trunk/wicket-devutils/wicket-extensions:760352
 /wicket/trunk/wicket-extensions:1204836,1204865

Modified: 
wicket/branches/wicket-1.5.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.5.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js?rev=1214750r1=1214749r2=1214750view=diff
==
--- 
wicket/branches/wicket-1.5.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 (original)
+++ 
wicket/branches/wicket-1.5.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 Thu Dec 15 13:45:06 2011
@@ -47,7 +47,6 @@ Wicket.AutoComplete=function(elementId, 
 
// pointers of the browser events
var objonkeydown;
-   var objonblur;
var objonkeyup;
var objonkeypress;
var objonchange;
@@ -93,7 +92,6 @@ Wicket.AutoComplete=function(elementId, 
initialElement = obj;

 objonkeydown=obj.onkeydown;
-objonblur=obj.onblur;
 objonkeyup=obj.onkeyup;
 objonkeypress=obj.onkeypress;
 objonfocus=obj.onfocus;
@@ -105,17 +103,16 @@ Wicket.AutoComplete=function(elementId, 
if(typeof objonchangeoriginal==function) return 
objonchangeoriginal.apply(this,[event]);
}
 objonchange=obj.onchange;
-
-   obj.onblur=function(event){ 
+
+Wicket.Event.add(obj,'blur',function(event){   
if(mouseactive==1){
 ignoreOneFocusGain = true;
Wicket.$(elementId).focus();
return killEvent(event);
}
-   hideAutoComplete();
-   if(typeof objonblur==function) return 
objonblur.apply(this,[event]);
-}
-   
+   window.setTimeout( hideAutoComplete, 500);
+}); 
+
obj.onfocus=function(event){
 if (mouseactive==1) {
 ignoreOneFocusGain = false;

svn commit: r1214755 - in /wicket/trunk/wicket-extensions: ./ src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js

2011-12-15 Thread jcompagner

Author: jcompagner
Date: Thu Dec 15 13:47:20 2011
New Revision: 1214755

URL: http://svn.apache.org/viewvc?rev=1214755view=rev
Log:
In Firefox the auto complete dialog will not be closed when clicking besides it.

Wicket autocomplete when click right into the popup list without moving the 
mouse will not selelect the item under the mouse
Issue: WICKET-4297,4296

Modified:
wicket/trunk/wicket-extensions/   (props changed)

wicket/trunk/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js

Propchange: wicket/trunk/wicket-extensions/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Dec 15 13:47:20 2011
@@ -1,5 +1,5 @@
 
/wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions:659248,661657,662360,677853,688992,698612,700502,701879,725634,760368,769440,772653,786424,790850
-/wicket/branches/wicket-1.4.x/wicket-extensions:963681,1206142,1206154
-/wicket/branches/wicket-1.5.x/wicket-extensions:1204465,1206145,1206158
+/wicket/branches/wicket-1.4.x/wicket-extensions:963681,1206142,1206154,1214748
+/wicket/branches/wicket-1.5.x/wicket-extensions:1204465,1206145,1206158,1214750
 
/wicket/sandbox/jthomerson/experimental/wicket-devutils/wicket-extensions:760296-760351,760353-760355
 /wicket/trunk/wicket-devutils/wicket-extensions:760352

Modified: 
wicket/trunk/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js?rev=1214755r1=1214754r2=1214755view=diff
==
--- 
wicket/trunk/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 (original)
+++ 
wicket/trunk/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
 Thu Dec 15 13:47:20 2011
@@ -47,7 +47,6 @@ Wicket.AutoComplete=function(elementId, 
 
// pointers of the browser events
var objonkeydown;
-   var objonblur;
var objonkeyup;
var objonkeypress;
var objonchange;
@@ -93,7 +92,6 @@ Wicket.AutoComplete=function(elementId, 
initialElement = obj;

 objonkeydown=obj.onkeydown;
-objonblur=obj.onblur;
 objonkeyup=obj.onkeyup;
 objonkeypress=obj.onkeypress;
 objonfocus=obj.onfocus;
@@ -105,17 +103,16 @@ Wicket.AutoComplete=function(elementId, 
if(typeof objonchangeoriginal==function) return 
objonchangeoriginal.apply(this,[event]);
}
 objonchange=obj.onchange;
-
-   obj.onblur=function(event){ 
+
+Wicket.Event.add(obj,'blur',function(event){   
if(mouseactive==1){
 ignoreOneFocusGain = true;
Wicket.$(elementId).focus();
return killEvent(event);
}
-   hideAutoComplete();
-   if(typeof objonblur==function) return 
objonblur.apply(this,[event]);
-}
-   
+   window.setTimeout( hideAutoComplete, 500);
+}); 
+
obj.onfocus=function(event){
 if (mouseactive==1) {
 ignoreOneFocusGain = false;

[jira] [Commented] (WICKET-4296) In Firefox the auto complete dialog will not be closed when clicking besides it.

2011-12-15 Thread Martin Grigorov (Commented) (JIRA)


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

Martin Grigorov commented on WICKET-4296:
-

This change is also part of my work on Wicket-Ajax for Wicket 6.

 In Firefox the auto complete dialog will not be closed when clicking besides 
 it.
 

 Key: WICKET-4296
 URL: https://issues.apache.org/jira/browse/WICKET-4296
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.19
Reporter: Johan Compagner
Assignee: Johan Compagner
 Fix For: 1.4.20, 1.5.5


 Currently we do:
 obj.onblur=function(event){   
   if(mouseactive==1){
 ignoreOneFocusGain = true;
   Wicket.$(elementId).focus();
   return killEvent(event);
   }
   hideAutoComplete();
   if(typeof objonblur==function) return 
 objonblur.apply(this,[event]);
 }
 somhow we override then onblur behavior because that one is never called in 
 FF to hide the auto complete
 if i use the Wicket.Event add listeners:
 Wicket.Event.add(obj,'blur',function(event){  
   if(mouseactive==1){
 ignoreOneFocusGain = true;
   Wicket.$(elementId).focus();
   return killEvent(event);
   }
   hideAutoComplete();
 });
 it works fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (WICKET-4297) Wicket autocomplete when click right into the popup list without moving the mouse will not selelect the item under the mouse

2011-12-15 Thread Johan Compagner (Closed) (JIRA)


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

Johan Compagner closed WICKET-4297.
---

Resolution: Fixed

 Wicket autocomplete when click right into the popup list without moving the 
 mouse will not selelect the item under the mouse
 

 Key: WICKET-4297
 URL: https://issues.apache.org/jira/browse/WICKET-4297
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.19
Reporter: Johan Compagner
Assignee: Johan Compagner
 Fix For: 1.4.20, 1.5.5


 instead of just doing this:
   hideAutoComplete();
 we need to do:
   window.setTimeout( hideAutoComplete, 500);
 so that the mouse events are handled first before the window is removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (WICKET-4296) In Firefox the auto complete dialog will not be closed when clicking besides it.

2011-12-15 Thread Johan Compagner (Closed) (JIRA)


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

Johan Compagner closed WICKET-4296.
---

Resolution: Fixed

 In Firefox the auto complete dialog will not be closed when clicking besides 
 it.
 

 Key: WICKET-4296
 URL: https://issues.apache.org/jira/browse/WICKET-4296
 Project: Wicket
  Issue Type: Bug
  Components: wicket-extensions
Affects Versions: 1.4.19
Reporter: Johan Compagner
Assignee: Johan Compagner
 Fix For: 1.4.20, 1.5.5


 Currently we do:
 obj.onblur=function(event){   
   if(mouseactive==1){
 ignoreOneFocusGain = true;
   Wicket.$(elementId).focus();
   return killEvent(event);
   }
   hideAutoComplete();
   if(typeof objonblur==function) return 
 objonblur.apply(this,[event]);
 }
 somhow we override then onblur behavior because that one is never called in 
 FF to hide the auto complete
 if i use the Wicket.Event add listeners:
 Wicket.Event.add(obj,'blur',function(event){  
   if(mouseactive==1){
 ignoreOneFocusGain = true;
   Wicket.$(elementId).focus();
   return killEvent(event);
   }
   hideAutoComplete();
 });
 it works fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4298) FormTester doesn't handle nested forms correctly

2011-12-15 Thread Carl-Eric Menzel (Updated) (JIRA)

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

Carl-Eric Menzel updated WICKET-4298:
-

Attachment: WICKET-4298-6.0-fix-nested-form-handling-in-FormTester.patch
WICKET-4298-1.5-fix-nested-form-handling-in-FormTester.patch
WICKET-4298-1.4-fix-nested-form-handling-in-FormTester.patch

A set of patches against 1.4, 1.5 and trunk. An appropriate test is included.
The build did not break, so I assume the fix is safe.

FormTester doesn't handle nested forms correctly

Key: WICKET-4298
URL: https://issues.apache.org/jira/browse/WICKET-4298
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.19, 1.5.3, 6.0.0
Reporter: Carl-Eric Menzel
Attachments:
WICKET-4298-1.4-fix-nested-form-handling-in-FormTester.patch,
WICKET-4298-1.5-fix-nested-form-handling-in-FormTester.patch,
WICKET-4298-6.0-fix-nested-form-handling-in-FormTester.patch

While working on WICKET-4295, I discovered that FormTester doesn't handle
nested form submits correctly.
The browser will always submit the outermost form, because that is the only
form it sees. Wicket will then determine the correct form by looking at the
submitting component. If you create a FormTester on an inner form, however,
the test request will point directly at that inner form. This is a problem
for the new feature in WICKET-4295, but also in general since it does not
correctly model the actual interaction. Also the submitting component is not
found due to the wrong form being looked at. (form.getRootForm() == Form.this
in Form#findSubmittingButton()) This means that for a nested form, the
submitting component could *never* be found! I think it's mostly luck that
this is not a bigger issue in tests :-)
It is possible to have the correct handling in a test, if you do
newFormTester(outerForm) and then submit with a submit button in the inner
form (formtester.submit(inner:submitButton)).
I think FormTester should do the correct thing on its own though. The fix is
trivial: in submit() don't just use the form it's pointing at, but use
form.getRootForm(). This fixes both the correct request handling, as well as
the issue with not finding the submitting component.
I'll attach the appropriate patches.

[jira] [Issue Comment Edited] (WICKET-4014) Wicket 1.5 Form Post Action and Link Get discard Page Class Information

2011-12-15 Thread Issue Comment Edited


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

Thomas Götz edited comment on WICKET-4014 at 12/15/11 2:24 PM:
---

The only disadvantage to the solution is IMHO:
when you have a mounted page with a state (e.g. some ajax components on the 
page) and the page expires then you now have no chance of informing the user 
about the session expiry. Instead a fresh page (with a reset/fresh state) is 
created which can result in a suboptimal user experience (as already discussed 
today in IRC with martin-g and carl-eric). I'd suggest to make that behavior 
configurable, should I open a new ticket for that?

  was (Author: thomas.goetz):
The only disadvantage to the solution is IMHO:
when you have a mounted page with a state (e.g. some ajax components on the 
page) and the page expires then you now have no chance of informing the user 
about the session expiry. Instead a fresh page (with a reset/fresh) is created 
which can result in a suboptimal user experience (as already discussed today in 
IRC with martin-g and carl-eric). I'd suggest to make that behavior 
configurable, should I open a new ticket for that?
  
 Wicket 1.5 Form Post Action and Link Get discard Page Class Information
 ---

 Key: WICKET-4014
 URL: https://issues.apache.org/jira/browse/WICKET-4014
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5-RC7
 Environment: Wicket version: 1.5-RC7
 java version 1.6.0_25
 Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
 Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
 Server: GlassFish 3.1.1
Reporter: bernard
Assignee: Martin Grigorov
 Fix For: 1.5.1

 Attachments: ExpiryFallbackParametersQuickStart1.5.zip, 
 ExpiryFallbackQuickStart1.4.zip, ExpiryFallbackQuickStart1.5.zip


 Page expiry is a very annoying and perplexing event especially if users stay 
 logged in via remember-me cookie.
 It is therefore not a fancy enhancement but an essential business requirement 
 to not drop the user out of context after session expiry.
 Only stateless pages can fully achieve this, but it is not always desirable 
 to go fully stateless, especially while a recovery solution already exists.
 In 1.4, this appears to be automatic with 
 BookmarkablePageRequestTargetUrlCodingStrategy - without any additional 
 coding.
 The solution is well known - keep as much state in the client as required to 
 recover the page class, and possibly even its page parameters, and to not 
 destroy this information.
 The two attached testcases show two possible methods of page fallback 
 recovery (one with AJAX, one without) that already work behind the scenes.
 Of course it is easy with AJAX, to just force a page reload, but this is not 
 discussed here. AJAX just serves to demonstrate how easy the principle 
 actually is.
 In most cases the user could successfully reload the page but Wicket 1.5 
 can't create a response because it has forgotten the class of the expired 
 page.
 In 1.4, it is possible to recover the class of an expired page via its mount 
 path.
 This feature is lost in 1.5.
 To get this functionality back in a more streamlined fashion, I am 
 additionaly proposing in a separate jira issue 4013 to store page class and 
 page parameters in PageExpiredException.
 Meanwhile, the focus of this issue is to request whatever means to not 
 overwrite the path of a page in a form post action or get request, and to get 
 the page class back as in 1.4 by whatever means.
 The two attached testcases may be helpful for expermintation. The 1.4 tescase 
 demonstrates how the scheme works, unfortunately I could not fill the blanks 
 in the 1.5 testcase.
 In 1.4,
 a form tag is rendered as:
 form wicket:id=form 
 action=?wicket:interface=:0:form::IFormSubmitListener::
 This is requested as:
 /testForm.0?wicket:interface=:0:form::IFormSubmitListener::
 and the page class can be recovered from the mount path testForm as in
 mount(new HybridUrlCodingStrategy(testForm, TestPageForm.class));
 an anchor tag is rendered as:
 a href=?wicket:interface=:0:linkSwitch::ILinkListener::
 This is requested as:
 /testLink.0?wicket:interface=:0:linkSwitch::ILinkListener::
 and the page class can be recovered from the mount path test as in
 mount(new HybridUrlCodingStrategy(testLink, TestPageLink.class));
 In 1.5,
 a form tag is rendered as:
 form wicket:id=form action=wicket/page?0-2.IFormSubmitListener-form
 This is requested requested as:
 /wicket/page?0-1.IFormSubmitListener-form
 This overwrites the mount path testForm as in
 mountPage(testForm, TestPageForm.class);
 Consequently the server

[jira] [Commented] (WICKET-4014) Wicket 1.5 Form Post Action and Link Get discard Page Class Information

2011-12-15 Thread Commented


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

Thomas Götz commented on WICKET-4014:
-

The only disadvantage to the solution is IMHO:
when you have a mounted page with a state (e.g. some ajax components on the 
page) and the page expires then you now have no chance of informing the user 
about the session expiry. Instead a fresh page (with a reset/fresh) is created 
which can result in a suboptimal user experience (as already discussed today in 
IRC with martin-g and carl-eric). I'd suggest to make that behavior 
configurable, should I open a new ticket for that?

 Wicket 1.5 Form Post Action and Link Get discard Page Class Information
 ---

 Key: WICKET-4014
 URL: https://issues.apache.org/jira/browse/WICKET-4014
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5-RC7
 Environment: Wicket version: 1.5-RC7
 java version 1.6.0_25
 Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
 Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
 Server: GlassFish 3.1.1
Reporter: bernard
Assignee: Martin Grigorov
 Fix For: 1.5.1

 Attachments: ExpiryFallbackParametersQuickStart1.5.zip, 
 ExpiryFallbackQuickStart1.4.zip, ExpiryFallbackQuickStart1.5.zip


 Page expiry is a very annoying and perplexing event especially if users stay 
 logged in via remember-me cookie.
 It is therefore not a fancy enhancement but an essential business requirement 
 to not drop the user out of context after session expiry.
 Only stateless pages can fully achieve this, but it is not always desirable 
 to go fully stateless, especially while a recovery solution already exists.
 In 1.4, this appears to be automatic with 
 BookmarkablePageRequestTargetUrlCodingStrategy - without any additional 
 coding.
 The solution is well known - keep as much state in the client as required to 
 recover the page class, and possibly even its page parameters, and to not 
 destroy this information.
 The two attached testcases show two possible methods of page fallback 
 recovery (one with AJAX, one without) that already work behind the scenes.
 Of course it is easy with AJAX, to just force a page reload, but this is not 
 discussed here. AJAX just serves to demonstrate how easy the principle 
 actually is.
 In most cases the user could successfully reload the page but Wicket 1.5 
 can't create a response because it has forgotten the class of the expired 
 page.
 In 1.4, it is possible to recover the class of an expired page via its mount 
 path.
 This feature is lost in 1.5.
 To get this functionality back in a more streamlined fashion, I am 
 additionaly proposing in a separate jira issue 4013 to store page class and 
 page parameters in PageExpiredException.
 Meanwhile, the focus of this issue is to request whatever means to not 
 overwrite the path of a page in a form post action or get request, and to get 
 the page class back as in 1.4 by whatever means.
 The two attached testcases may be helpful for expermintation. The 1.4 tescase 
 demonstrates how the scheme works, unfortunately I could not fill the blanks 
 in the 1.5 testcase.
 In 1.4,
 a form tag is rendered as:
 form wicket:id=form 
 action=?wicket:interface=:0:form::IFormSubmitListener::
 This is requested as:
 /testForm.0?wicket:interface=:0:form::IFormSubmitListener::
 and the page class can be recovered from the mount path testForm as in
 mount(new HybridUrlCodingStrategy(testForm, TestPageForm.class));
 an anchor tag is rendered as:
 a href=?wicket:interface=:0:linkSwitch::ILinkListener::
 This is requested as:
 /testLink.0?wicket:interface=:0:linkSwitch::ILinkListener::
 and the page class can be recovered from the mount path test as in
 mount(new HybridUrlCodingStrategy(testLink, TestPageLink.class));
 In 1.5,
 a form tag is rendered as:
 form wicket:id=form action=wicket/page?0-2.IFormSubmitListener-form
 This is requested requested as:
 /wicket/page?0-1.IFormSubmitListener-form
 This overwrites the mount path testForm as in
 mountPage(testForm, TestPageForm.class);
 Consequently the server cannot discover the page class
 an anchor tag is rendered as:
 a href=wicket/page?0-1.ILinkListener-linkSwitch
 This is requested requested as:
 /wicket/page?0-1.ILinkListener-linkSwitch
 This overwrites the mount path testLink as in
 mountPage(testLink, TestPageLink.class);
 Consequently the server cannot discover the page class

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:

[jira] [Created] (WICKET-4299) Correct tests for nested form handling

2011-12-15 Thread Carl-Eric Menzel (Created) (JIRA)

Correct tests for nested form handling
--

 Key: WICKET-4299
 URL: https://issues.apache.org/jira/browse/WICKET-4299
 Project: Wicket
  Issue Type: Sub-task
Reporter: Carl-Eric Menzel
Priority: Minor


The tests introduced in WICKET-4295 use the workaround mentioned in WICKET-4298 
- they always use the outer forms and then use one of the inner submit buttons. 
If the fix in WICKET-4298 is applied, these tests can use the correct way and 
target the inner forms.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (WICKET-4278) Performance regression in Component.configure() in 1.5

2011-12-15 Thread Martin Grigorov (Resolved) (JIRA)


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

Martin Grigorov resolved WICKET-4278.
-

   Resolution: Fixed
Fix Version/s: 6.0.0
   1.5.4

 Performance regression in Component.configure() in 1.5 
 ---

 Key: WICKET-4278
 URL: https://issues.apache.org/jira/browse/WICKET-4278
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
Reporter: Martin Grigorov
Assignee: Martin Grigorov
 Fix For: 1.5.4, 6.0.0

 Attachments: WICKET-4278.patch, WICKET-4278.patch, myproject-1.4.tgz, 
 myproject-1.5.tgz


 Wicket 1.5 is slower than 1.4 in rendering deep component trees.
 See the attached application that adds recursively components with specified 
 depth. In 1.5 it is several times slower than 1.4.
 I found several problems:
 1) org.apache.wicket.Component.configure() calls 
 org.apache.wicket.Component.setRenderAllowed()
 The problems is that configure() is called for each component in the 
 hierarchy and  setRenderAllowed() is overwritten in MarkupContainer to visit 
 all children and call it for them. And the final result is that 
 setRenderAllowed() is called for the parent and all its children, then for 
 the first child and all its children again, and so on...
 The solution is to completely remove 
 org.apache.wicket.MarkupContainer.setRenderAllowed()
 2) If you increase the number of components to  1000 in 1.5 we hit 
 StackOverflowError in 
 2.1) org.apache.wicket.MarkupContainer.getMarkupType()
 2.2) org.apache.wicket.Component.getLocale()
 2.3) org.apache.wicket.MarkupContainer.internalMarkRendering(boolean)
 For 2.1 and 2.2 I suggest to add transient fields which will cache the 
 calculated value after the first call of the get method.
 For 2.3 I don't see a solution for now

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4299) Correct tests for nested form handling

2011-12-15 Thread Carl-Eric Menzel (Updated) (JIRA)


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

Carl-Eric Menzel updated WICKET-4299:
-

Attachment: 
WICKET-4299-6.0-adapt-NestedFormSubmitTest-for-fixed-FormTester-nest.patch

WICKET-4299-1.5-adapt-NestedFormSubmitTest-for-fixed-FormTester-nest.patch

WICKET-4299-1.4-adapt-NestedFormSubmitTest-for-fixed-FormTester-nest.patch

A set of patches for 1.4, 1.5 and trunk that corrects the tests. This will only 
work if both WICKET-4295 and WICKET-4298 are applied!

 Correct tests for nested form handling
 --

 Key: WICKET-4299
 URL: https://issues.apache.org/jira/browse/WICKET-4299
 Project: Wicket
  Issue Type: Sub-task
  Components: wicket
Reporter: Carl-Eric Menzel
Priority: Minor
 Attachments: 
 WICKET-4299-1.4-adapt-NestedFormSubmitTest-for-fixed-FormTester-nest.patch, 
 WICKET-4299-1.5-adapt-NestedFormSubmitTest-for-fixed-FormTester-nest.patch, 
 WICKET-4299-6.0-adapt-NestedFormSubmitTest-for-fixed-FormTester-nest.patch


 The tests introduced in WICKET-4295 use the workaround mentioned in 
 WICKET-4298 - they always use the outer forms and then use one of the inner 
 submit buttons. If the fix in WICKET-4298 is applied, these tests can use the 
 correct way and target the inner forms.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1214784 - /wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

2011-12-15 Thread mgrigorov

Author: mgrigorov
Date: Thu Dec 15 14:36:09 2011
New Revision: 1214784

URL: http://svn.apache.org/viewvc?rev=1214784view=rev
Log:
WICKET-4223
Wrong Ajax form submit with wicket-1.418 and IBM WebSphere Portal 6.1


Modified:

wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

Modified: 
wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?rev=1214784r1=1214783r2=1214784view=diff
==
--- 
wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
 (original)
+++ 
wicket/branches/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
 Thu Dec 15 14:36:09 2011
@@ -1196,7 +1196,8 @@ Wicket.Ajax.Call.prototype = {

// reconfigure the form
form.target=iframe.name;
-   form.action=this.request.url + 
wicket-ajax=truewicket-ajax-baseurl= + 
Wicket.Form.encode(Wicket._getAjaxBaseUrl());
+   var separator = (this.request.url.indexOf(?)-1 ?  : ?);
+   form.action=this.request.url + separator + 
wicket-ajax=truewicket-ajax-baseurl= + 
Wicket.Form.encode(Wicket._getAjaxBaseUrl());
form.method=post;
form.enctype=multipart/form-data;
form.encoding=multipart/form-data;

svn commit: r1214786 - /wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

2011-12-15 Thread mgrigorov

Author: mgrigorov
Date: Thu Dec 15 14:37:30 2011
New Revision: 1214786

URL: http://svn.apache.org/viewvc?rev=1214786view=rev
Log:
WICKET-4223
Wrong Ajax form submit with wicket-1.418 and IBM WebSphere Portal 6.1


Modified:

wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

Modified: 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
URL: 
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?rev=1214786r1=1214785r2=1214786view=diff
==
--- 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
 (original)
+++ 
wicket/branches/wicket-1.4.x/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
 Thu Dec 15 14:37:30 2011
@@ -1198,7 +1198,8 @@ Wicket.Ajax.Call.prototype = {

// reconfigure the form
form.target=iframe.name;
-   form.action=this.request.url + wicket:ajax=true;
+   var separator = (this.request.url.indexOf(?)-1 ?  : ?);
+   form.action=this.request.url + separator + wicket:ajax=true;
form.method=post;
form.enctype=multipart/form-data;
form.encoding=multipart/form-data;

[jira] [Resolved] (WICKET-4223) Wrong Ajax form submit with wicket-1.418 and IBM WebSphere Portal 6.1

2011-12-15 Thread Martin Grigorov (Resolved) (JIRA)


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

Martin Grigorov resolved WICKET-4223.
-

   Resolution: Fixed
Fix Version/s: 1.5.4
   1.4.20
 Assignee: Martin Grigorov

Fixed.
Thanks!

The fix for 6.0 will be included in another (bigger) commit

 Wrong Ajax form submit with wicket-1.418 and IBM WebSphere Portal 6.1
 -

 Key: WICKET-4223
 URL: https://issues.apache.org/jira/browse/WICKET-4223
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.20
 Environment: Apache Wicket 1.4.18
 IBM WebSphere Portal 6.1
Reporter: José Antonio Matute
Assignee: Martin Grigorov
  Labels: patch
 Fix For: 1.4.20, 1.5.4

 Attachments: wicket-1.4.x-wicket-ajax.js.patch


 Recently, when we were developing an application for IBM WebSphere Portal 6.1 
 (JSR286 Portlet) using Wicket 1.4.18, we had problems with forms that use 
 AjaxButton component for submitting. 
 After some investigations, we realized that the problem was on the javascript 
 side (wicket-ajax.js).  The url encoded by IBM WebSphere Portal 6.1 has the 
 following pattern:
 /wps/myportal/!ut/p/c5/_very_very_long_string_ended_with_a_slash/
 and when wicket-ajax.js do the submit, builds the following url
 /wps/myportal/!ut/p/c5/_very_very_long_string_ended_with_a_slash/wicket:ajax=true
 As you can see, this is an invalid URL: after the / must be an ? not an 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4247) HeaderResponseContainerFilteringHeaderResponse does not override enough methods

2011-12-15 Thread Martin Grigorov (Commented) (JIRA)

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

Martin Grigorov commented on WICKET-4247:
-

@Andreas: do you need this fix in 1.5 ?
These classes are reworked in 6.0 and I'd like to save myself some time if this
ticket is only for consistency and completeness and it is not really a stopper
for you.

HeaderResponseContainerFilteringHeaderResponse does not override enough
methods
---

Key: WICKET-4247
URL: https://issues.apache.org/jira/browse/WICKET-4247
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.3
Reporter: Andreas Köhler
Assignee: Martin Grigorov
Fix For: 1.5.4, 6.0.0

Attachments: wicket-4247.tar.bz2

Seen on Wicket 1.5.3 and I think it is still there in SVN.
Major because users might be trapped thinking that their Javascript is at the
bottom but it is not, having weird consequences.
Attached is a quickstart. It sets up a header response decorator with a
header response sending javascript to the bottom which is optionally wrapped
by a simple implementation of an aggregating header response. The wrapper
though uses a full-arguments method to render javascript which is not fetched
by the other response header. So the javascript ends up in the html head.
It should suffice to override the remaining four (js/css, resource ref/url)
render methods to fix this.

[jira] [Updated] (WICKET-4293) UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

2011-12-15 Thread Pepijn de Geus (Updated) (JIRA)

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

Pepijn de Geus updated WICKET-4293:
---

Attachment: wicket-core-4293-2.patch

UrlResourceStream closes incorrect InputStream causing stacktraces on
undeploy on GlassFish
---

Attachments: Wicket153-bug.zip, patch.txt, wicket-core-4293-2.patch

[jira] [Commented] (WICKET-4293) UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

2011-12-15 Thread Pepijn de Geus (Commented) (JIRA)


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

Pepijn de Geus commented on WICKET-4293:


Thanks for your reply, Martin.

Your commit fixes the problem, but has one disadvantage: the call to 
Connections.close(data.connection) still opens a new InputStream and 
immediately closes it.
The problem is thereby even broader: every call to 
Connections.close(URLConnection) has this problem. Please refer to these 
implementations of URLConnection (in OpenJDK and GlassFish) to see a new stream 
created for every call:

http://grepcode.com/file/repository.springsource.com/org.apache.geronimo/com.springsource.org.apache.geronimo.kernel/2.0.1/org/apache/geronimo/kernel/classloader/JarFileUrlConnection.java?av=h#JarFileUrlConnection
http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.common/common-util/10.0-b28/com/sun/enterprise/loader/EJBClassLoader.java?av=h#EJBClassLoader.InternalJarURLConnection

In my opinion all usages of the close(URLConnection) with connections other 
than HttpURLConnection are faulty and should be checked/changed.
I'll attach a new patch (wicket-core-4293-2.patch) fixing the problem based on 
your new commit and extending the test you mentioned.

 UrlResourceStream closes incorrect InputStream causing stacktraces on 
 undeploy on GlassFish
 ---

 Key: WICKET-4293
 URL: https://issues.apache.org/jira/browse/WICKET-4293
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
 Environment: GlassFish v2.1.1 and GlassFish v.3.1
 java version 1.6.0_29
 Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)
 Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
 Mac OS X 10.7.2
Reporter: Pepijn de Geus
Assignee: Martin Grigorov
  Labels: core, ear, glassfish, resource
 Fix For: 1.5.4, 6.0.0

 Attachments: Wicket153-bug.zip, patch.txt, wicket-core-4293-2.patch


 The UrlResourceStream, used by PackageResources, uses 
 URLConnection#getInputStream() to get file contents. This method is called in 
 UrlResourceStream#getInputStream(), but also when closing the resource in 
 UrlResourceStream#close(). At least on GlassFish v2 and v3, the second call 
 to URLConnection#getInputStream() returns a new stream, so the one created to 
 retrieve the file contents is never closed properly.
 This results in a warning of the container when the classes are 
 garbage-collected, for example on undeploy.
 The problem is not triggered in all situations. It can be reproduced by using 
 Wicket in a multi-module project consisting of an EAR, WAR and JAR. The JAR 
 must contain a resource (CSS, image, ...) and a Behavior. Inside the 
 Behavior, a static ResourceReference must be created for the resource file.
 When using this Behavior from inside the WAR project by loading a page the 
 resource is loaded properly. On undeploy however, the described problem will 
 show up.
 The problem does not exists in Wicket 1.4.x, because a reference to the 
 InputStream is stored. A quickstart and patch for 1.5 is available, will try 
 to attach it :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (WICKET-4293) UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

2011-12-15 Thread Martin Grigorov (Reopened) (JIRA)

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

Martin Grigorov reopened WICKET-4293:
-

UrlResourceStream closes incorrect InputStream causing stacktraces on
undeploy on GlassFish
---

Attachments: Wicket153-bug.zip, patch.txt, wicket-core-4293-2.patch

[jira] [Commented] (WICKET-4293) UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

2011-12-15 Thread Martin Grigorov (Commented) (JIRA)

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

Martin Grigorov commented on WICKET-4293:
-

The real problem is Connections#close() that calls getInputStream().
I don't see a reason to do that.

UrlResourceStream closes incorrect InputStream causing stacktraces on
undeploy on GlassFish
---

Attachments: Wicket153-bug.zip, patch.txt, wicket-core-4293-2.patch

[jira] [Commented] (WICKET-4293) UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

2011-12-15 Thread Pepijn de Geus (Commented) (JIRA)

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

Pepijn de Geus commented on WICKET-4293:

Exactly, but the streams that are used must of course be closed afterwards,
which is what my patch accomplishes.

UrlResourceStream closes incorrect InputStream causing stacktraces on
undeploy on GlassFish
---

Attachments: Wicket153-bug.zip, patch.txt, wicket-core-4293-2.patch

[jira] [Commented] (WICKET-4293) UrlResourceStream closes incorrect InputStream causing stacktraces on undeploy on GlassFish

2011-12-15 Thread Martin Grigorov (Commented) (JIRA)

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

Martin Grigorov commented on WICKET-4293:
-

Your test improvement is not correct. Or at least doesn't follow the rule that
calling getInputStream() should increase the streamCounter.
I'll commit the improved version soon.

UrlResourceStream closes incorrect InputStream causing stacktraces on
undeploy on GlassFish
---

Attachments: Wicket153-bug.zip, patch.txt, wicket-core-4293-2.patch

[CONF] Apache Wicket Migration to Wicket 6.0

2011-12-15 Thread confluence








Migration to Wicket 6.0
Page edited by Emond Papegaaij


 Changes (1)
 




...
For more information read [Wicket Ajax|https://cwiki.apache.org/confluence/x/NK2oAQ]  
h3. IHeaderResponse, including decorators and filters  IHeaderResponse has been rewritten to render HeaderItems. All render* methods have been replaced by a single render(HeaderItem) method. HeaderItems can be instantiated using the factory methods in _javascript_HeaderItem, CssHeaderItem, OnDomReadyHeaderItem, OnLoadHeaderItem, OnEventHeaderItem and StringHeaderItem. For example, the following code in renderHead: {code}   response.renderCSSReference(new CssResourceReference(HomePage.class, header.css));   response.renderJavaScriptReference(new _javascript_ResourceReference(HomePage.class, page.js)); {code} Needs to be replaced with: {code}   response.render(CssHeaderItem.forReference(new CssResourceReference(HomePage.class, header.css)));   response.render(_javascript_HeaderItem.forReference(new _javascript_ResourceReference(HomePage.class, page.js))); {code}  
h3. package.properties renamed to wicket-package.properties  
...


Full Content

Migrating to Wicket 6.0

Environment


	Wicket 6.0 requires at least Java 6




Repeaters

	`IDataProvider` was converted to using `long` instead of `int` to better line up with JPA and other persistence frameworks. This has caused a rather large cascade of `int` to `long` changes all over the repeater packages (WICKET-1175).



Form Processing

Validation


	`DateValidator` no longer has static factory methods, use `new DateValidator(min,max)` instead
	`StringValidator` no longer has static factory methods, use `new StringValidator(min, max)` instead
	`StringValidator` will add the `maxlen` attribute if added to a component attached to an input tag
	`AbstractValidator` has been removed
	`ValidationError` now makes creating standard error keys (classname and classname.subtype) easier
	Most validators provide a `decorate(ValidationError, Validatable)` method for overriding how they report errors



Ajax

Use JQuery as a backing library for Wicket Ajax functionality

Apache Wicket needed to improve the implementation of its _javascript_ libraries used for Ajax functionality (wicket-ajax.js and wicket-event.js) by using any of the bigger _javascript_ libraries and delegate to it the handling of the differences in the browsers (DOM, events, Ajax, ...). After a discussion in the mailing lists the Wicket team decided to use JQuery for that.
For more information read Wicket Ajax

IHeaderResponse, including decorators and filters

IHeaderResponse has been rewritten to render HeaderItems. All render* methods have been replaced by a single render(HeaderItem) method. HeaderItems can be instantiated using the factory methods in _javascript_HeaderItem, CssHeaderItem, OnDomReadyHeaderItem, OnLoadHeaderItem, OnEventHeaderItem and StringHeaderItem. For example, the following code in renderHead:


  response.renderCSSReference(new CssResourceReference(HomePage.class, "header.css"));
  response.renderJavaScriptReference(new _javascript_ResourceReference(HomePage.class, "page.js"));


Needs to be replaced with:


  response.render(CssHeaderItem.forReference(new CssResourceReference(HomePage.class, "header.css")));
  response.render(_javascript_HeaderItem.forReference(new _javascript_ResourceReference(HomePage.class, "page.js")));



package.properties renamed to wicket-package.properties

The special resource bundle that can contain resources for a whole package has been renamed from package.properties to wicket-package.properties. This prefix will be used for all wicket resources which may collide somehow with resources provided by other frameworks. See WICKET-4211 

List of renamed classes and methods

Following the renames in subclasses is easier if the @Override annotations are present. IDE-s, like Eclipse, can be used to add missing @Override annotations before moving to wicket 6.

Here's a table of deprecated classes andmethods in Wicket 1.5 and the corresponding replacement in Wicket 6.




 Wicket 1.5 (deprecated) 
 Wicket 6 (replacement) 


 org.apache.wicket.behavior.SimpleAttributeModifier 
 org.apache.wicket.AttributeModifier#replace(...) 


 org.apache.wicket.request.Url#toAbsoluteString() 
 org.apache.wicket.request.Url#toString(StringMode.FULL) 





Refactorings

	HttpsMapper has been refactored to make subclassing easier





Change Notification Preferences

View Online
|
View Changes
|
Add Comment

[jira] [Created] (WICKET-4300) JavaScript error Uncaught TypeError: Cannot read property 'length' of undefined in case of CheckGroupSelector and nested forms

2011-12-15 Thread Alexander Morozov (Created) (JIRA)

JavaScript error Uncaught TypeError: Cannot read property 'length' of 
undefined in case of CheckGroupSelector and nested forms


 Key: WICKET-4300
 URL: https://issues.apache.org/jira/browse/WICKET-4300
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
 Environment: JDK 1.6u27, Win64, Google Chrome 15.0.x
Reporter: Alexander Morozov


Full stack trace is:

Uncaught TypeError: Cannot read property 'length' of undefined:
(anonymous function)CheckGroupSelector-ver-1323970753862.js:35
Wicket.CheckboxSelector.updateAllCheckboxesAbstractCheckSelector-ver-1323970753862.js:35
(anonymous function)

Caused by CheckGroupSelector.java:

@Override
protected CharSequence getFindCheckboxesFunction()
{
CheckGroup? group = getGroup();
if (group == null)
{
throw new WicketRuntimeException(
CheckGroupSelector component [ +
getPath() +
] cannot find its parent CheckGroup. 
All CheckGroupSelector components must be a child of or below in the hierarchy 
of a CheckGroup component.);
}
return Wicket.CheckboxSelector.Group.findCheckboxesFunction(' 
+
group.getForm().getMarkupId() + ',' + 
group.getInputName() + ');
}

The generated JS will address HTML form which is attached to check group, but 
this element may be not a root form (which is rendered as 'div' instead of 
'form' element). JS code CheckGroupSelector:js:34 parentForm[groupName] can 
be evaluated to 'undefined'. I think, that group.getForm().getMarkupId() 
should be replaced by group.getForm().getRootForm().getMarkupId().






--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4300) JavaScript error Uncaught TypeError: Cannot read property 'length' of undefined in case of CheckGroupSelector and nested forms

2011-12-15 Thread Alexander Morozov (Updated) (JIRA)


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

Alexander Morozov updated WICKET-4300:
--

Attachment: myproject.zip

quickstart project

 JavaScript error Uncaught TypeError: Cannot read property 'length' of 
 undefined in case of CheckGroupSelector and nested forms
 

 Key: WICKET-4300
 URL: https://issues.apache.org/jira/browse/WICKET-4300
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
 Environment: JDK 1.6u27, Win64, Google Chrome 15.0.x
Reporter: Alexander Morozov
 Attachments: myproject.zip


 Full stack trace is:
 Uncaught TypeError: Cannot read property 'length' of undefined:
 (anonymous function)CheckGroupSelector-ver-1323970753862.js:35
 Wicket.CheckboxSelector.updateAllCheckboxesAbstractCheckSelector-ver-1323970753862.js:35
 (anonymous function)
 Caused by CheckGroupSelector.java:
   @Override
   protected CharSequence getFindCheckboxesFunction()
   {
   CheckGroup? group = getGroup();
   if (group == null)
   {
   throw new WicketRuntimeException(
   CheckGroupSelector component [ +
   getPath() +
   ] cannot find its parent CheckGroup. 
 All CheckGroupSelector components must be a child of or below in the 
 hierarchy of a CheckGroup component.);
   }
   return Wicket.CheckboxSelector.Group.findCheckboxesFunction(' 
 +
   group.getForm().getMarkupId() + ',' + 
 group.getInputName() + ');
   }
 The generated JS will address HTML form which is attached to check group, but 
 this element may be not a root form (which is rendered as 'div' instead of 
 'form' element). JS code CheckGroupSelector:js:34 parentForm[groupName] can 
 be evaluated to 'undefined'. I think, that group.getForm().getMarkupId() 
 should be replaced by group.getForm().getRootForm().getMarkupId().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4300) JavaScript error Uncaught TypeError: Cannot read property 'length' of undefined in case of CheckGroupSelector and nested forms

2011-12-15 Thread Alexander Morozov (Updated) (JIRA)


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

Alexander Morozov updated WICKET-4300:
--

Attachment: wicket-4300-fix.patch

patch

 JavaScript error Uncaught TypeError: Cannot read property 'length' of 
 undefined in case of CheckGroupSelector and nested forms
 

 Key: WICKET-4300
 URL: https://issues.apache.org/jira/browse/WICKET-4300
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
 Environment: JDK 1.6u27, Win64, Google Chrome 15.0.x
Reporter: Alexander Morozov
 Attachments: myproject.zip, wicket-4300-fix.patch


 Full stack trace is:
 Uncaught TypeError: Cannot read property 'length' of undefined:
 (anonymous function)CheckGroupSelector-ver-1323970753862.js:35
 Wicket.CheckboxSelector.updateAllCheckboxesAbstractCheckSelector-ver-1323970753862.js:35
 (anonymous function)
 Caused by CheckGroupSelector.java:
   @Override
   protected CharSequence getFindCheckboxesFunction()
   {
   CheckGroup? group = getGroup();
   if (group == null)
   {
   throw new WicketRuntimeException(
   CheckGroupSelector component [ +
   getPath() +
   ] cannot find its parent CheckGroup. 
 All CheckGroupSelector components must be a child of or below in the 
 hierarchy of a CheckGroup component.);
   }
   return Wicket.CheckboxSelector.Group.findCheckboxesFunction(' 
 +
   group.getForm().getMarkupId() + ',' + 
 group.getInputName() + ');
   }
 The generated JS will address HTML form which is attached to check group, but 
 this element may be not a root form (which is rendered as 'div' instead of 
 'form' element). JS code CheckGroupSelector:js:34 parentForm[groupName] can 
 be evaluated to 'undefined'. I think, that group.getForm().getMarkupId() 
 should be replaced by group.getForm().getRootForm().getMarkupId().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4301) ByteArrayResource throws error if data is null

2011-12-15 Thread Bertrand Guay-Paquet (Commented) (JIRA)


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

Bertrand Guay-Paquet commented on WICKET-4301:
--

Please validate the patch. It works in my tests, but I'm not 100% sure if it's 
right. In particular, should the following 2 statements be executed if 
data==null?

response.setContentLength(0);

configureResponse(response, attributes); // --- DynamicImageResource calls 
this even if data is null

 ByteArrayResource throws error if data is null
 --

 Key: WICKET-4301
 URL: https://issues.apache.org/jira/browse/WICKET-4301
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
Reporter: Bertrand Guay-Paquet
Priority: Minor
  Labels: resource
 Attachments: ByteArrayResource.patch


 When 
 ByteArrayResource#getData(org.apache.wicket.request.resource.IResource.Attributes)
  returns null, the class throws a WicketRuntimeException.
 This behavior differs from DynamicImageResource and ResourceStreamResource 
 which instead issue the following call:
 response.setError(HttpServletResponse.SC_NOT_FOUND);
 ByteArrayResource should follow the same behavior. This would allow for 
 instance to use it for resources which depend on the contents of 
 attributes.getParameters(). When the parameters are invalid, a 404 should be 
 issued instead of an exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (WICKET-4301) ByteArrayResource throws error if data is null

2011-12-15 Thread Bertrand Guay-Paquet (Created) (JIRA)

ByteArrayResource throws error if data is null
--

 Key: WICKET-4301
 URL: https://issues.apache.org/jira/browse/WICKET-4301
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
Reporter: Bertrand Guay-Paquet
Priority: Minor
 Attachments: ByteArrayResource.patch

When 
ByteArrayResource#getData(org.apache.wicket.request.resource.IResource.Attributes)
 returns null, the class throws a WicketRuntimeException.

This behavior differs from DynamicImageResource and ResourceStreamResource 
which instead issue the following call:
response.setError(HttpServletResponse.SC_NOT_FOUND);

ByteArrayResource should follow the same behavior. This would allow for 
instance to use it for resources which depend on the contents of 
attributes.getParameters(). When the parameters are invalid, a 404 should be 
issued instead of an exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (WICKET-4301) ByteArrayResource throws error if data is null

2011-12-15 Thread Bertrand Guay-Paquet (Updated) (JIRA)


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

Bertrand Guay-Paquet updated WICKET-4301:
-

Attachment: ByteArrayResource.patch

proposed fix

 ByteArrayResource throws error if data is null
 --

 Key: WICKET-4301
 URL: https://issues.apache.org/jira/browse/WICKET-4301
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.5.3
Reporter: Bertrand Guay-Paquet
Priority: Minor
  Labels: resource
 Attachments: ByteArrayResource.patch


 When 
 ByteArrayResource#getData(org.apache.wicket.request.resource.IResource.Attributes)
  returns null, the class throws a WicketRuntimeException.
 This behavior differs from DynamicImageResource and ResourceStreamResource 
 which instead issue the following call:
 response.setError(HttpServletResponse.SC_NOT_FOUND);
 ByteArrayResource should follow the same behavior. This would allow for 
 instance to use it for resources which depend on the contents of 
 attributes.getParameters(). When the parameters are invalid, a 404 should be 
 issued instead of an exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4091) Automate output of markup ids

2011-12-15 Thread Emond Papegaaij (Commented) (JIRA)

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

Emond Papegaaij commented on WICKET-4091:
-

With the patch for WICKET-4273 applied, I think this issue can be closed. The
patch for that issue also included the patch attached here. After porting our
application and WiQuery to Wicket 6, this small change made most
setOutputMarkupId calls unnecessary.

Automate output of markup ids
-

Key: WICKET-4091
URL: https://issues.apache.org/jira/browse/WICKET-4091
Project: Wicket
Issue Type: Improvement
Components: wicket
Reporter: Igor Vaynberg
Labels: ajax, markupid
Fix For: 6.0.0

Attachments: WICKET-4091.patch

this is a proposal to remove the rather annoying requirement of having to
call setoutputmarkupid(true) on components.
when a user calls getmarkupid() they are showing intent of using that id, so
if that method is called we should automatically call
setoutputmarkupid(true). further we should process renderhead() of components
first - before rendering the components. most calls to getmarkupid() come
from that method so processing it before rendering the component will toggle
the correct bit.

[jira] [Commented] (WICKET-4247) HeaderResponseContainerFilteringHeaderResponse does not override enough methods

2011-12-15 Thread Emond Papegaaij (Commented) (JIRA)

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

Emond Papegaaij commented on WICKET-4247:
-

Perhaps for 1.5, it's as easy as adding the last few methods? New methods will
not get added in 1.5, as that's an API break.

HeaderResponseContainerFilteringHeaderResponse does not override enough
methods
---

Attachments: wicket-4247.tar.bz2

43 matches

Mail list logo