svn commit: r1053019 - /wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.java

2010-12-27 Thread mgrigorov
Author: mgrigorov
Date: Mon Dec 27 08:38:28 2010
New Revision: 1053019

URL: http://svn.apache.org/viewvc?rev=1053019&view=rev
Log:
Use LinkedHashMap so it prints the calendar settings in the same order they 
were put

Modified:

wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.java

Modified: 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.java?rev=1053019&r1=1053018&r2=1053019&view=diff
==
--- 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.java
 (original)
+++ 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.java
 Mon Dec 27 08:38:28 2010
@@ -24,6 +24,7 @@ import java.util.Calendar;
 import java.util.Date;
 import java.util.HashMap;
 import java.util.Iterator;
+import java.util.LinkedHashMap;
 import java.util.List;
 import java.util.Locale;
 import java.util.Map;
@@ -256,7 +257,7 @@ public class DatePicker extends Behavior
Strings.replaceAll(script, "${calendar}", 
"YAHOO.wicket." + widgetId + "DpJs"));
}
// print out the initialization properties
-   Map p = new HashMap();
+   Map p = new LinkedHashMap();
configure(p);
if (!p.containsKey("navigator") && enableMonthYearSelection())
{




svn commit: r1053020 - in /wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar: DatesPage1.java DatesPage1_ExpectedResult.html

2010-12-27 Thread mgrigorov
Author: mgrigorov
Date: Mon Dec 27 08:38:58 2010
New Revision: 1053020

URL: http://svn.apache.org/viewvc?rev=1053020&view=rev
Log:
Use a shorter list of locales for the test.
Locale.getAvailableLocales() returns different results on JDK 1.5 vs. 1.6
These locales exist for both 1.5 and 1.6

Re-generate the expected .html so that it has the new order of calendar 
settings and the expected locales

With this change the test passes here with jdk 1.5 and 1.6

Modified:

wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1.java

wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1_ExpectedResult.html

Modified: 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1.java?rev=1053020&r1=1053019&r2=1053020&view=diff
==
--- 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1.java
 (original)
+++ 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1.java
 Mon Dec 27 08:38:58 2010
@@ -84,7 +84,7 @@ public class DatesPage1 extends WebPage
{
super(id);
// sort locales on strings of selected locale
-   setChoices(new AbstractReadOnlyModel>()
+   setChoices(new AbstractReadOnlyModel>()
{
private static final long serialVersionUID = 1L;
 
@@ -98,7 +98,7 @@ public class DatesPage1 extends WebPage
public int compare(Locale o1, 
Locale o2)
{
return 
o1.getDisplayName(selectedLocale).compareTo(
-   
o2.getDisplayName(selectedLocale));
+   
o2.getDisplayName(selectedLocale));
}
});
return locales;
@@ -131,7 +131,11 @@ public class DatesPage1 extends WebPage
private static final List LOCALES;
static
{
-   LOCALES = Arrays.asList(Locale.getAvailableLocales());
+   LOCALES = Arrays.asList(Locale.CANADA, Locale.CANADA_FRENCH, 
Locale.CHINA, Locale.ENGLISH,
+   Locale.FRANCE, Locale.FRENCH, Locale.GERMAN, 
Locale.GERMANY, Locale.ITALIAN,
+   Locale.ITALY, Locale.JAPAN, Locale.JAPANESE, 
Locale.KOREA, Locale.KOREAN, Locale.PRC,
+   Locale.SIMPLIFIED_CHINESE, Locale.TAIWAN, 
Locale.TRADITIONAL_CHINESE, Locale.UK,
+   Locale.US);
}
 
private final Date date = new Date();
@@ -144,7 +148,7 @@ public class DatesPage1 extends WebPage
public DatesPage1()
{
selectedLocale = Session.get().getLocale();
-   Form< ? > localeForm = new Form("localeForm");
+   Form localeForm = new Form("localeForm");
localeForm.add(new LocaleDropDownChoice("localeSelect"));
localeForm.add(new Link("localeUSLink")
{
@@ -158,7 +162,7 @@ public class DatesPage1 extends WebPage
});
add(localeForm);
DateTextField dateTextField = new 
DateTextField("dateTextField", new PropertyModel(
-   this, "date"), new StyleDateConverter("S-", 
true))
+   this, "date"), new StyleDateConverter("S-", true))
{
private static final long serialVersionUID = 1L;
 
@@ -168,7 +172,7 @@ public class DatesPage1 extends WebPage
return selectedLocale;
}
};
-   Form< ? > form = new Form("form")
+   Form form = new Form("form")
{
private static final long serialVersionUID = 1L;
 

Modified: 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1_ExpectedResult.html
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1_ExpectedResult.html?rev=1053020&r1=1053019&r2=1053020&view=diff
==
--- 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1_ExpectedResult.html
 (original)
+++ 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPag

[jira] Created: (WICKET-3284) Feedback messages are not displayed permanently when using REDIRECT_TO_BUFFER

2010-12-27 Thread Chris Wewerka (JIRA)
Feedback messages are not displayed permanently when using REDIRECT_TO_BUFFER
-

 Key: WICKET-3284
 URL: https://issues.apache.org/jira/browse/WICKET-3284
 Project: Wicket
  Issue Type: Bug
  Components: wicket
Affects Versions: 1.4.14
Reporter: Chris Wewerka


In our app someone used ONE_PASS_RENDER to bypass/workaround problems with the 
redirect-after-post pattern in a Apache/Tomcat scenario where the app was not 
mounted under root path in tomcat, but was mounted under root path in the 
apache. I figured out the problems with missing rewrite rules.

Then I switched back to the default: REDIRECT_TO_BUFFER

But now I have s.th. that I think is a bug: If I post a form, I get a response 
with a redirect and all errors/feedback messages are displayed correctly. But 
if I reload the page again a GET to the very same page is done, but the 
feedback messages are gone. Shouldn't the messages also be stored in the buffer 
and should be correctly displayed if the page with its state is redisplayed?

I've also found out that this isn't only a behaviour in our app, but can also 
be found e.g. here in the CDAPP Example: 
http://www.wicket-library.com/wicket-contrib-examples/cdapp

Just select one CD, delete title for example, press save and you're presented 
some error feedback. But when you hit "reload", the messages are gone.  IMHO 
the state of the page including the feedback messages should be presented to 
the user.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1053027 - /wicket/trunk/pom.xml

2010-12-27 Thread jdonnerstag
Author: jdonnerstag
Date: Mon Dec 27 09:09:16 2010
New Revision: 1053027

URL: http://svn.apache.org/viewvc?rev=1053027&view=rev
Log:
wicket-core related change to make maven work

Modified:
wicket/trunk/pom.xml

Modified: wicket/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/wicket/trunk/pom.xml?rev=1053027&r1=1053026&r2=1053027&view=diff
==
--- wicket/trunk/pom.xml (original)
+++ wicket/trunk/pom.xml Mon Dec 27 09:09:16 2010
@@ -48,7 +48,7 @@
the parent. 
-->

-   wicket
+   wicket-core
 wicket-util
wicket-datetime
 wicket-request
@@ -63,7 +63,6 @@
wicket-objectssizeof-agent
wicket-examples
archetypes/quickstart
-   wicket-core



@@ -124,7 +123,7 @@
false


-   wicket
+   wicket-core
 wicket-util
wicket-datetime
 wicket-request
@@ -139,7 +138,6 @@
wicket-objectssizeof-agent
wicket-examples
archetypes/quickstart
-   wicket-core



@@ -183,7 +181,7 @@
true


-   wicket
+   wicket-core
 wicket-util
wicket-datetime
 wicket-request
@@ -199,7 +197,6 @@
wicket-examples
archetypes/quickstart
testing/wicket-threadtest
-   wicket-core

 





svn commit: r1053028 - /wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java

2010-12-27 Thread jdonnerstag
Author: jdonnerstag
Date: Mon Dec 27 09:24:22 2010
New Revision: 1053028

URL: http://svn.apache.org/viewvc?rev=1053028&view=rev
Log:
replace toString with compareTo

Modified:

wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java

Modified: 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java?rev=1053028&r1=1053027&r2=1053028&view=diff
==
--- 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java
 (original)
+++ 
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java
 Mon Dec 27 09:24:22 2010
@@ -79,9 +79,11 @@ public class DatePickerTest extends Wick
formTester.submit();
DatesPage2 page = (DatesPage2)tester.getLastRenderedPage();
 
+   log.error("orig: " + date.getTime() + "; date: " + 
page.date.getTime() + "; dateTime: " +
+   page.dateTime.getTime());
log.error("orig: " + date + "; date: " + page.date + "; 
dateTime: " + page.dateTime);
-   assertEquals(date.toString(), page.dateTime.toString());
-   assertEquals(date.toString(), page.date.toString());
+   assertEquals(0, date.compareTo(page.dateTime));
+   assertEquals(0, date.compareTo(page.date));
}
 
/**




svn commit: r1053036 - /wicket/trunk/pom.xml

2010-12-27 Thread jdonnerstag
Author: jdonnerstag
Date: Mon Dec 27 09:57:18 2010
New Revision: 1053036

URL: http://svn.apache.org/viewvc?rev=1053036&view=rev
Log:
revert last change

Modified:
wicket/trunk/pom.xml

Modified: wicket/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/wicket/trunk/pom.xml?rev=1053036&r1=1053035&r2=1053036&view=diff
==
--- wicket/trunk/pom.xml (original)
+++ wicket/trunk/pom.xml Mon Dec 27 09:57:18 2010
@@ -48,6 +48,7 @@
the parent. 
-->

+   wicket
wicket-core
 wicket-util
wicket-datetime
@@ -123,6 +124,7 @@
false


+   wicket
wicket-core
 wicket-util
wicket-datetime
@@ -181,6 +183,7 @@
true


+   wicket
wicket-core
 wicket-util
wicket-datetime




svn commit: r1053037 - /wicket/trunk/wicket-auth-roles/src/main/java/org/apache/wicket/authentication/panel/SignInPanel.java

2010-12-27 Thread jdonnerstag
Author: jdonnerstag
Date: Mon Dec 27 10:08:21 2010
New Revision: 1053037

URL: http://svn.apache.org/viewvc?rev=1053037&view=rev
Log:
make form more easily available to subclasses

Modified:

wicket/trunk/wicket-auth-roles/src/main/java/org/apache/wicket/authentication/panel/SignInPanel.java

Modified: 
wicket/trunk/wicket-auth-roles/src/main/java/org/apache/wicket/authentication/panel/SignInPanel.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-auth-roles/src/main/java/org/apache/wicket/authentication/panel/SignInPanel.java?rev=1053037&r1=1053036&r2=1053037&view=diff
==
--- 
wicket/trunk/wicket-auth-roles/src/main/java/org/apache/wicket/authentication/panel/SignInPanel.java
 (original)
+++ 
wicket/trunk/wicket-auth-roles/src/main/java/org/apache/wicket/authentication/panel/SignInPanel.java
 Mon Dec 27 10:08:21 2010
@@ -55,6 +55,8 @@ public class SignInPanel extends Panel
/** Log. */
private static final Logger log = 
LoggerFactory.getLogger(SignInPanel.class);
 
+   private static final String SIGN_IN_FORM = "signInForm";
+
/** True if the panel should display a remember-me checkbox */
private boolean includeRememberMe = true;
 
@@ -93,7 +95,16 @@ public class SignInPanel extends Panel
 
// Add sign-in form to page, passing feedback panel as
// validation error handler
-   add(new SignInForm("signInForm"));
+   add(new SignInForm(SIGN_IN_FORM));
+   }
+
+   /**
+* 
+* @return signin form
+*/
+   protected SignInForm getForm()
+   {
+   return (SignInForm)get(SIGN_IN_FORM);
}
 
/**




[jira] Created: (WICKET-3285) Method to invalidate Session after stateful Operations eg Panel Replacement

2010-12-27 Thread bernard (JIRA)
Method to invalidate Session after stateful Operations eg Panel Replacement
---

 Key: WICKET-3285
 URL: https://issues.apache.org/jira/browse/WICKET-3285
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.4.13
 Environment: All
Reporter: bernard


We need to invalidate the web session after a panel of the current page is 
replaced.

The use case is user registration where after completion, it must be avoided 
that the session on the same client computer can accidentally be used by 
someone else.


All my attempts are failing because webSession.invalidate() or even 
webSession.replaceSession(); have an influence on the current request/response.

Typically, one would just show a new page, e.g.

Session.invalidate();
setResponsePage(...);

but I don't have this option because I am using panel replacement that depends 
on the session.


I have tried the folowing but it doesn't seem to work:

replacedPanel.getPage().add(new AbstractBehavior(){
private boolean lastTime = false;
@Override
public void detach(Component component) {
super.detach(component);
WebRequestCycle requestCycle = (WebRequestCycle) RequestCycle.get();
WebRequest webRequest = (WebRequest) requestCycle.getRequest();
HttpServletRequest httpServletRequest = 
webRequest.getHttpServletRequest();
httpServletRequest.getSession().setMaxInactiveInterval(10);
}
});
replacedPanel.replaceWith(newPanel);

Is it possible that the Wicket framework provides a safe method to invalidate 
the session
after all work is completed, including redirect after post, preferably without 
having to use JavaScript/AJAX hacks?

It would make sense to me that a framework that depends on sessions so heavily, 
provides developers with a method to
avoid errors in this use case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1053047 - in /wicket/common/site/trunk: _site/start/quickstart.html start/quickstart.md

2010-12-27 Thread mgrigorov
Author: mgrigorov
Date: Mon Dec 27 11:42:02 2010
New Revision: 1053047

URL: http://svn.apache.org/viewvc?rev=1053047&view=rev
Log:
WICKET-3268 Can't generate 1.5-SNAPSHOT project with the quickstart command

Use -DarchetypeRepository instead of -DremoteRepositories to point where the 
-SNAPSHOT archetype is.


Modified:
wicket/common/site/trunk/_site/start/quickstart.html
wicket/common/site/trunk/start/quickstart.md

Modified: wicket/common/site/trunk/_site/start/quickstart.html
URL: 
http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/start/quickstart.html?rev=1053047&r1=1053046&r2=1053047&view=diff
==
--- wicket/common/site/trunk/_site/start/quickstart.html (original)
+++ wicket/common/site/trunk/_site/start/quickstart.html Mon Dec 27 11:42:02 
2010
@@ -177,7 +177,8 @@
else
cmd = 'mvn archetype:generate 
-DarchetypeGroupId=org.apache.wicket 
-DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=' + 
version + ' -DgroupId=' + groupId + ' -DartifactId=' + artifactId;  

 
-   if (version.match(/.*SNAPSHOT/)) cmd += ' 
-DremoteRepositories=http://wicketstuff.org/maven/repository/';
+   if (version.match(/.*SNAPSHOT/)) cmd += ' 
-DarchetypeRepository=http://wicketstuff.org/maven/repository/'; 
+   cmd += ' -DinteractiveMode=false'; 
document.getElementById("cmdLine").value = cmd;
}
 

Modified: wicket/common/site/trunk/start/quickstart.md
URL: 
http://svn.apache.org/viewvc/wicket/common/site/trunk/start/quickstart.md?rev=1053047&r1=1053046&r2=1053047&view=diff
==
--- wicket/common/site/trunk/start/quickstart.md (original)
+++ wicket/common/site/trunk/start/quickstart.md Mon Dec 27 11:42:02 2010
@@ -42,7 +42,8 @@ typing in the groupId, artifactId and ve
else
cmd = 'mvn archetype:generate 
-DarchetypeGroupId=org.apache.wicket 
-DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=' + 
version + ' -DgroupId=' + groupId + ' -DartifactId=' + artifactId;  

 
-   if (version.match(/.*SNAPSHOT/)) cmd += ' 
-DremoteRepositories=http://wicketstuff.org/maven/repository/';
+   if (version.match(/.*SNAPSHOT/)) cmd += ' 
-DarchetypeRepository=http://wicketstuff.org/maven/repository/'; 
+   cmd += ' -DinteractiveMode=false'; 
document.getElementById("cmdLine").value = cmd;
}
 




[jira] Resolved: (WICKET-3268) Can't generate 1.5-SNAPSHOT project with the quickstart command

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov resolved WICKET-3268.
-

Resolution: Fixed
  Assignee: Martin Grigorov

Fixed with r1053047.

> Can't generate 1.5-SNAPSHOT project with the quickstart command
> ---
>
> Key: WICKET-3268
> URL: https://issues.apache.org/jira/browse/WICKET-3268
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-quickstart
>Reporter: Major Peter
>Assignee: Martin Grigorov
> Fix For: 1.5-M4
>
>
> Currently the command on Wicket site 
> (http://wicket.apache.org/start/quickstart.html) is not working with 
> 1.5-SNAPSHOT, because the archetype plugin does not care about the 
> remoteRepositories parameter 
> (http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html).
>  Instead it will always generate 1.5-M3 quickstart. (at least this is the 
> behavior with Maven 3.0.1)
> The solution is to use the following command:
> mvn archetype:generate -DarchetypeGroupId=org.apache.wicket 
> -DarchetypeArtifactId=wicket-archetype-quickstart 
> -DarchetypeVersion=1.5-SNAPSHOT -DgroupId=com.mycompany 
> -DartifactId=myproject -DinteractiveMode=false 
> -DarchetypeRepository=http://wicketstuff.org/maven/repository/
> note the extra -DinteractiveMode=false parameter, which can speed up the 
> projectgeneration. ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (WICKET-3135) Improve JavaScriptPackageResource#toString() to show filename instead of default Object#toString()

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov reassigned WICKET-3135:
---

Assignee: (was: Martin Grigorov)

> Improve JavaScriptPackageResource#toString() to show filename instead of 
> default Object#toString()
> --
>
> Key: WICKET-3135
> URL: https://issues.apache.org/jira/browse/WICKET-3135
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.13
>Reporter: Martijn Dashorst
> Attachments: fix-WICKET-3135.patch, test-WICKET-3135.patch
>
>
> For seeing the difference between normal page requests (and ajax requests) 
> and resource request, the requestlogger needs to output the actual filename 
> of the resource. This allows for a top 10 most requested resources...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (WICKET-1721) FormTester doesnt support onSelectionChanged for RadioChoice

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov reassigned WICKET-1721:
---

Assignee: Martin Grigorov

> FormTester doesnt support onSelectionChanged  for RadioChoice
> -
>
> Key: WICKET-1721
> URL: https://issues.apache.org/jira/browse/WICKET-1721
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
> Environment: Doesn't matter
>Reporter: Murat Yücel
>Assignee: Martin Grigorov
> Fix For: 1.5-M4
>
>
> It is not possible to test onSelectionChanged for RadioChoice and probably 
> also other form components.
> See this thread:
> http://www.nabble.com/Problem-test-RadioChoice-td18196023.html#a18196023

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (WICKET-1732) FormTester's DropDownChoice onSelectionChanged() behaviour doesn't reload page

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov reassigned WICKET-1732:
---

Assignee: Martin Grigorov

> FormTester's DropDownChoice onSelectionChanged() behaviour doesn't reload page
> --
>
> Key: WICKET-1732
> URL: https://issues.apache.org/jira/browse/WICKET-1732
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-final, 1.3.3
>Reporter: David Shepherdson
>Assignee: Martin Grigorov
>Priority: Minor
>
> When a DropDownChoice's onSelectionChanged() notification is sent from a 
> browser, it causes the whole page to be reloaded/redisplayed (because the 
> form is submitted). However, when the same notification is sent through the 
> FormTester, it doesn't submit the form and therefore other components on the 
> page may not be updated/redisplayed.
> We're working around this by overriding FormTester's select() method so that 
> it submits the form as follows:
> @Override
> public void select(String formComponentId, int index) {
> super.select(formComponentId, index);
> 
> // Workaround for Wicket FormTester bug: selection changed 
> notifications cause the page
> // to be reloaded in a real browser, but they don't when using the 
> Wicket tester.
> FormComponent component = 
> (FormComponent)getForm().get(formComponentId);
> if (component instanceof DropDownChoice) {
> try
> {
> Method wantOnSelectionChangedNotificationsMethod = 
> DropDownChoice.class.getDeclaredMethod("wantOnSelectionChangedNotifications", 
> new Class[0]);
> wantOnSelectionChangedNotificationsMethod.setAccessible(true);
> boolean wantOnSelectionChangedNotifications = 
> ((Boolean)wantOnSelectionChangedNotificationsMethod.invoke(component, new 
> Object[0])).booleanValue();
> if (wantOnSelectionChangedNotifications) {
> // Notification method call has already been made by 
> super,
> // but we want to trigger the page load, as would happen 
> in a real browser.
> 
> // First, use reflection to get the form's hidden field 
> id.
> Method getHiddenFieldIdMethod = 
> Form.class.getDeclaredMethod("getHiddenFieldId");
> getHiddenFieldIdMethod.setAccessible(true);
> String hiddenFieldId = (String) 
> getHiddenFieldIdMethod.invoke(getForm());
> 
> // Now set the parameter in the form
> // to cause it to call the callback when submitted.
> m_wicketTester.getServletRequest().setParameter(
> hiddenFieldId, 
> component.urlFor(IOnChangeListener.INTERFACE).toString());
> 
> // And finally submit the form.
> submit();
> 
> }
> }
> catch (Exception e)
> {
> throw new RuntimeException(e);
> }
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1053070 - /wicket/trunk/wicket-objectssizeof-agent/.settings/org.eclipse.jdt.core.prefs

2010-12-27 Thread mgrigorov
Author: mgrigorov
Date: Mon Dec 27 14:03:53 2010
New Revision: 1053070

URL: http://svn.apache.org/viewvc?rev=1053070&view=rev
Log:
Add missing Eclipse setting

Modified:
wicket/trunk/wicket-objectssizeof-agent/.settings/org.eclipse.jdt.core.prefs

Modified: 
wicket/trunk/wicket-objectssizeof-agent/.settings/org.eclipse.jdt.core.prefs
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-objectssizeof-agent/.settings/org.eclipse.jdt.core.prefs?rev=1053070&r1=1053069&r2=1053070&view=diff
==
--- 
wicket/trunk/wicket-objectssizeof-agent/.settings/org.eclipse.jdt.core.prefs 
(original)
+++ 
wicket/trunk/wicket-objectssizeof-agent/.settings/org.eclipse.jdt.core.prefs 
Mon Dec 27 14:03:53 2010
@@ -1,10 +1,11 @@
-#Fri Nov 05 09:41:17 PDT 2010
+#Mon Dec 27 12:49:57 CET 2010
 eclipse.preferences.version=1
 encoding//src/main/java=UTF-8
 encoding//src/main/resources=UTF-8
 encoding//src/test/java=UTF-8
 org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
 org.eclipse.jdt.core.compiler.compliance=1.5
+org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
 org.eclipse.jdt.core.compiler.source=1.5
 org.eclipse.jdt.core.formatter.align_type_members_on_columns=false
 
org.eclipse.jdt.core.formatter.alignment_for_arguments_in_allocation_expression=16




svn commit: r1053071 - /wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/tester/FormTester.java

2010-12-27 Thread mgrigorov
Author: mgrigorov
Date: Mon Dec 27 14:04:27 2010
New Revision: 1053071

URL: http://svn.apache.org/viewvc?rev=1053071&view=rev
Log:
WICKET-1721 FormTester doesnt support onSelectionChanged for RadioChoice
WICKET-1732 FormTester's DropDownChoice onSelectionChanged() behaviour doesn't 
reload page

Call #selectionChanged() for all form components which have 
#wantOnSelectionChangedNotifications()

Modified:

wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/tester/FormTester.java

Modified: 
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/tester/FormTester.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/tester/FormTester.java?rev=1053071&r1=1053070&r2=1053071&view=diff
==
--- 
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/tester/FormTester.java
 (original)
+++ 
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/util/tester/FormTester.java
 Mon Dec 27 14:04:27 2010
@@ -35,6 +35,7 @@ import org.apache.wicket.markup.html.for
 import org.apache.wicket.markup.html.form.FormComponent;
 import org.apache.wicket.markup.html.form.IChoiceRenderer;
 import org.apache.wicket.markup.html.form.IFormSubmittingComponent;
+import org.apache.wicket.markup.html.form.IOnChangeListener;
 import org.apache.wicket.markup.html.form.ListMultipleChoice;
 import org.apache.wicket.markup.html.form.Radio;
 import org.apache.wicket.markup.html.form.RadioChoice;
@@ -79,7 +80,8 @@ public class FormTester
}
 
/**
-* @see 
org.apache.wicket.util.visit.IVisitor#component(Object, 
org.apache.wicket.util.visit.IVisit)
+* @see 
org.apache.wicket.util.visit.IVisitor#component(Object,
+*  org.apache.wicket.util.visit.IVisit)
 */
public void component(final Component component, final 
IVisit visit)
{
@@ -302,7 +304,8 @@ public class FormTester
}
else
{
-   fail("Selecting on the component:'" + 
formComponent.getPath() + "' is not supported.");
+   fail("Selecting on the component:'" + 
formComponent.getPath() +
+   "' is not supported.");
return null;
}
}
@@ -535,22 +538,30 @@ public class FormTester
 
ChoiceSelector choiceSelector = 
choiceSelectorFactory.create(component);
choiceSelector.doSelect(index);
-   if (component instanceof DropDownChoice)
+
+   try
{
+   Method wantOnSelectionChangedNotificationsMethod = 
component.getClass()
+   
.getDeclaredMethod("wantOnSelectionChangedNotifications");
+
try
{
-   Method 
wantOnSelectionChangedNotificationsMethod = 
DropDownChoice.class.getDeclaredMethod("wantOnSelectionChangedNotifications");

wantOnSelectionChangedNotificationsMethod.setAccessible(true);
boolean wantOnSelectionChangedNotifications = 
(Boolean)wantOnSelectionChangedNotificationsMethod.invoke(component);
if (wantOnSelectionChangedNotifications)
{
-   
((DropDownChoice)component).onSelectionChanged();
+   tester.executeListener(component, 
IOnChangeListener.INTERFACE);
}
}
-   catch (Exception e)
+   catch (final Exception x)
{
-   throw new RuntimeException(e);
+   throw new RuntimeException(x);
}
+
+   }
+   catch (final NoSuchMethodException ignored)
+   {
+   // this form component has no auto page reload mechanism
}
}
 




[jira] Resolved: (WICKET-1721) FormTester doesnt support onSelectionChanged for RadioChoice

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov resolved WICKET-1721.
-

Resolution: Fixed

Improved with r1053071.

> FormTester doesnt support onSelectionChanged  for RadioChoice
> -
>
> Key: WICKET-1721
> URL: https://issues.apache.org/jira/browse/WICKET-1721
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
> Environment: Doesn't matter
>Reporter: Murat Yücel
>Assignee: Martin Grigorov
> Fix For: 1.5-M4
>
>
> It is not possible to test onSelectionChanged for RadioChoice and probably 
> also other form components.
> See this thread:
> http://www.nabble.com/Problem-test-RadioChoice-td18196023.html#a18196023

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (WICKET-1732) FormTester's DropDownChoice onSelectionChanged() behaviour doesn't reload page

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov resolved WICKET-1732.
-

   Resolution: Fixed
Fix Version/s: 1.5-M4

Improved with r1053071.

> FormTester's DropDownChoice onSelectionChanged() behaviour doesn't reload page
> --
>
> Key: WICKET-1732
> URL: https://issues.apache.org/jira/browse/WICKET-1732
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-final, 1.3.3
>Reporter: David Shepherdson
>Assignee: Martin Grigorov
>Priority: Minor
> Fix For: 1.5-M4
>
>
> When a DropDownChoice's onSelectionChanged() notification is sent from a 
> browser, it causes the whole page to be reloaded/redisplayed (because the 
> form is submitted). However, when the same notification is sent through the 
> FormTester, it doesn't submit the form and therefore other components on the 
> page may not be updated/redisplayed.
> We're working around this by overriding FormTester's select() method so that 
> it submits the form as follows:
> @Override
> public void select(String formComponentId, int index) {
> super.select(formComponentId, index);
> 
> // Workaround for Wicket FormTester bug: selection changed 
> notifications cause the page
> // to be reloaded in a real browser, but they don't when using the 
> Wicket tester.
> FormComponent component = 
> (FormComponent)getForm().get(formComponentId);
> if (component instanceof DropDownChoice) {
> try
> {
> Method wantOnSelectionChangedNotificationsMethod = 
> DropDownChoice.class.getDeclaredMethod("wantOnSelectionChangedNotifications", 
> new Class[0]);
> wantOnSelectionChangedNotificationsMethod.setAccessible(true);
> boolean wantOnSelectionChangedNotifications = 
> ((Boolean)wantOnSelectionChangedNotificationsMethod.invoke(component, new 
> Object[0])).booleanValue();
> if (wantOnSelectionChangedNotifications) {
> // Notification method call has already been made by 
> super,
> // but we want to trigger the page load, as would happen 
> in a real browser.
> 
> // First, use reflection to get the form's hidden field 
> id.
> Method getHiddenFieldIdMethod = 
> Form.class.getDeclaredMethod("getHiddenFieldId");
> getHiddenFieldIdMethod.setAccessible(true);
> String hiddenFieldId = (String) 
> getHiddenFieldIdMethod.invoke(getForm());
> 
> // Now set the parameter in the form
> // to cause it to call the callback when submitted.
> m_wicketTester.getServletRequest().setParameter(
> hiddenFieldId, 
> component.urlFor(IOnChangeListener.INTERFACE).toString());
> 
> // And finally submit the form.
> submit();
> 
> }
> }
> catch (Exception e)
> {
> throw new RuntimeException(e);
> }
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (WICKET-2264) Ajax xml response is not validated correct

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov reassigned WICKET-2264:
---

Assignee: Martin Grigorov

> Ajax xml response is not validated correct
> --
>
> Key: WICKET-2264
> URL: https://issues.apache.org/jira/browse/WICKET-2264
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.6
>Reporter: Jens Alenius
>Assignee: Martin Grigorov
> Attachments: myproject.rar
>
>
> Ajax xml response is not validated correct
> Try my quickstart project with Firefox. Clicking on the submit button should 
> update the label above. But does not. See the result in the error log in 
> firefox. 
> The control characters is not properly escaped. Ex: "\u0014" is written 
> as 0014 in the xml Ajax Response but should be . ''
> See: http://www.w3.org/TR/REC-xml/#dt-charref. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1053077 - in /wicket/trunk: wicket-core/src/main/java/org/apache/wicket/Component.java wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java

2010-12-27 Thread mgrigorov
Author: mgrigorov
Date: Mon Dec 27 14:34:23 2010
New Revision: 1053077

URL: http://svn.apache.org/viewvc?rev=1053077&view=rev
Log:
WICKET-2264 Ajax xml response is not validated correct

HTML escape all characters which are not in range 32-159 (incl.)

Modified:
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/Component.java

wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java

Modified: 
wicket/trunk/wicket-core/src/main/java/org/apache/wicket/Component.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-core/src/main/java/org/apache/wicket/Component.java?rev=1053077&r1=1053076&r2=1053077&view=diff
==
--- wicket/trunk/wicket-core/src/main/java/org/apache/wicket/Component.java 
(original)
+++ wicket/trunk/wicket-core/src/main/java/org/apache/wicket/Component.java Mon 
Dec 27 14:34:23 2010
@@ -1728,7 +1728,7 @@ public abstract class Component
if (getFlag(FLAG_ESCAPE_MODEL_STRINGS))
{
// Escape HTML sensitive characters 
only. Not all none-ascii chars
-   return 
Strings.escapeMarkup(modelString, false, false).toString();
+   return 
Strings.escapeMarkup(modelString, false, true).toString();
}
return modelString;
}

Modified: 
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java?rev=1053077&r1=1053076&r2=1053077&view=diff
==
--- 
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java
 (original)
+++ 
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java
 Mon Dec 27 14:34:23 2010
@@ -354,7 +354,7 @@ public final class Strings
if (convertToHtmlUnicodeEscapes)
{
int ci = 0x & c;
-   if (ci < 160)
+   if (ci > 31 && ci < 160)
{
// nothing 
special only 7 Bit

buffer.append(c);




[jira] Resolved: (WICKET-2264) Ajax xml response is not validated correct

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov resolved WICKET-2264.
-

   Resolution: Fixed
Fix Version/s: 1.5-M4

Fixed with r1053077 in 1.5.

> Ajax xml response is not validated correct
> --
>
> Key: WICKET-2264
> URL: https://issues.apache.org/jira/browse/WICKET-2264
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.6
>Reporter: Jens Alenius
>Assignee: Martin Grigorov
> Fix For: 1.5-M4
>
> Attachments: myproject.rar
>
>
> Ajax xml response is not validated correct
> Try my quickstart project with Firefox. Clicking on the submit button should 
> update the label above. But does not. See the result in the error log in 
> firefox. 
> The control characters is not properly escaped. Ex: "\u0014" is written 
> as 0014 in the xml Ajax Response but should be . ''
> See: http://www.w3.org/TR/REC-xml/#dt-charref. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (WICKET-2652) LiveSessionsPage (devutils) leaks memory

2010-12-27 Thread Martin Grigorov (JIRA)

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

Martin Grigorov resolved WICKET-2652.
-

Resolution: Cannot Reproduce

Closing as "Cannot Reproduce".

> LiveSessionsPage (devutils) leaks memory
> 
>
> Key: WICKET-2652
> URL: https://issues.apache.org/jira/browse/WICKET-2652
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4.5
>Reporter: Marat Radchenko
>
> Steps to reproduce:
> 1. Open LiveSessionsPage
> 2. Click "Enable request recording"
> 3. Click "Disable request recording"
> 4. Refresh page several times and observe session growth.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Martin Grigorov (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975267#action_12975267
 ] 

Martin Grigorov commented on WICKET-1973:
-

I think this issue is still relevant for Wicket 1.5.
The buffered responses (only for stateful pages) are stored in the Application 
and thus are not replicated to the other nodes.

Recently we had discussion about this behavior when trying to store the 
buffered response for stateless pages (see WICKET-3239).
If I don't miss something important then I think the storage for buffered 
responses for stateful pages can be moved to the user's Session.
Currently the storing for stateless pages is disabled by default but if someone 
needs this functionality then the storage for them should be in Application.

> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1053088 - /wicket/trunk/wicket/

2010-12-27 Thread pete
Author: pete
Date: Mon Dec 27 15:36:07 2010
New Revision: 1053088

URL: http://svn.apache.org/viewvc?rev=1053088&view=rev
Log:
ignore resources from work environment that do not belong to project

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

Propchange: wicket/trunk/wicket/
--
--- svn:ignore (added)
+++ svn:ignore Mon Dec 27 15:36:07 2010
@@ -0,0 +1,6 @@
+.classpath
+.project
+target
+RECYCLER
+*.iml
+*.iws




[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Igor Vaynberg (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975273#action_12975273
 ] 

Igor Vaynberg commented on WICKET-1973:
---

storing the buffer in session is a big nono. we do not want the buffer 
replicated across the cluster as it can be quiet big.

> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Johan Compagner (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975279#action_12975279
 ] 

Johan Compagner commented on WICKET-1973:
-

you really should use sticky sessions,
I dont see any reason not to use that, and it is way better for performance.
A browser can do many request at the same time to the server, those should hit 
the same node, else you have multithreaded access to pages over multiply 
computers. What is then the final page that you want to have?


> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Igor Vaynberg (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975281#action_12975281
 ] 

Igor Vaynberg commented on WICKET-1973:
---

the usecase is when a node fails and session fails over to another one.

> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Erik van Oosten (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975285#action_12975285
 ] 

Erik van Oosten commented on WICKET-1973:
-

The other use case is the odd-client that insists on using a round robin load 
balancer.

> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Igor Vaynberg (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975288#action_12975288
 ] 

Igor Vaynberg commented on WICKET-1973:
---

that odd client would have to use a strategy other then redirect to buffer

> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Johan Compagner (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975289#action_12975289
 ] 

Johan Compagner commented on WICKET-1973:
-

How many times does it happens that a node fails and at the same time you would 
have just between the real and the redirect request you that would have had 
messages??

you have to use a round robin load balancer but for new sessions.
Not for existing sessions.. That really can jus screw things up...


> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Martin Grigorov (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975303#action_12975303
 ] 

Martin Grigorov commented on WICKET-1973:
-

Then we can document this as a known issue/limitation of this strategy and 
close the ticket. Objections ?

> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



svn commit: r1053167 - in /wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar: DateField.java DateTimeField.java TimeField.java

2010-12-27 Thread jdonnerstag
Author: jdonnerstag
Date: Mon Dec 27 20:00:47 2010
New Revision: 1053167

URL: http://svn.apache.org/viewvc?rev=1053167&view=rev
Log:
another attempt trying to understand why DatePickerTest works on my laptop but 
fails on our hudson.

Modified:

wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java

wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateTimeField.java

wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/TimeField.java

Modified: 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java?rev=1053167&r1=1053166&r2=1053167&view=diff
==
--- 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java
 (original)
+++ 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java
 Mon Dec 27 20:00:47 2010
@@ -74,8 +74,8 @@ public class DateField extends DateTimeF
{
super(id, model);
 
-   get("hours").setVisible(false);
-   get("minutes").setVisible(false);
-   get("amOrPmChoice").setVisibilityAllowed(false);
+   get(HOURS).setVisibilityAllowed(false);
+   get(MINUTES).setVisibilityAllowed(false);
+   get(AM_OR_PM_CHOICE).setVisibilityAllowed(false);
}
 }

Modified: 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateTimeField.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateTimeField.java?rev=1053167&r1=1053166&r2=1053167&view=diff
==
--- 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateTimeField.java
 (original)
+++ 
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateTimeField.java
 Mon Dec 27 20:00:47 2010
@@ -51,8 +51,6 @@ import org.joda.time.format.DateTimeForm
  */
 public class DateTimeField extends FormComponentPanel
 {
-   private static final long serialVersionUID = 1L;
-
/**
 * Enumerated type for different ways of handling the render part of 
requests.
 */
@@ -81,23 +79,35 @@ public class DateTimeField extends FormC
}
}
 
-   private static final IConverter MINUTES_CONVERTER = new 
ZeroPaddingIntegerConverter(2);
+   private static final long serialVersionUID = 1L;
 
-   private AM_PM amOrPm = AM_PM.AM;
+   // Component-IDs
+   protected static final String DATE = "date";
+   protected static final String HOURS = "hours";
+   protected static final String MINUTES = "minutes";
+   protected static final String AM_OR_PM_CHOICE = "amOrPmChoice";
 
-   private DropDownChoice amOrPmChoice;
+   // PropertyModel string to access getAmOrPm
+   private static final String AM_OR_PM = "amOrPm";
 
-   private MutableDateTime date;
+   private static final IConverter MINUTES_CONVERTER = new 
ZeroPaddingIntegerConverter(2);
 
-   private DateTextField dateField;
+   // The dropdown list for AM/PM and it's associated model object
+   private DropDownChoice amOrPmChoice;
+   private AM_PM amOrPm = AM_PM.AM;
 
-   private Integer hours;
+   // The date TextField and it's associated model object
+   // Note that any time information in date will be ignored
+   private DateTextField dateField;
+   private Date date;
 
+   // The TextField for "hours" and it's associated model object
private TextField hoursField;
+   private Integer hours;
 
-   private Integer minutes;
-
+   // The TextField for "minutes" and it's associated model object
private TextField minutesField;
+   private Integer minutes;
 
/**
 * Construct.
@@ -119,16 +129,25 @@ public class DateTimeField extends FormC
{
super(id, model);
 
+   // Sets the type that will be used when updating the model for 
this component.
setType(Date.class);
-   PropertyModel dateFieldModel = new 
PropertyModel(this, "date");
-   add(dateField = newDateTextField("date", dateFieldModel));
+
+   // Create and add the date TextField
+   PropertyModel dateFieldModel = new 
PropertyModel(this, DATE);
+   add(dateField = newDateTextField(DATE, dateFieldModel));
+
+   // Add a date picker to the date TextField
dateField.add(newDatePicker());
-   add(hoursField = new TextField("hours", new 
PropertyModel(this

[jira] Created: (WICKET-3286) DropDownChoice: "data" or "choices?"

2010-12-27 Thread Willis Blackburn (JIRA)
DropDownChoice:  "data" or "choices?"
-

 Key: WICKET-3286
 URL: https://issues.apache.org/jira/browse/WICKET-3286
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.5-M3
Reporter: Willis Blackburn


In DropDownChoice, sometimes the constructor argument is called "data" and 
sometimes "choices."  These look like the same parameter; wouldn't it be better 
to give the same parameter the same name across all the constructors?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (WICKET-1790) DatePicker javaScript should be optimized. Currently DatePicker generates 3000 bytes of javascript for each date field.

2010-12-27 Thread JIRA

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

Attila Király updated WICKET-1790:
--

Attachment: WICKET-1790.patch

Attaching a patch that resolves this issue.

It's mainly a refactor of the original code to generate 3 different javascript 
instead of 1.

1, the loading, initalizing javascript with some new helper functions is now 
generated only once per page.

2, localization strings are generated only once per localization per page. 
Because most application use the same localization for all datepickers in a 
page in practice this means that localization strings are only generated once 
per page. This is a reduction not only in generated js bytes but also in server 
side cpu cycles.

3, datepicker init script which is generated for every datepicker on page is 
greatly reduced.

I made some tests to see how much is the size reduction. These were measured in 
deployment mode with wicket javascript compressor working.

The original 1.5M3 code generated around 1830 bytes of javascript per 
datepicker. The new code generates 340 (+ once the js generated by 1, and 2,). 
This means that there is no real difference if there is only 1 datepicker in 
page. But with 2 datepickers the reduction is 35% with 10 it is 72%.

The patch is made against wicket trunk, revision 1053118 (somewhere between the 
already released 1.5M3 and the upcoming 1.5M4). Junit tests in the datepicker 
submodule pass but for the first time junit needs to be run with 
"-Dwicket.replace.expected.results=true" because 
/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1_ExpectedResult.html
 needs to be regenerated.

Hopefully somebody in the wicket team can spare some time to review the patch 
and apply it if it is found good enough.

> DatePicker javaScript should be optimized. Currently DatePicker generates 
> 3000 bytes of javascript for each date field.
> ---
>
> Key: WICKET-1790
> URL: https://issues.apache.org/jira/browse/WICKET-1790
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-extensions
>Affects Versions: 1.4-M1
>Reporter: Martin Makundi
> Attachments: WICKET-1790.patch
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> Currently DatePicker generates 3000 bytes of javascript per each date field 
> (more specifically per each date field having DatePicker).
> If you have a table with 2 date columns and 10 rows this means 6 bytes 
> excess HTTP traffic. And it shows. It slows down page rendering significantly.
> DatePicker javaScript should be optimized. I myself am not a javascript 
> wizard, I do not know which hooks could serve this change. But I know where 
> the problem is: each datePicker component is given its own initializer 
> methods instead of using parametrized method calls:
> // block 1
> initproject__employee__startdate123 = function() {
>   Wicket.DateTime.init( {
> widgetId: "project__employee__startdate123",<-- this 
> should be suitably parametrized
> componentId: "project__employee__startdate123",   <-- this 
> should be suitably parametrized
>   
> }
> // block 2
> if (wicketCalendarInitFinished) {
>   initproject__employee__startdate123();  <-- this should be suitably 
> parametrized
> } else {
>   wicketCalendarInits.push(initproject__employee__startdate123); <-- 
> this should be suitably parametrized
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer

2010-12-27 Thread Erik van Oosten (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975442#action_12975442
 ] 

Erik van Oosten commented on WICKET-1973:
-

None from me.

> Messages lost upon session failover with redirect_to_buffer
> ---
>
> Key: WICKET-1973
> URL: https://issues.apache.org/jira/browse/WICKET-1973
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> Using the redirect_to_buffer render strategy, messages in the session get 
> cleared after the render.
> If the redirected request comes in at another node, the buffer is not found 
> and the page is re-rendered. In this case the messages are no longer 
> available.
> See the javadoc of WebApplication#popBufferedResponse(String,String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.