svn commit: r571925 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java

2007-09-01 Thread ivaynberg
Author: ivaynberg
Date: Sat Sep  1 22:22:04 2007
New Revision: 571925

URL: http://svn.apache.org/viewvc?rev=571925&view=rev
Log:
fixed bug where getlevelasstring() failed due to recent change in level 
numbering

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java?rev=571925&r1=571924&r2=571925&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java
 Sat Sep  1 22:22:04 2007
@@ -17,6 +17,8 @@
 package org.apache.wicket.feedback;
 
 import java.io.Serializable;
+import java.util.HashMap;
+import java.util.Map;
 
 import org.apache.wicket.Component;
 import org.apache.wicket.IClusterable;
@@ -54,8 +56,17 @@
public static final int WARNING = 300;
 
/** Levels as strings for debugging. */
-   private static final String[] levelStrings = new String[] { 
"UNDEFINED", "DEBUG", "INFO",
-   "WARNING", "ERROR", "FATAL" };
+   private static final Map levelStrings = new HashMap();
+
+   static
+   {
+   levelStrings.put(new Integer(0), "UNDEFINED");
+   levelStrings.put(new Integer(100), "DEBUG");
+   levelStrings.put(new Integer(200), "INFO");
+   levelStrings.put(new Integer(300), "WARNING");
+   levelStrings.put(new Integer(400), "ERROR");
+   levelStrings.put(new Integer(500), "FATAL");
+   }
 
/**
 * The message level; can be used by rendering components. Note that 
what actually happens with
@@ -130,7 +141,7 @@
 */
public String getLevelAsString()
{
-   return levelStrings[getLevel() / 100];
+   return (String)levelStrings.get(new Integer(getLevel()));
}
 
/**




[jira] Created: (WICKET-918) allow for pluggable javascript compression algorithms

2007-09-01 Thread Ryan Sonnek (JIRA)
allow for pluggable javascript compression algorithms
-

 Key: WICKET-918
 URL: https://issues.apache.org/jira/browse/WICKET-918
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Reporter: Ryan Sonnek
Priority: Minor


The current JavascripResource uses a very simple algorithm to compress 
javascript (JavascriptStripper).  This should be abstracted into a pluggable 
interface so that any algorithm can be used.  There are a number of popular 
javascript compression tools out there that could be integrated into wicket if 
this feature is supported.

* dojo javascript compression tool
* JSMin
* YUI compression tool

My suggestion for implementation would be to create an interface:
{code}
public interface JavascriptCompressor {
  public String stripCommentsAndWhitespace(String original);
}
{code}

The existing JavascriptStripper would be the default implementation, but there 
would be an application setting to swap in a different implementation.  
Actually I would recommend creating a NoOp implementation as the default 
implementation.

{code}
public class MyApplication extends WebApplication {
  public void init() {
getResourceSettings().setJavascriptCompressor(new 
MyFancyJavascriptCompressor());
  }
}
{code}



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



svn commit: r571909 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 17:25:35 2007
New Revision: 571909

URL: http://svn.apache.org/viewvc?rev=571909&view=rev
Log:
quick fix

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java?rev=571909&r1=571908&r2=571909&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessage.java
 Sat Sep  1 17:25:35 2007
@@ -130,7 +130,7 @@
 */
public String getLevelAsString()
{
-   return levelStrings[getLevel()];
+   return levelStrings[getLevel() / 100];
}
 
/**




[jira] Resolved: (WICKET-879) reduce code in DatePicker.js (because it can be loaded multiple times per page)

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-879.


Resolution: Fixed

> reduce code in DatePicker.js (because it can be loaded multiple times per 
> page)
> ---
>
> Key: WICKET-879
> URL: https://issues.apache.org/jira/browse/WICKET-879
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-datetime
>Affects Versions: 1.3.0-beta2
>Reporter: Gerolf Seitz
>Assignee: Matej Knopp
>Priority: Trivial
> Fix For: 1.3.0-beta4
>
> Attachments: size_reduction.patch, size_reduction.patch
>
>
> everytime the DatePicker behavior is added to a component, the file 
> DatePicker.js is rendered to the head (with interpolated vars that are 
> specific for each DatePicker instance).
> some of the code (actually only the code in the function 
> init${widgetId}DpJs()) can be moved to wicket-date.js
> the rest of the code is used for the yuiloader and can't be moved to 
> wicket-date.js, since the loader actually loads this file.

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



svn commit: r571908 - in /wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar: DatePicker.js assets/wicket-calendar.css wicket-date.js

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 17:13:30 2007
New Revision: 571908

URL: http://svn.apache.org/viewvc?rev=571908&view=rev
Log:
WICKET-879

Modified:

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

wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/wicket-calendar.css

wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/wicket-date.js

Modified: 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.js
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.js?rev=571908&r1=571907&r2=571908&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.js
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DatePicker.js
 Sat Sep  1 17:13:30 2007
@@ -24,7 +24,7 @@
checkWicketDate(name, loaderCallback);
}, 50);
}
-};
+}
 
 wicketYuiLoader.addModule({
name: "wicket-date",
@@ -35,46 +35,30 @@
 });
 
 
-function check${widgetId}Loader() {
+function check${widgetId}Loader() {
if (!wicketYuiLoader.initializing) {
wicketYuiLoader.initializing = true;
wicketYuiLoader.require("wicket-date");
wicketYuiLoader.insert(function() {
wicketYuiLoader.initializing = false;
+   // init the datepicker  
init${widgetId}DpJs();
});
}  else {
setTimeout(check${widgetId}Loader, 50);
}
- }
-
-check${widgetId}Loader();  
- 
-function init${widgetId}DpJs() {
-
-   YAHOO.namespace("wicket");
-   YAHOO.wicket.${widgetId}DpJs = new 
YAHOO.widget.Calendar("${widgetId}DpJs","${widgetId}Dp", { ${calendarInit} });
-   YAHOO.wicket.${widgetId}DpJs.isVisible = function() { return 
YAHOO.wicket.${widgetId}DpJs.oDomContainer.style.display == 'block'; }
-   if (${enableMonthYearSelection}) 
Wicket.DateTime.enableMonthYearSelection(YAHOO.wicket.${widgetId}DpJs); 
-   
-   function showCalendar() {
-   Wicket.DateTime.showCalendar(YAHOO.wicket.${widgetId}DpJs, 
YAHOO.util.Dom.get("${componentId}").value, '${datePattern}');
-   if (${alignWithIcon}) 
Wicket.DateTime.positionRelativeTo(YAHOO.wicket.${widgetId}DpJs.oDomContainer, 
"${widgetId}Icon");
-   if (${enableMonthYearSelection}) 
Wicket.DateTime.enableMonthYearSelection(YAHOO.wicket.${widgetId}DpJs); 
-   }
-
-   YAHOO.util.Event.addListener("${widgetId}Icon", "click", showCalendar, 
YAHOO.wicket.${widgetId}DpJs, true);
-
-   function selectHandler(type, args, cal) {
-   YAHOO.util.Dom.get("${componentId}").value = 
Wicket.DateTime.substituteDate('${datePattern}', args[0][0]);
-   var wasVisible = YAHOO.wicket.${widgetId}DpJs.isVisible();
-   cal.hide();
-   if (${fireChangeEvent} && wasVisible) {
-   var field = YAHOO.util.Dom.get("${componentId}");
-   if (typeof(field.onchange) != 'undefined') 
field.onchange();
-   }
-   }
+}
 
-   
YAHOO.wicket.${widgetId}DpJs.selectEvent.subscribe(selectHandler,YAHOO.wicket.${widgetId}DpJs);
-   YAHOO.wicket.${widgetId}DpJs.render();
+init${widgetId}DpJs = function() {
+   Wicket.DateTime.init( {
+   widgetId: "${widgetId}",
+   componentId: "${componentId}",  

+   calendarInit: { ${calendarInit} },
+   datePattern: "${datePattern}",
+   alignWithIcon: ${alignWithIcon},
+   enableMonthYearSelection: 
${enableMonthYearSelection},
+   fireChangeEvent: ${fireChangeEvent}
+   });
 }
+
+check${widgetId}Loader();

Modified: 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/wicket-calendar.css
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/wicket-calendar.css?rev=571908&r1=571907&r2=571908&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/wicket-calendar.css
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/wicket-calendar.css
 Sat Sep  1 17:13:30 2007
@@ -30,7 +3

svn commit: r571906 - /wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/skins/sam/calendar.css

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 17:05:09 2007
New Revision: 571906

URL: http://svn.apache.org/viewvc?rev=571906&view=rev
Log:
made text color darker for month

Modified:

wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/skins/sam/calendar.css

Modified: 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/skins/sam/calendar.css
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/skins/sam/calendar.css?rev=571906&r1=571905&r2=571906&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/skins/sam/calendar.css
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/assets/skins/sam/calendar.css
 Sat Sep  1 17:05:09 2007
@@ -4,4 +4,4 @@
 http://developer.yahoo.net/yui/license.txt
 version: 2.3.0
 */
-.yui-calcontainer{position:relative;float:left;_overflow:hidden;}.yui-calcontainer
 
iframe{position:absolute;border:none;margin:0;padding:0;z-index:0;width:100%;height:100%;left:0px;top:0px;}.yui-calcontainer
 
iframe.fixedsize{width:50em;height:50em;top:-1px;left:-1px;}.yui-calcontainer.multi
 .groupcal{z-index:1;float:left;position:relative;}.yui-calcontainer 
.title{position:relative;z-index:1;}.yui-calcontainer 
.close-icon{position:absolute;z-index:1;}.yui-calendar{position:relative;}.yui-calendar
 .calnavleft{position:absolute;z-index:1;}.yui-calendar 
.calnavright{position:absolute;z-index:1;}.yui-calendar 
.calheader{position:relative;width:100%;text-align:center;}.yui-calendar 
.calbody 
a:hover{background:inherit;}p#clear{clear:left;padding-top:10px;}.yui-skin-sam 
.yui-calcontainer{background-color:#f2f2f2;border:1px solid 
#808080;padding:10px;}.yui-skin-sam .yui-calcontainer.multi{padding:0 5px 0 
5px;}.yui-skin-sam .yui-calcontainer.multi .groupcal{background-color:transpare
 nt;border:none;padding:10px 5px 10px 5px;margin:0;}.yui-skin-sam 
.yui-calcontainer 
.title{background:url(../../../../assets/skins/sam/sprite.png) repeat-x 0 
0;border-bottom:1px solid #cc;font:100% 
sans-serif;color:#000;font-weight:bold;height:auto;padding:.4em;margin:0 -10px 
10px -10px;top:0;left:0;text-align:left;}.yui-skin-sam .yui-calcontainer.multi 
.title{margin:0 -5px 0 -5px;}.yui-skin-sam 
.yui-calcontainer.withtitle{padding-top:0;}.yui-skin-sam .yui-calcontainer 
.calclose{background:url(../../../../assets/skins/sam/sprite.png) no-repeat 0 
-300px;width:25px;height:15px;top:.4em;right:.4em;cursor:pointer;}.yui-skin-sam 
.yui-calendar{border-spacing:0;border-collapse:collapse;font:100% 
sans-serif;text-align:center;}.yui-skin-sam .yui-calendar 
.calhead{background:transparent;border:none;vertical-align:middle;}.yui-skin-sam
 .yui-calendar .calheader{background:transparent;font-weight:bold;padding:0 0 
.6em 0;text-align:center;}.yui-skin-sam .yui-calendar .calheader img{bor
 der:none;}.yui-skin-sam .yui-calendar 
.calnavleft{background:url(../../../../assets/skins/sam/sprite.png) no-repeat 0 
-450px;width:25px;height:15px;top:0;bottom:0;left:-10px;margin-left:.4em;cursor:pointer;}.yui-skin-sam
 .yui-calendar 
.calnavright{background:url(../../../../assets/skins/sam/sprite.png) no-repeat 
0 
-500px;width:25px;height:15px;top:0;bottom:0;right:-10px;margin-right:.4em;cursor:pointer;}.yui-skin-sam
 .yui-calendar .calweekdayrow{height:2em;}.yui-skin-sam .yui-calendar 
.calweekdaycell{color:#000;font-weight:bold;text-align:center;width:2em;}.yui-skin-sam
 .yui-calendar .calfoot{background-color:#f2f2f2;}.yui-skin-sam .yui-calendar 
.calrowhead,.yui-skin-sam .yui-calendar 
.calrowfoot{color:#a6a6a6;font-size:85%;font-style:normal;font-weight:normal;}.yui-skin-sam
 .yui-calendar .calrowhead{text-align:right;padding-right:2px;}.yui-skin-sam 
.yui-calendar .calrowfoot{text-align:left;padding-left:2px;}.yui-skin-sam 
.yui-calendar td.calcell{border:1px solid #cc;bac
 
kground:#fff;padding:1px;height:1.6em;line-height:1.6em;text-align:center;white-space:nowrap;}.yui-skin-sam
 .yui-calendar td.calcell 
a{color:#0066cc;display:block;height:100%;text-decoration:none;}.yui-skin-sam 
.yui-calendar td.calcell.today{background-color:#000;}.yui-skin-sam 
.yui-calendar td.calcell.today a{background-color:#fff;}.yui-skin-sam 
.yui-calendar 
td.calcell.oom{background-color:#cc;color:#a6a6a6;cursor:default;}.yui-skin-sam
 .yui-calendar 
td.calcell.selected{background-color:#fff;color:#000;}.yui-skin-sam 
.yui-calendar td.calcell.selected 
a{background-color:#b3d4ff;color:#000;}.yui-skin-sam .yui-calendar 
td.calcell.calcellhover{background-color:#426fd9;color:#fff;cursor:pointer;}.yui-skin-sam
 .yui-calendar td.calcell.calcellhover 
a{background-color:#426fd9;color:#fff;}.yui-skin-sam .yui-calendar 
td.calcell.previous{color:#e0e0e0;}.yui-skin-sam .yui-cal

svn commit: r571891 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/string/JavascriptStripper.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 16:00:04 2007
New Revision: 571891

URL: http://svn.apache.org/viewvc?rev=571891&view=rev
Log:
fixed a typo

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/string/JavascriptStripper.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/string/JavascriptStripper.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/string/JavascriptStripper.java?rev=571891&r1=571890&r2=571891&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/string/JavascriptStripper.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/string/JavascriptStripper.java
 Sat Sep  1 16:00:04 2007
@@ -25,26 +25,26 @@
 public class JavascriptStripper
 {
/*
-* Determines the state of script proessing.
+* Determines the state of script processing.
 */
/** Inside regular text */
-   private final static int REGULAR_TEXT = 1; 
-   
+   private final static int REGULAR_TEXT = 1;
+
/** String started with single quote (') */
private final static int STRING_SINGLE_QUOTE = 2;
-   
+
/** String started with double quotes (") */
-   private final static int STRING_DOUBLE_QUOTES = 3; 
-   
+   private final static int STRING_DOUBLE_QUOTES = 3;
+
/** Inside two or more whitespace characters */
-   private final static int WHITE_SPACE = 4; 
-   
-   /** Inside a line comment (//   ) */
-   private final static int LINE_COMMENT = 5; 
-   
+   private final static int WHITE_SPACE = 4;
+
+   /** Inside a line comment (// ) */
+   private final static int LINE_COMMENT = 5;
+
/** Inside a multi line comment */
private final static int MULTILINE_COMMENT = 6;
-   
+
/** Inside a regular expression */
private final static int REG_EXP = 7;
 
@@ -92,7 +92,8 @@
else if (c == '/')
{
// This might be a divide operator, or 
it might be a regular expression.
-   // Work out if it's a regular 
expression by finding the previous non-whitespace char, which
+   // Work out if it's a regular 
expression by finding the previous non-whitespace
+   // char, which
// will be either '=' or '('. If it's 
not, it's just a divide operator.
int idx = i - 1;
while (idx > 0)
@@ -167,7 +168,7 @@
result.append(c);
continue;
}
-   
+
if (state == REG_EXP)
{
if (c == '/' && prev != '\\')




[jira] Assigned: (WICKET-879) reduce code in DatePicker.js (because it can be loaded multiple times per page)

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp reassigned WICKET-879:
--

Assignee: Matej Knopp

> reduce code in DatePicker.js (because it can be loaded multiple times per 
> page)
> ---
>
> Key: WICKET-879
> URL: https://issues.apache.org/jira/browse/WICKET-879
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-datetime
>Affects Versions: 1.3.0-beta2
>Reporter: Gerolf Seitz
>Assignee: Matej Knopp
>Priority: Trivial
> Fix For: 1.3.0-beta4
>
> Attachments: size_reduction.patch, size_reduction.patch
>
>
> everytime the DatePicker behavior is added to a component, the file 
> DatePicker.js is rendered to the head (with interpolated vars that are 
> specific for each DatePicker instance).
> some of the code (actually only the code in the function 
> init${widgetId}DpJs()) can be moved to wicket-date.js
> the rest of the code is used for the yuiloader and can't be moved to 
> wicket-date.js, since the loader actually loads this file.

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



[jira] Resolved: (WICKET-909) onBeforeRender not called on ModalWindow contents

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-909.


   Resolution: Fixed
Fix Version/s: 1.3.0-beta4

> onBeforeRender not called on ModalWindow contents
> -
>
> Key: WICKET-909
> URL: https://issues.apache.org/jira/browse/WICKET-909
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta3
> Environment: Tomcat 5.5.1
> Windows
> Eclipse + wtp
>Reporter: Thomas Mäder
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.3.0-beta4
>
> Attachments: TestModal.zip
>
>
> ModalWindow.onBeforeRender contains the following code:
>   super.onBeforeRender();
>   getContent().setOutputMarkupId(true);
>   getContent().setVisible(shown);
> This has the consequence that the content of the modal windows is still 
> invisible when its onBeforeRender() method is called. The default 
> implementation of onBeforeRender delegates to the window's children 
> beforeRender() method. However, the contents beforeRender() method first 
> checks if the component is visible, which is not the case, so the 
> onBeforeRender()  call is not propagated down the component tree. 
> This is a problem if the content of the modal window is something like a 
> table, which populates itself in the onBeforeRender call. 

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



svn commit: r571890 - /wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 15:40:38 2007
New Revision: 571890

URL: http://svn.apache.org/viewvc?rev=571890&view=rev
Log:
WICKET-909

Modified:

wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java

Modified: 
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java?rev=571890&r1=571889&r2=571890&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow.java
 Sat Sep  1 15:40:38 2007
@@ -752,8 +752,6 @@
 */
protected void onBeforeRender()
{
-   super.onBeforeRender();
-
// if user is refreshing whole page, the window will not be 
shown
if (((WebRequest)getRequest()).isAjax() == false)
{
@@ -762,6 +760,8 @@
 
getContent().setOutputMarkupId(true);
getContent().setVisible(shown);
+   
+   super.onBeforeRender();
}
 
/**




[jira] Updated: (WICKET-879) reduce code in DatePicker.js (because it can be loaded multiple times per page)

2007-09-01 Thread Gerolf Seitz (JIRA)

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

Gerolf Seitz updated WICKET-879:


Attachment: size_reduction.patch

> reduce code in DatePicker.js (because it can be loaded multiple times per 
> page)
> ---
>
> Key: WICKET-879
> URL: https://issues.apache.org/jira/browse/WICKET-879
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-datetime
>Affects Versions: 1.3.0-beta2
>Reporter: Gerolf Seitz
>Priority: Trivial
> Fix For: 1.3.0-beta4
>
> Attachments: size_reduction.patch, size_reduction.patch
>
>
> everytime the DatePicker behavior is added to a component, the file 
> DatePicker.js is rendered to the head (with interpolated vars that are 
> specific for each DatePicker instance).
> some of the code (actually only the code in the function 
> init${widgetId}DpJs()) can be moved to wicket-date.js
> the rest of the code is used for the yuiloader and can't be moved to 
> wicket-date.js, since the loader actually loads this file.

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



[jira] Resolved: (WICKET-895) If a form includes a DataTable with AjaxEditableLabels and the form should be refresh an exception occurs when a user switches between a changed label to another

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-895.


   Resolution: Fixed
Fix Version/s: 1.3.0-beta4

> If a form includes a DataTable with AjaxEditableLabels and the form should be 
> refresh an exception occurs when a user switches between a changed label to 
> another
> -
>
> Key: WICKET-895
> URL: https://issues.apache.org/jira/browse/WICKET-895
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-final
> Environment: Win2000, Eclipse 3.2, Java 1.5, Firefox 2.0.6, 
>Reporter: Fabian Hagen
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: wicket_quick.zip
>
>
> A normal Form includes a DataTable which includes some AjaxEditableLabels.
> If the user changes the contens of a label and the label has an effect of the 
> whole DataTable the complete from has to be refreshed. But if the user 
> switches between one label to another, an exception occurs.
> UseCase:
> click on label and change the value
> to leave the label click another labe in the DataTabel
> --> an exception should occur

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



[jira] Commented: (WICKET-497) For stateless mounted page incorrect url is generated

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-497:


I wouldn't be surprised that this doesn't work because of 
continueToOriginalDestination() which relies on (bound) session.

> For stateless mounted page incorrect url is generated
> -
>
> Key: WICKET-497
> URL: https://issues.apache.org/jira/browse/WICKET-497
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta1
> Environment: wicket-1.3.0-incubating-snapshot.jar from 21 Apr 2007
>Reporter: Shumbola
> Fix For: 1.3.0-beta4
>
>
> There is no redirect by default if I use setResponsePage(new Home()) inside 
> onSubmit() handler. If set redirect explicitly, after login from stateless 
> SignIn page the url contains form submission listener. Example: 
> http://localhost:/app/signin/wicket:interface/%3A0%3AsignInForm%3A%3AIFormSubmitListener%3A?wicket:interface=:1:::.

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



[jira] Resolved: (WICKET-771) Provide ResourceReference with ID attribute for filtering multiple includes

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-771.


Resolution: Fixed

Added 
public void renderJavascriptReference(ResourceReference reference, String id);
and
public void renderJavascriptReference(String url, String id);

so it is possible to filter out javascript references by id

> Provide ResourceReference with ID attribute for filtering multiple includes
> ---
>
> Key: WICKET-771
> URL: https://issues.apache.org/jira/browse/WICKET-771
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 1.3.0-beta1, 1.3.0-beta2
>Reporter: Jim McLaughlin
> Fix For: 1.3.0-beta4
>
>
> Provide ResourceReference with an ID attribute that can be used to reduce 
> multiple inclusions. This will allow different projects to include the same 
> resources without worrying about double includes (if they agree to use the 
> same id) even if the resources have different urls.

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



svn commit: r571888 - in /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket: ajax/AjaxRequestTarget.java ajax/wicket-ajax.js markup/html/IHeaderResponse.java markup/html/internal/HeaderRespo

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 15:18:37 2007
New Revision: 571888

URL: http://svn.apache.org/viewvc?rev=571888&view=rev
Log:
WICKET-771

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java?rev=571888&r1=571887&r2=571888&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
 Sat Sep  1 15:18:37 2007
@@ -805,10 +805,22 @@
super.renderJavascriptReference(reference);
}
 
+   public void renderJavascriptReference(ResourceReference 
reference, String id)
+   {
+   checkHeaderRendering();
+   super.renderJavascriptReference(reference, id);
+   }
+
public void renderJavascriptReference(String url)
{
checkHeaderRendering();
super.renderJavascriptReference(url);
+   }
+
+   public void renderJavascriptReference(String url, String id)
+   {
+   checkHeaderRendering();
+   super.renderJavascriptReference(url, id);
}
 
public void renderString(CharSequence string)

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?rev=571888&r1=571887&r2=571888&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js 
(original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js 
Sat Sep  1 15:18:37 2007
@@ -1351,7 +1351,7 @@
 // Adds a javascript element to page header. 
 // The fakeSrc attribute is used to filter out duplicate javascript references.
 // External javascripts are loaded using xmlhttprequest. Then a javascript 
element is created and the
-// javascript body is used as text for the element. Fori javascript 
references, wicket uses the src 
+// javascript body is used as text for the element. For javascript references, 
wicket uses the src 
 // attribute to filter out duplicates. However, since we set the body of the 
element, we can't assign
 // also a src value. Therefore we put the url to the src_ (notice the 
underscore)  attribute.
 // Wicket.Head.containsElement is aware of that and takes also the underscored 
attributes into account.

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java?rev=571888&r1=571887&r2=571888&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java
 Sat Sep  1 15:18:37 2007
@@ -40,10 +40,33 @@
/**
 * Writes a javascript reference, if the specified reference hasn't 
been rendered yet.
 * 
+* @param reference
+*resource reference pointing to the javascript resource
+* @param id
+*id that will be used to filter duplicate reference (it's 
still filtered by URL
+*too)
+*/
+   public void renderJavascriptReference(ResourceReference reference, 
String id);
+
+   /**
+* Writes a javascript reference, if the specified reference hasn't 
been rendered yet.
+* 
 * @param url
 *url of the the javascript resource
 */
public void renderJavascriptReference(String url);
+
+   /**
+* Writes a javascript reference, if the specified reference hasn't 
been rendered yet.
+* 
+* @param url
+*url of the the javascript resource
+* @param id
+*id that will be used to filter duplicate reference (it's 
still filtered by URL
+*too)
+*/
+   public vo

[jira] Commented: (WICKET-771) Provide ResourceReference with ID attribute for filtering multiple includes

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-771:


I don't mind filtering the reference by ID, but that would mean adding another 
2 or even 4 methods to IHeaderResponse :-(. That would be little bit bloated.

> Provide ResourceReference with ID attribute for filtering multiple includes
> ---
>
> Key: WICKET-771
> URL: https://issues.apache.org/jira/browse/WICKET-771
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 1.3.0-beta1, 1.3.0-beta2
>Reporter: Jim McLaughlin
> Fix For: 1.3.0-beta4
>
>
> Provide ResourceReference with an ID attribute that can be used to reduce 
> multiple inclusions. This will allow different projects to include the same 
> resources without worrying about double includes (if they agree to use the 
> same id) even if the resources have different urls.

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



[jira] Resolved: (WICKET-707) Invoking a request listener on a page returns an Expired Error page

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-707.


Resolution: Fixed

> Invoking a request listener on a page returns an Expired Error page
> ---
>
> Key: WICKET-707
> URL: https://issues.apache.org/jira/browse/WICKET-707
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.2.6
>Reporter: paolo di tommaso
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.3.0-beta4
>
>
> The Page object being a Component should support the Wicket request listener 
> mechanism. 
> But invoking a request listener on page defined listener object it results in 
> a "Page Expired" error page. 
> To reproduce it  try the following code:
> public interface IHelloListener extends IRequestListener
> {
> public static final RequestListenerInterface INTERFACE = new 
> RequestListenerInterface(IHelloListener.class);
> void onHello();
> }
> public class HelloWorld extends WebPage implements IHelloListener
> {
> public HelloWorld()
> {
> add(new Label("message", "Hello World!"));
> WebMarkupContainer link = new WebMarkupContainer("link");
> link.add(new SimpleAttributeModifier("href", 
> RequestCycle.get().urlFor(this, IHelloListener.INTERFACE)));
> add(link);
> }
> public void onHello()
> {
> RequestCycle.get().setRequestTarget(new IRequestTarget()
> {
> public void detach(RequestCycle requestCycle)
> {
> }
> public void respond(RequestCycle requestCycle)
> {
> 
> requestCycle.getResponse().write("HELLO!");
> }
> 
> public Object getLock(RequestCycle requestCycle) {
> return null;
> }
> });
> }
> }

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



[jira] Issue Comment Edited: (WICKET-707) Invoking a request listener on a page returns an Expired Error page

2007-09-01 Thread Matej Knopp (JIRA)

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

knopp edited comment on WICKET-707 at 9/1/07 2:52 PM:


I think valid solution to this is to remove the stateless flag when it's true. 
So when user/urlFor specifically request statefull page we honor that. 

  was (Author: knopp):
I think valid solution to this is to remove the stateless flag when it's 
true. So when user specifically request statefull page we honor that.
  
> Invoking a request listener on a page returns an Expired Error page
> ---
>
> Key: WICKET-707
> URL: https://issues.apache.org/jira/browse/WICKET-707
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.2.6
>Reporter: paolo di tommaso
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.3.0-beta4
>
>
> The Page object being a Component should support the Wicket request listener 
> mechanism. 
> But invoking a request listener on page defined listener object it results in 
> a "Page Expired" error page. 
> To reproduce it  try the following code:
> public interface IHelloListener extends IRequestListener
> {
> public static final RequestListenerInterface INTERFACE = new 
> RequestListenerInterface(IHelloListener.class);
> void onHello();
> }
> public class HelloWorld extends WebPage implements IHelloListener
> {
> public HelloWorld()
> {
> add(new Label("message", "Hello World!"));
> WebMarkupContainer link = new WebMarkupContainer("link");
> link.add(new SimpleAttributeModifier("href", 
> RequestCycle.get().urlFor(this, IHelloListener.INTERFACE)));
> add(link);
> }
> public void onHello()
> {
> RequestCycle.get().setRequestTarget(new IRequestTarget()
> {
> public void detach(RequestCycle requestCycle)
> {
> }
> public void respond(RequestCycle requestCycle)
> {
> 
> requestCycle.getResponse().write("HELLO!");
> }
> 
> public Object getLock(RequestCycle requestCycle) {
> return null;
> }
> });
> }
> }

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



[jira] Commented: (WICKET-707) Invoking a request listener on a page returns an Expired Error page

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-707:


I think valid solution to this is to remove the stateless flag when it's true. 
So when user specifically request statefull page we honor that.

> Invoking a request listener on a page returns an Expired Error page
> ---
>
> Key: WICKET-707
> URL: https://issues.apache.org/jira/browse/WICKET-707
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.2.6
>Reporter: paolo di tommaso
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.3.0-beta4
>
>
> The Page object being a Component should support the Wicket request listener 
> mechanism. 
> But invoking a request listener on page defined listener object it results in 
> a "Page Expired" error page. 
> To reproduce it  try the following code:
> public interface IHelloListener extends IRequestListener
> {
> public static final RequestListenerInterface INTERFACE = new 
> RequestListenerInterface(IHelloListener.class);
> void onHello();
> }
> public class HelloWorld extends WebPage implements IHelloListener
> {
> public HelloWorld()
> {
> add(new Label("message", "Hello World!"));
> WebMarkupContainer link = new WebMarkupContainer("link");
> link.add(new SimpleAttributeModifier("href", 
> RequestCycle.get().urlFor(this, IHelloListener.INTERFACE)));
> add(link);
> }
> public void onHello()
> {
> RequestCycle.get().setRequestTarget(new IRequestTarget()
> {
> public void detach(RequestCycle requestCycle)
> {
> }
> public void respond(RequestCycle requestCycle)
> {
> 
> requestCycle.getResponse().write("HELLO!");
> }
> 
> public Object getLock(RequestCycle requestCycle) {
> return null;
> }
> });
> }
> }

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



svn commit: r571882 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Page.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 14:50:58 2007
New Revision: 571882

URL: http://svn.apache.org/viewvc?rev=571882&view=rev
Log:
WICKET-707

Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Page.java

Modified: wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Page.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Page.java?rev=571882&r1=571881&r2=571882&view=diff
==
--- wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Page.java 
(original)
+++ wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Page.java Sat 
Sep  1 14:50:58 2007
@@ -828,8 +828,11 @@
// Make sure it is really empty
renderedComponents = null;
 
-   // Reset it to stateless so that it can be tested again
-   stateless = null;
+   // if the page is stateless, reset the flag so that it is 
tested again
+   if (Boolean.TRUE.equals(stateless))
+   {
+   stateless = null;
+   }
 
// Set form component values from cookies
setFormComponentValuesFromCookies();




[jira] Resolved: (WICKET-480) IHeaderResponse.renderOnUnLoadJavascript(String javascript);

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-480.


Resolution: Fixed

public void renderOnEventJavacript(String target, String event, String 
javascript);

> IHeaderResponse.renderOnUnLoadJavascript(String javascript);
> 
>
> Key: WICKET-480
> URL: https://issues.apache.org/jira/browse/WICKET-480
> Project: Wicket
>  Issue Type: New Feature
>  Components: wicket
>Affects Versions: 1.3.0-beta1
>Reporter: Martin Funk
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.3.0-beta4
>
> Attachments: diff.txt
>
>
> Where there is a renderOnLoadJavascript there ought to be a 
> renderOnUnLoadJavascript too.
> This is all just copy past, so it's a little smelly.
> Beyond that I wouldn't mind to be able to specify which element an event 
> should be added.
> Index: 
> wicket/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java
> ===
> --- 
> wicket/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java
>  (Revision 529942)
> +++ 
> wicket/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java
>  (Arbeitskopie)
> @@ -197,4 +197,19 @@
> }
> }
>  
> +   /**
> +* @see 
> org.apache.wicket.markup.html.IHeaderResponse#renderOnUnLoadJavascript(java.lang.String)
> +*/
> +   public void renderOnUnLoadJavascript(String javascript)
> +   {
> +   List token = Arrays.asList(new Object[] { "javascript-event", 
> "unload", javascript });
> +   if (wasRendered(token) == false)
> +   {
> +   
> renderJavascriptReference(WicketEventReference.INSTANCE);
> +   JavascriptUtils.writeJavascript(getResponse(),
> +   "Wicket.Event.add(window, \"unload\", 
> function() { " + javascript + ";});");
> +   markRendered(token);
> +   }
> +   }
> +
>  }
> Index: wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java
> ===
> --- wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java   
>   (Revision 529942)
> +++ wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java   
>   (Arbeitskopie)
> @@ -174,4 +174,11 @@
>  * @param javascript
>  */
> public void renderOnLoadJavascript(String javascript);
> +
> +   /**
> +* Renders javascript that is executed after the page is unloaded.
> +* 
> +* @param javascript
> +*/
> +   public void renderOnUnLoadJavascript(String javascript);
>  }

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



svn commit: r571877 - in /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket: ajax/AjaxRequestTarget.java markup/html/IHeaderResponse.java markup/html/internal/HeaderResponse.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 14:39:26 2007
New Revision: 571877

URL: http://svn.apache.org/viewvc?rev=571877&view=rev
Log:
WICKET-480

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java?rev=571877&r1=571876&r2=571877&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
 Sat Sep  1 14:39:26 2007
@@ -829,7 +829,8 @@
 
public void renderOnDomReadyJavascript(String javascript)
{
-   List token = Arrays.asList(new Object[] { 
"javascript-event", "domready", javascript });
+   List token = Arrays.asList(new Object[] { 
"javascript-event", "window", "domready",
+   javascript });
if (wasRendered(token) == false)
{
domReadyJavascripts.add(javascript);
@@ -839,7 +840,8 @@
 
public void renderOnLoadJavascript(String javascript)
{
-   List token = Arrays.asList(new Object[] { 
"javascript-event", "load", javascript });
+   List token = Arrays.asList(new Object[] { 
"javascript-event", "window", "load",
+   javascript });
if (wasRendered(token) == false)
{
// execute the javascript after all other 
scripts are executed

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java?rev=571877&r1=571876&r2=571877&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/IHeaderResponse.java
 Sat Sep  1 14:39:26 2007
@@ -20,20 +20,17 @@
 import org.apache.wicket.Response;
 
 /**
- * Interface that is used to render header elements (usually javascript and CSS
- * references).
+ * Interface that is used to render header elements (usually javascript and 
CSS references).
  * 
- * Implementation of this interface is responsible for filtering duplicate
- * contributions (so that for example the same javascript is not loaded twice)
- * during the same request.
+ * Implementation of this interface is responsible for filtering duplicate 
contributions (so that
+ * for example the same javascript is not loaded twice) during the same 
request.
  * 
  * @author Matej Knopp
  */
 public interface IHeaderResponse
 {
/**
-* Writes a javascript reference, if the specified reference hasn't been
-* rendered yet.
+* Writes a javascript reference, if the specified reference hasn't 
been rendered yet.
 * 
 * @param reference
 *resource reference pointing to the javascript resource
@@ -41,8 +38,7 @@
public void renderJavascriptReference(ResourceReference reference);
 
/**
-* Writes a javascript reference, if the specified reference hasn't been
-* rendered yet.
+* Writes a javascript reference, if the specified reference hasn't 
been rendered yet.
 * 
 * @param url
 *url of the the javascript resource
@@ -50,25 +46,21 @@
public void renderJavascriptReference(String url);
 
/**
-* Renders javascript code to the response, if the javascript has not
-* already been rendered.
+* Renders javascript code to the response, if the javascript has not 
already been rendered.
 * 
-* the necessary surrounding script tags will be added to 
the
-* output.
+* the necessary surrounding script tags will be added to 
the output.
 * 
 * @param javascript
 *javacript content to be rendered.
 * 
 * @param id
-*unique id for the javascript element. This can be null,
-*however in that case the ajax header contribution can't 
detect
-*duplicate script fragments.
+*unique id f

[jira] Commented: (WICKET-796) setresponsepage() does not properly redirect from ajax requests

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-796:


I've fixed this by disabling redirect to buffer for AJAX request (as it break 
everything, since the URL is wrong)

> setresponsepage() does not properly redirect from ajax requests
> ---
>
> Key: WICKET-796
> URL: https://issues.apache.org/jira/browse/WICKET-796
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta1, 1.3.0-beta2
>Reporter: Igor Vaynberg
>Assignee: Eelco Hillenius
> Fix For: 1.3.0-beta4
>
>
> if you are on a mounted page with parameters, lets say
> /context/page/param1/param2/
> and you call setresponsepage() from an NORMAL link on that page you will land 
> on
> /context/?wicket:interface=...
> which is correct, however if you do it from an ajax link like so: 
> onclick(ajaxrequesttarget target) { setresponsepage(new mypage()); } you will 
> land on 
> /context/page/param1/param2/?wicket:interface=...
> which is INCORRECTl. notice that the mount and params were not stripped. also 
> now because wicket thinks url depth is 0 urls will break, for example a 
> resource requested from that page will be:
> /context/page/param1/param2/resources/. woopsie
> why this happens:
> when setresponsepage is called the ?wicket:interface:foo::: url is 
> constructed and passed to webresponse.redirect(url) which in turn calls 
> httpServletResponse.sendRedirect(url); for normal responses or 
> httpServletResponse.addHeader("Ajax-Location", url); for ajax responses. the 
> big difference is how servletresponse handles this, and from the javadoc: 
> This method can accept relative URLs; the servlet container will convert the 
> relative URL to an absolute URL before sending the response to the client. 
> so what needs to be done is that 
> httpServletResponse.addHeader("Ajax-Location", url); also needs to mangle the 
> url and make it absolute.
> since you are the proxy guy and i dont know how this will play into that i am 
> assigning it to you

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



svn commit: r571871 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebRequestCycle.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 14:19:46 2007
New Revision: 571871

URL: http://svn.apache.org/viewvc?rev=571871&view=rev
Log:
WICKET-796

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebRequestCycle.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebRequestCycle.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebRequestCycle.java?rev=571871&r1=571870&r2=571871&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebRequestCycle.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WebRequestCycle.java
 Sat Sep  1 14:19:46 2007
@@ -131,7 +131,7 @@
// Check if use serverside response for client side redirects
IRequestCycleSettings settings = 
application.getRequestCycleSettings();
if ((settings.getRenderStrategy() == 
IRequestCycleSettings.REDIRECT_TO_BUFFER) &&
-   (application instanceof WebApplication))
+   (application instanceof WebApplication) && 
!(getWebRequest().isAjax()))
{
// remember the current response
final WebResponse currentResponse = getWebResponse();




[jira] Updated: (WICKET-917) Minor patch in polish translation

2007-09-01 Thread Dariusz Wojtas (JIRA)

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

Dariusz Wojtas updated WICKET-917:
--

Attachment: pl_patch.diff

> Minor patch in polish translation
> -
>
> Key: WICKET-917
> URL: https://issues.apache.org/jira/browse/WICKET-917
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 1.3.0-beta3
>Reporter: Dariusz Wojtas
>Priority: Trivial
> Attachments: pl_patch.diff
>
>
> The current PL translation is nice, just minor change to null value to give 
> it universal meaning in some cases

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



[jira] Created: (WICKET-917) Minor patch in polish translation

2007-09-01 Thread Dariusz Wojtas (JIRA)
Minor patch in polish translation
-

 Key: WICKET-917
 URL: https://issues.apache.org/jira/browse/WICKET-917
 Project: Wicket
  Issue Type: Improvement
  Components: wicket
Affects Versions: 1.3.0-beta3
Reporter: Dariusz Wojtas
Priority: Trivial
 Attachments: pl_patch.diff

The current PL translation is nice, just minor change to null value to give it 
universal meaning in some cases

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



[jira] Commented: (WICKET-824) Session id encoding problem in cookie-less mode

2007-09-01 Thread Eelco Hillenius (JIRA)

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

Eelco Hillenius commented on WICKET-824:


Yeah, I've been testing without cookies like crazy, and never ran into this. 
But I haven't tested this particular method.

> Session id encoding problem in cookie-less mode
> ---
>
> Key: WICKET-824
> URL: https://issues.apache.org/jira/browse/WICKET-824
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
> Environment: Tomcat 5.5.23, OS X
>Reporter: Roland Foerther
>Assignee: Alastair Maw
>Priority: Critical
> Fix For: 1.3.0-beta4
>
>
> If I disable session cookies, the URL-encoding does not work. The problem 
> appears in displaying 'page expired' when I click through 'wicket-exmples' . 
> I discovered that HttpServletResponse.encodeUrl() called by 
> WebRequestCodingStrategy.encode() does not encode the session id, if it is 
> called with a relative URL like 
> `?wicket:interface=:0:inputForm:IFormSubmitListener::'. i.e.. starting with 
> '?'.   

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



[jira] Commented: (WICKET-796) setresponsepage() does not properly redirect from ajax requests

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-796:


Okay, this still doesn't work.
If you are on mounted page with parameters, such as /links/param/value
then the redirect works, but all resources on rendered page are prepended by 
way too much ../

> setresponsepage() does not properly redirect from ajax requests
> ---
>
> Key: WICKET-796
> URL: https://issues.apache.org/jira/browse/WICKET-796
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta1, 1.3.0-beta2
>Reporter: Igor Vaynberg
>Assignee: Eelco Hillenius
> Fix For: 1.3.0-beta4
>
>
> if you are on a mounted page with parameters, lets say
> /context/page/param1/param2/
> and you call setresponsepage() from an NORMAL link on that page you will land 
> on
> /context/?wicket:interface=...
> which is correct, however if you do it from an ajax link like so: 
> onclick(ajaxrequesttarget target) { setresponsepage(new mypage()); } you will 
> land on 
> /context/page/param1/param2/?wicket:interface=...
> which is INCORRECTl. notice that the mount and params were not stripped. also 
> now because wicket thinks url depth is 0 urls will break, for example a 
> resource requested from that page will be:
> /context/page/param1/param2/resources/. woopsie
> why this happens:
> when setresponsepage is called the ?wicket:interface:foo::: url is 
> constructed and passed to webresponse.redirect(url) which in turn calls 
> httpServletResponse.sendRedirect(url); for normal responses or 
> httpServletResponse.addHeader("Ajax-Location", url); for ajax responses. the 
> big difference is how servletresponse handles this, and from the javadoc: 
> This method can accept relative URLs; the servlet container will convert the 
> relative URL to an absolute URL before sending the response to the client. 
> so what needs to be done is that 
> httpServletResponse.addHeader("Ajax-Location", url); also needs to mangle the 
> url and make it absolute.
> since you are the proxy guy and i dont know how this will play into that i am 
> assigning it to you

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



[jira] Updated: (WICKET-796) setresponsepage() does not properly redirect from ajax requests

2007-09-01 Thread Eelco Hillenius (JIRA)

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

Eelco Hillenius updated WICKET-796:
---

Priority: Major  (was: Critical)

I still have to check it. I don't think it's critical as it's not a very common 
use case.

> setresponsepage() does not properly redirect from ajax requests
> ---
>
> Key: WICKET-796
> URL: https://issues.apache.org/jira/browse/WICKET-796
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta1, 1.3.0-beta2
>Reporter: Igor Vaynberg
>Assignee: Eelco Hillenius
> Fix For: 1.3.0-beta4
>
>
> if you are on a mounted page with parameters, lets say
> /context/page/param1/param2/
> and you call setresponsepage() from an NORMAL link on that page you will land 
> on
> /context/?wicket:interface=...
> which is correct, however if you do it from an ajax link like so: 
> onclick(ajaxrequesttarget target) { setresponsepage(new mypage()); } you will 
> land on 
> /context/page/param1/param2/?wicket:interface=...
> which is INCORRECTl. notice that the mount and params were not stripped. also 
> now because wicket thinks url depth is 0 urls will break, for example a 
> resource requested from that page will be:
> /context/page/param1/param2/resources/. woopsie
> why this happens:
> when setresponsepage is called the ?wicket:interface:foo::: url is 
> constructed and passed to webresponse.redirect(url) which in turn calls 
> httpServletResponse.sendRedirect(url); for normal responses or 
> httpServletResponse.addHeader("Ajax-Location", url); for ajax responses. the 
> big difference is how servletresponse handles this, and from the javadoc: 
> This method can accept relative URLs; the servlet container will convert the 
> relative URL to an absolute URL before sending the response to the client. 
> so what needs to be done is that 
> httpServletResponse.addHeader("Ajax-Location", url); also needs to mangle the 
> url and make it absolute.
> since you are the proxy guy and i dont know how this will play into that i am 
> assigning it to you

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



[jira] Commented: (WICKET-824) Session id encoding problem in cookie-less mode

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-824:


Now that's really weird. Just clicking through wicket examples and all works 
well without cookies. (But on jetty, not tomcat though)

> Session id encoding problem in cookie-less mode
> ---
>
> Key: WICKET-824
> URL: https://issues.apache.org/jira/browse/WICKET-824
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
> Environment: Tomcat 5.5.23, OS X
>Reporter: Roland Foerther
>Assignee: Alastair Maw
>Priority: Critical
> Fix For: 1.3.0-beta4
>
>
> If I disable session cookies, the URL-encoding does not work. The problem 
> appears in displaying 'page expired' when I click through 'wicket-exmples' . 
> I discovered that HttpServletResponse.encodeUrl() called by 
> WebRequestCodingStrategy.encode() does not encode the session id, if it is 
> called with a relative URL like 
> `?wicket:interface=:0:inputForm:IFormSubmitListener::'. i.e.. starting with 
> '?'.   

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



[jira] Resolved: (WICKET-915) Next button not being enabled/disabled in Wizard when programitically calling setEnabled

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-915.


Resolution: Invalid

> Next button not being enabled/disabled in Wizard when programitically calling 
> setEnabled
> 
>
> Key: WICKET-915
> URL: https://issues.apache.org/jira/browse/WICKET-915
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
>Reporter: Doug Leeper
>Assignee: Eelco Hillenius
> Attachments: wicketTest-src.jar
>
>
> When I create a WizardStep, I automatically call setComplete( false ).
> When the user performs the necessary option (selects an item), I call 
> setComplete( true ).
> However, the Next button is disabled even though I called setComplete( true ).
> Actually, I found out that once you call setComplete( false ) or if 
> isComplete() returns false, the Next button will never become disabled. 
> Note: this behavior only is exhibited in the attached example.  A pared down 
> example (not attached) preforms as expected, i.e. a button has a link that 
> toggles complete for the step

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



[jira] Commented: (WICKET-915) Next button not being enabled/disabled in Wizard when programitically calling setEnabled

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-915:


Hi,

this is not really a bug. Problem is, that selecting a tree node is made during 
AjaxRequest. And you haven't specified which components should be refreshed - 
thus the button is not refreshed. Unfortunately, there is no nice solution for 
this, the best you can do is to call 

getRequestCycle().setResponsePage(getPage());

after 

setComplete(currentC != null);

alternatively, you can add individual components to AjaxRequestTarget but 
that's a bit more tricky.

> Next button not being enabled/disabled in Wizard when programitically calling 
> setEnabled
> 
>
> Key: WICKET-915
> URL: https://issues.apache.org/jira/browse/WICKET-915
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
>Reporter: Doug Leeper
>Assignee: Eelco Hillenius
> Attachments: wicketTest-src.jar
>
>
> When I create a WizardStep, I automatically call setComplete( false ).
> When the user performs the necessary option (selects an item), I call 
> setComplete( true ).
> However, the Next button is disabled even though I called setComplete( true ).
> Actually, I found out that once you call setComplete( false ) or if 
> isComplete() returns false, the Next button will never become disabled. 
> Note: this behavior only is exhibited in the attached example.  A pared down 
> example (not attached) preforms as expected, i.e. a button has a link that 
> toggles complete for the step

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



[jira] Resolved: (WICKET-912) shink of resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js // general JS in wicket // JS loading by loaderclass

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-912.


Resolution: Won't Fix

> shink of 
> resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js 
> // general JS in wicket // JS loading by loaderclass
> -
>
> Key: WICKET-912
> URL: https://issues.apache.org/jira/browse/WICKET-912
> Project: Wicket
>  Issue Type: Improvement
>Affects Versions: 1.3.0-beta1, 1.3.0-beta2, 1.3.0-beta3
> Environment: general all wicket 1.3+
>Reporter: Korbinian Bachl
>
> Currently, when using basic ajax, a JS resource like 
> "resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js" 
> is included in head and called - this should short and/ or be replaced by 
> fewer JS calls.
> An aproach like the one the YUI team made would be much nicer in regards to 
> header-size and downloaddata. So i would recommend to have wicket taken the 
> same way as YUI and instead of adding several JS paths to the header only 1 
> loader class and this class then could feed the rest (same as for YUI in 
> 2.3.0 now).

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



[jira] Commented: (WICKET-912) shink of resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js // general JS in wicket // JS loading by loaderclass

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-912:


And what would be the benefit of this? What's the difference between rendering 
multiple references or having one reference and load the other using 
XmlHttpRequest. Actually, this approach is even more expensive. Also by 
default, there is only one javascript file - wicket-ajax.js, unless you are in 
development mode, but in development mode it doesn't matter.

Such approach might make sense for Javascript only toolkits, such as YUI, but 
it's not really justified for web framework like wicket.

> shink of 
> resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js 
> // general JS in wicket // JS loading by loaderclass
> -
>
> Key: WICKET-912
> URL: https://issues.apache.org/jira/browse/WICKET-912
> Project: Wicket
>  Issue Type: Improvement
>Affects Versions: 1.3.0-beta1, 1.3.0-beta2, 1.3.0-beta3
> Environment: general all wicket 1.3+
>Reporter: Korbinian Bachl
>
> Currently, when using basic ajax, a JS resource like 
> "resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax.js" 
> is included in head and called - this should short and/ or be replaced by 
> fewer JS calls.
> An aproach like the one the YUI team made would be much nicer in regards to 
> header-size and downloaddata. So i would recommend to have wicket taken the 
> same way as YUI and instead of adding several JS paths to the header only 1 
> loader class and this class then could feed the rest (same as for YUI in 
> 2.3.0 now).

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



[jira] Assigned: (WICKET-877) stateless page + form + bookmark = trouble

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp reassigned WICKET-877:
--

Assignee: Johan Compagner

> stateless page + form + bookmark = trouble
> --
>
> Key: WICKET-877
> URL: https://issues.apache.org/jira/browse/WICKET-877
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Reporter: Peter Ertl
>Assignee: Johan Compagner
>
> I have a stateless login page for the application (using 
> HybridUrlCodingStrategy):
>url_1 = http://localhost/login
> When I press the login button of the username + password form the form data 
> will be sent using HTTP POST:
>   url_2 = 
> http://localhost/login/wicket:interface/%3A0%3AnavigationContrib%3Aform%3A%3AIFormSubmitListener%3A%3A/
> Unfortunately, if somebody bookmarks url_2 (which is stupid as we java dudes 
> all know, but it _will_ happen because average users don't know better) the 
> form submit listener will be invoked using HTTP GET and having no form 
> parameters. *imho* bookmarks should be possible in a professional application 
> at all time.
> This, of course, will result in an ugly error message and unexpected 
> application behavior and empty form fields and stuff. That's *btw* why I 
> declare this request a bug and not a feature / enhancement.
> I think it would be cool to have Form#onInvalidSubmit() to handle this kind 
> of stuff (it won't happen on stateful pages with redirect after post 
> enabled). So, for example, the application could just reload to the login 
> page.
> detection is easy... here my suggestion:
> --
> class org.apache.wicket.markup.html.form.Form:
> public final void onFormSubmitted()  // line 746
> {
> final String method = ((WebRequest) 
> getRequest()).getHttpServletRequest().getMethod();
> if (method.equalsIgnoreCase(this.getMethod()) == false)
>   this.onInvalidSubmit();
> // ...
> }
> // override (optional)
> protected onInvalidSubmit() {}
> --
> in my case I would just do this:
> @Override
> protected onInvalidSubmit()
> {
>   this.setRedirect(true);
>   throw new RestartResponseException(getPage().getClass());
> }
> This would probably be a good default behavior for StatelessForm
> I consider this change useful enough to be part of wicket core.
> What you guys think?

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



[jira] Commented: (WICKET-775) Buggy behaviour in FormComponentPanel.setRequired(boolean)

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-775:


What do we do about it?

> Buggy behaviour in FormComponentPanel.setRequired(boolean)
> --
>
> Key: WICKET-775
> URL: https://issues.apache.org/jira/browse/WICKET-775
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
>Reporter: Kadir Sener GUMUS
> Fix For: 1.3.0-beta4
>
>
> When you set a required flag for a FormComponentPanel in a form,  the 
> component does not check its children while validating if it is required or 
> not, and throws "required" exception!  Because "checkRequired()" method that 
> inherited from FormComponent calls "getInput()", then that method calls 
> "getInputAsArray()", and then the last called method "getInputAsArray" looks 
> for values from the http request parameters with the formComponentPanel name. 
> Hence there is no any parameter in request with the formComponentPanel name, 
> it thinks itself as empty and throws the validation error.  IMHO, 
> FormComponentPanel class should override "checkRequired()" method or 
> "getInput()" method to delegate work to its children components.

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



[jira] Updated: (WICKET-775) Buggy behaviour in FormComponentPanel.setRequired(boolean)

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp updated WICKET-775:
---

Fix Version/s: 1.3.0-beta4

> Buggy behaviour in FormComponentPanel.setRequired(boolean)
> --
>
> Key: WICKET-775
> URL: https://issues.apache.org/jira/browse/WICKET-775
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
>Reporter: Kadir Sener GUMUS
> Fix For: 1.3.0-beta4
>
>
> When you set a required flag for a FormComponentPanel in a form,  the 
> component does not check its children while validating if it is required or 
> not, and throws "required" exception!  Because "checkRequired()" method that 
> inherited from FormComponent calls "getInput()", then that method calls 
> "getInputAsArray()", and then the last called method "getInputAsArray" looks 
> for values from the http request parameters with the formComponentPanel name. 
> Hence there is no any parameter in request with the formComponentPanel name, 
> it thinks itself as empty and throws the validation error.  IMHO, 
> FormComponentPanel class should override "checkRequired()" method or 
> "getInput()" method to delegate work to its children components.

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



[jira] Resolved: (WICKET-869) Back button processing doesn't work in Opera

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-869.


   Resolution: Cannot Reproduce
Fix Version/s: 1.3.0-beta4

Can not reproduce with current trunk and opera 9.23. That means it's probably 
fixed already

> Back button processing doesn't work in Opera
> 
>
> Key: WICKET-869
> URL: https://issues.apache.org/jira/browse/WICKET-869
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
>Reporter: Andrew Klochkov
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: wicket-quickstart.tar.gz
>
>
> Use case:
> 1) user loads page A
> 2) he goes to page B
> 3) he hits back button
> 4) he clicks an ajax link on the page A, but wicket thinks that page B is 
> current
>page because Opera doesn't make any request when back button is presssed
> Opera 9.01
> wicket 1.3 beta 2
> It's happenning when pages extends base class with the following constructors:
> public class MyPage extends WebPage
> {
>   public MyPage() {
>   this(null);
>   }
>   public MyPage(PageParameters params)
>   {
>   super(params);
>   }
>   
> }
> In this case Page.init(final IPageMap pageMap) is never called and 
> Page.numericId contains zero for every page instance. 
> Quickstart is attached.

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



[jira] Assigned: (WICKET-869) Back button processing doesn't work in Opera

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp reassigned WICKET-869:
--

Assignee: Matej Knopp

> Back button processing doesn't work in Opera
> 
>
> Key: WICKET-869
> URL: https://issues.apache.org/jira/browse/WICKET-869
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
>Reporter: Andrew Klochkov
>Assignee: Matej Knopp
> Attachments: wicket-quickstart.tar.gz
>
>
> Use case:
> 1) user loads page A
> 2) he goes to page B
> 3) he hits back button
> 4) he clicks an ajax link on the page A, but wicket thinks that page B is 
> current
>page because Opera doesn't make any request when back button is presssed
> Opera 9.01
> wicket 1.3 beta 2
> It's happenning when pages extends base class with the following constructors:
> public class MyPage extends WebPage
> {
>   public MyPage() {
>   this(null);
>   }
>   public MyPage(PageParameters params)
>   {
>   super(params);
>   }
>   
> }
> In this case Page.init(final IPageMap pageMap) is never called and 
> Page.numericId contains zero for every page instance. 
> Quickstart is attached.

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



[jira] Resolved: (WICKET-889) Automatic multi-window support drops URL fragment identifier

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-889.


Resolution: Fixed

> Automatic multi-window support drops URL fragment identifier
> 
>
> Key: WICKET-889
> URL: https://issues.apache.org/jira/browse/WICKET-889
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.2.6
>Reporter: Nick Johnson
>
> If a bookmarkable link contains a fragment identifier (e.g. #foo) and 
> automatic multi-window support is enabled, if that URL is opened in a new 
> window or new tab, the fragment identifier is dropped.
> For example, shift-clicking on this URL in Firefox to open it in a new 
> window, or right clicking it and opening it in a new tab:
> http://beta.morons.org/tally-ho/article/read/7613/findMsg%3D159236#159236
> Results in a redirect in the new tab/window to this URL:
> 
> http://beta.morons.org/tally-ho/article/read/7613/findMsg%3D159236/wicket:pageMapName/wicket-0
> The redirection is expected, but losing the fragment identifier (#159236) is 
> not.  The redirect should have been to:
> 
> http://beta.morons.org/tally-ho/article/read/7613/findMsg%3D159236/wicket:pageMapName/wicket-0#159236
> (It may be relevant that in this case the fragment identifier was added using 
> a Behavior attached to the BookmarkableLink.)
> The workaround is to turn off automatic multi-window support.

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



[jira] Updated: (WICKET-889) Automatic multi-window support drops URL fragment identifier

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp updated WICKET-889:
---

Fix Version/s: 1.3.0-beta4

> Automatic multi-window support drops URL fragment identifier
> 
>
> Key: WICKET-889
> URL: https://issues.apache.org/jira/browse/WICKET-889
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.2.6
>Reporter: Nick Johnson
> Fix For: 1.3.0-beta4
>
>
> If a bookmarkable link contains a fragment identifier (e.g. #foo) and 
> automatic multi-window support is enabled, if that URL is opened in a new 
> window or new tab, the fragment identifier is dropped.
> For example, shift-clicking on this URL in Firefox to open it in a new 
> window, or right clicking it and opening it in a new tab:
> http://beta.morons.org/tally-ho/article/read/7613/findMsg%3D159236#159236
> Results in a redirect in the new tab/window to this URL:
> 
> http://beta.morons.org/tally-ho/article/read/7613/findMsg%3D159236/wicket:pageMapName/wicket-0
> The redirection is expected, but losing the fragment identifier (#159236) is 
> not.  The redirect should have been to:
> 
> http://beta.morons.org/tally-ho/article/read/7613/findMsg%3D159236/wicket:pageMapName/wicket-0#159236
> (It may be relevant that in this case the fragment identifier was added using 
> a Behavior attached to the BookmarkableLink.)
> The workaround is to turn off automatic multi-window support.

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



[jira] Resolved: (WICKET-794) PagingNavigationLink leaves long URL

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-794.


Resolution: Fixed

> PagingNavigationLink leaves long URL
> 
>
> Key: WICKET-794
> URL: https://issues.apache.org/jira/browse/WICKET-794
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
> Environment: Tomcat 5.5
>Reporter: Thomas Mäder
>
> 1) I have a DefaultDataTable which shows a Number of Pages
> 2) I click on the navigation link for the second page ("2")
> 3) I end up with a link like this:
> http://localhost:8080/ffpro_web2/?wicket:interface=:0:wizard:form:view:instrumentSelection:searchResult:topToolbars:1:toolbar:span:navigator:navigation:1:pageLink::ILinkListener::
> I would expect to end up on a new version of the previous page url.
> The problem seems to be that PagingNavigationLink.onClick() does a 
> setRedirect(false).
> Similar actions like sorting seem to redirect to a different version of the 
> same page.

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



[jira] Commented: (WICKET-908) There is no way to specify what exceptions to log in RequestCycle

2007-09-01 Thread Marat Radchenko (JIRA)

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

Marat Radchenko commented on WICKET-908:


Oh, sorry. I didn't think about overriding logRuntimeException

> There is no way to specify what exceptions to log in RequestCycle
> -
>
> Key: WICKET-908
> URL: https://issues.apache.org/jira/browse/WICKET-908
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta3
>Reporter: Marat Radchenko
>Assignee: Juergen Donnerstag
>Priority: Critical
> Fix For: 1.3.0-beta4
>
>
> RequestCycle, line 1135 logs all exceptions except for PageExpiredException. 
> This is not a wanted behavior for us (for example, it also logs 
> AuthorizationException which is not a error).
> So we need some way to specify which exceptions should be treated as errors 
> and which ones are just need to be handled by 
> RequestCycleProcessor#respond(RuntimeException, RequestCycle).
> Maybe there is some way to globally catch application exceptions other than 
> writing a custom RequestCycleProcessor. If so then tell me please.
> The possible solution is to move exception logging to 
> RequestCycleProcessor#respond(RuntimeException, RequestCycle) because it can 
> be overriden.

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



svn commit: r571841 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/FeedbackPanel.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 10:46:45 2007
New Revision: 571841

URL: http://svn.apache.org/viewvc?rev=571841&view=rev
Log:
WICKET-836

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/FeedbackPanel.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/FeedbackPanel.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/FeedbackPanel.java?rev=571841&r1=571840&r2=571841&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/FeedbackPanel.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/FeedbackPanel.java
 Sat Sep  1 10:46:45 2007
@@ -271,15 +271,6 @@
}
 
/**
-* @see org.apache.wicket.feedback.IFeedback#updateFeedback()
-*/
-   public void updateFeedback()
-   {
-   // Force model to load
-   // getFeedbackMessagesModel().preloadMessages();
-   }
-
-   /**
 * Gets the css class for the given message.
 * 
 * @param message




[jira] Commented: (WICKET-836) feedback panels not being updated when inside repeaters

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-836:


Okay. I've commited the code. I hope I haven't broken the world. Which wouldn't 
surprise me at all.

> feedback panels not being updated when inside repeaters
> ---
>
> Key: WICKET-836
> URL: https://issues.apache.org/jira/browse/WICKET-836
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2, 1.3.0-beta3
>Reporter: Carlos Pita
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: FeedbackPage.html, FeedbackPage.java
>
>
> see the attached example

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



svn commit: r571837 - in /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket: ./ ajax/ feedback/ markup/html/panel/ request/target/component/

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 10:42:51 2007
New Revision: 571837

URL: http://svn.apache.org/viewvc?rev=571837&view=rev
Log:
WICKET-836

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

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Page.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/FeedbackMessagesModel.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/feedback/IFeedback.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/FeedbackPanel.java

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/component/ComponentRequestTarget.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java?rev=571837&r1=571836&r2=571837&view=diff
==
--- wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java 
(original)
+++ wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java 
Sat Sep  1 10:42:51 2007
@@ -30,6 +30,7 @@
 import org.apache.wicket.authorization.UnauthorizedActionException;
 import org.apache.wicket.behavior.IBehavior;
 import org.apache.wicket.feedback.FeedbackMessage;
+import org.apache.wicket.feedback.IFeedback;
 import org.apache.wicket.markup.ComponentTag;
 import org.apache.wicket.markup.MarkupException;
 import org.apache.wicket.markup.MarkupStream;
@@ -792,11 +793,7 @@
internalAttach2();
}
 
-   /**
-* Called for every component when the page is getting to be rendered. 
it will call
-* onBeforeRender for this component and all the child components
-*/
-   public final void beforeRender()
+   private final void internalBeforeRender()
{
if (isVisible() && !getFlag(FLAG_RENDERING) && 
!getFlag(FLAG_PREPARED_FOR_RENDER))
{
@@ -815,6 +812,42 @@
}
 
/**
+* We need to postpone calling beforeRender() on components that 
implement IFeedback, to be sure
+* that all other component's beforeRender() has been already called, 
so that IFeedbacks can
+* collect all feedback messages. This is the key under list of 
postponed IFeedback is stored to
+* request cycle metadata. The List is then iterated over in [EMAIL 
PROTECTED] #prepareForRender()} after
+* calling [EMAIL PROTECTED] #beforeRender()}, to initialize postponed 
components.
+*/
+   private static final MetaDataKey FEEDBACK_LIST = new 
MetaDataKey(List.class)
+   {
+   private static final long serialVersionUID = 1L;
+   };
+
+   /**
+* Called for every component when the page is getting to be rendered. 
it will call
+* onBeforeRender for this component and all the child components
+*/
+   public final void beforeRender()
+   {
+   if (!(this instanceof IFeedback))
+   {
+   internalBeforeRender();
+   }
+   else
+   {
+   // this component is a feedback. Feedback must be 
initialized last, so that
+   // they can collect messages from other components
+   List feedbacks = 
(List)getRequestCycle().getMetaData(FEEDBACK_LIST);
+   if (feedbacks == null)
+   {
+   feedbacks = new ArrayList();
+   getRequestCycle().setMetaData(FEEDBACK_LIST, 
(Serializable)feedbacks);
+   }
+   feedbacks.add(this);
+   }
+   }
+
+   /**
 * Redirects to any intercept page previously specified by a call to 
redirectToInterceptPage.
 * 
 * @return True if an original destination was redirected to
@@ -1803,6 +1836,16 @@
public void prepareForRender()
{
beforeRender();
+   List feedbacks = 
(List)getRequestCycle().getMetaData(FEEDBACK_LIST);
+   if (feedbacks != null)
+   {
+   for (Iterator i = feedbacks.iterator(); i.hasNext();)
+   {
+   Component feedback = (Component)i.next();
+   feedback.internalBeforeRender();
+   }
+   }
+   getRequestCycle().setMetaData(FEEDBACK_LIST, null);
markRendering();
}
 
@@ -2020,8 +2063,7 @@
// Make sure that while rendering the markup 
stream is found

svn commit: r571834 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 10:35:41 2007
New Revision: 571834

URL: http://svn.apache.org/viewvc?rev=571834&view=rev
Log:
typo fix

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?rev=571834&r1=571833&r2=571834&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js 
(original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js 
Sat Sep  1 10:35:41 2007
@@ -826,7 +826,7 @@
Wicket.Log.error("Exception evaluating AJAX 
status: " + e);
status = "unavailable";
}
-   if (status == 200 || status == "") { // as stupid as it 
seems, IE7 sets satus to "" on ok
+   if (status == 200 || status == "") { // as stupid as it 
seems, IE7 sets status to "" on ok
// response came without error
var responseAsText = t.responseText;





svn commit: r571833 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 10:35:21 2007
New Revision: 571833

URL: http://svn.apache.org/viewvc?rev=571833&view=rev
Log:
precondition fixes and lazy form serialization on ajax form submission

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?rev=571833&r1=571832&r2=571833&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js 
(original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js 
Sat Sep  1 10:35:21 2007
@@ -53,12 +53,16 @@
 
 // returns if the element belongs to current document
 // if the argument is not element, function returns true
-Wicket.$$ = function(element) {
+Wicket.$$ = function(element) {
if (element == null || typeof(element) == "undefined" ||
-   element.tagName == null || typeof(element.tagName)) {
+   element.tagName == null || typeof(element.tagName) == "undefined") {
return true;
-   } 
-   return element.ownerDocument == document;
+   }
+   
+   if (typeof(element.id) == "undefined" || element.id == null)
+   return element.ownerDocument == document;
+   else
+   return document.getElementById(element.id) == element;
 }
 
 Wicket.emptyFunction = function() { };
@@ -778,6 +782,7 @@

// The actual post implementation
doPost: function(body) {
+   
if (this.precondition()) {
this.transport = Wicket.Ajax.getTransport();

@@ -788,6 +793,10 @@

var t = this.transport;
if (t != null) {
+   // we allow body to be a method - to lazily 
evaluate itself
+   if (typeof(body) == "function") {
+   body = body();
+   }   
t.open("POST", url, this.async);
t.onreadystatechange = 
this.stateChangeCallback.bind(this);
t.setRequestHeader("Content-Type", 
"application/x-www-form-urlencoded");
@@ -936,9 +945,12 @@
// Submits a form using ajax.
// This method serializes a form and sends it as POST body.
submitForm: function(form, submitButton) {
-   var body = Wicket.Form.serialize(form);
-   if (submitButton != null) {
-   body += Wicket.Form.encode(submitButton) + "=1";
+   var body = function() {
+   var s = Wicket.Form.serialize(form);
+   if (submitButton != null) {
+   s += Wicket.Form.encode(submitButton) + "=1";
+   }
+   return s;   
}
return this.request.post(body);
},
@@ -1671,7 +1683,7 @@
 function wicketAjaxPost(url, body, successHandler, failureHandler, 
precondition, channel) {
var call = new Wicket.Ajax.Call(url, successHandler, failureHandler, 
channel);

-   if (typeof(precondition) != "undefined" && precondition != null) {
+   if (typeof(precondition) != "undefined" && precondition != null) {  

call.request.precondition = precondition;
}

@@ -1854,4 +1866,3 @@
e.style.display = "none";
}
 }
-




[jira] Commented: (WICKET-836) feedback panels not being updated when inside repeaters

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-836:


Okay, so Johan finally reminded me what updateFeedback() is for. The good thing 
is, that since we store messages in session, we no longer need it.

it was meant to collect feedback messages from component that would be removed 
in onBeforeRender. Such as when there are textfields in ListView with 
setReuseItems(false). Now since we store feedback messages ins session, they 
are not discarded when component is removed and we can safely ditch the 
updateFeedback() method (and thus all those stupid traversal that we had all 
over the place).

However, we still need IFeedback, but only as a marker interface. We need to be 
sure that onBeforeRender on IFeedback components is called _after_ all other 
(non feedback) component's onBeforeRender was called. So that we can collect 
all feedback messages, even from things like repeaters. 

I've already implemented this, but I'll need to test it properly before 
commiting.

> feedback panels not being updated when inside repeaters
> ---
>
> Key: WICKET-836
> URL: https://issues.apache.org/jira/browse/WICKET-836
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2, 1.3.0-beta3
>Reporter: Carlos Pita
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: FeedbackPage.html, FeedbackPage.java
>
>
> see the attached example

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



[jira] Commented: (WICKET-836) feedback panels not being updated when inside repeaters

2007-09-01 Thread Carlos Pita (JIRA)

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

Carlos Pita commented on WICKET-836:


I'm using a custom feedback panel as a temporary workaround for this
problem. The panel is only visible when there is feedback registered for its
target component. It has no need to be updated for this, it's just a matter
of overriding isVisible and using the right message filter. I wonder if
wicket's own feedback panels couldn't be implemented this way, instead of
relying on being explicitly notified.



> feedback panels not being updated when inside repeaters
> ---
>
> Key: WICKET-836
> URL: https://issues.apache.org/jira/browse/WICKET-836
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2, 1.3.0-beta3
>Reporter: Carlos Pita
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: FeedbackPage.html, FeedbackPage.java
>
>
> see the attached example

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



[jira] Commented: (WICKET-836) feedback panels not being updated when inside repeaters

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-836:


There seems to be bigger problem :-(

Let's say we have this hierarchy:

 FeedbackPanel
 ListView

inside listView's onPopulateItem we call item.info("something");
That string will not be shown inside FeedbackPanel, because feedback panel 
onBeforeRender is called before the listitem is built.

> feedback panels not being updated when inside repeaters
> ---
>
> Key: WICKET-836
> URL: https://issues.apache.org/jira/browse/WICKET-836
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2, 1.3.0-beta3
>Reporter: Carlos Pita
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: FeedbackPage.html, FeedbackPage.java
>
>
> see the attached example

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



svn commit: r571793 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 05:58:38 2007
New Revision: 571793

URL: http://svn.apache.org/viewvc?rev=571793&view=rev
Log:
typo fix

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java?rev=571793&r1=571792&r2=571793&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/MarkupContainer.java
 Sat Sep  1 05:58:38 2007
@@ -44,44 +44,38 @@
 /**
  * A MarkupContainer holds a map of child components.
  * 
- * Children - Children can be added by calling the add() method, and
- * they can be looked up using a dotted path. For example, if a container 
called
- * "a" held a nested container "b" which held a nested component "c", then
- * a.get("b.c") would return the Component with id "c". The number of children
- * in a MarkupContainer can be determined by calling size(), and the whole
- * hierarchy of children held by a MarkupContainer can be traversed by calling
- * visitChildren(), passing in an implementation of Component.IVisitor.
+ * Children - Children can be added by calling the add() method, 
and they can be looked
+ * up using a dotted path. For example, if a container called "a" held a 
nested container "b" which
+ * held a nested component "c", then a.get("b.c") would return the Component 
with id "c". The number
+ * of children in a MarkupContainer can be determined by calling size(), and 
the whole hierarchy of
+ * children held by a MarkupContainer can be traversed by calling 
visitChildren(), passing in an
+ * implementation of Component.IVisitor.
  * 
- * Markup Rendering - A MarkupContainer also holds/references
- * associated markup which is used to render the container. As the markup 
stream
- * for a container is rendered, component references in the markup are resolved
- * by using the container to look up Components in the container's component 
map
- * by id. Each component referenced by the markup stream is given an 
opportunity
- * to render itself using the markup stream.
+ * Markup Rendering - A MarkupContainer also holds/references 
associated markup which is
+ * used to render the container. As the markup stream for a container is 
rendered, component
+ * references in the markup are resolved by using the container to look up 
Components in the
+ * container's component map by id. Each component referenced by the markup 
stream is given an
+ * opportunity to render itself using the markup stream.
  * 
- * Components may alter their referring tag, replace the tag's body or insert
- * markup after the tag. But components cannot remove tags from the markup
- * stream. This is an important guarantee because graphic designers may be
- * setting attributes on component tags that affect visual presentation.
+ * Components may alter their referring tag, replace the tag's body or insert 
markup after the tag.
+ * But components cannot remove tags from the markup stream. This is an 
important guarantee because
+ * graphic designers may be setting attributes on component tags that affect 
visual presentation.
  * 
- * The type of markup held in a given container subclass can be determined by
- * calling getMarkupType(). Markup is accessed via a MarkupStream object which
- * allows a component to traverse ComponentTag and RawMarkup MarkupElements
- * while rendering a response. Markup in the stream may be HTML or some other
- * kind of markup, such as VXML, as determined by the specific container
- * subclass.
+ * The type of markup held in a given container subclass can be determined by 
calling
+ * getMarkupType(). Markup is accessed via a MarkupStream object which allows 
a component to
+ * traverse ComponentTag and RawMarkup MarkupElements while rendering a 
response. Markup in the
+ * stream may be HTML or some other kind of markup, such as VXML, as 
determined by the specific
+ * container subclass.
  * 
- * A markup stream may be directly associated with a container via
- * setMarkupStream. However, a container which does not have a markup stream
- * (its getMarkupStream() returns null) may inherit a markup stream from a
- * container above it in the component hierarchy. The findMarkupStream() method
- * will locate the first container at or above this container which has a 
markup
- * stream.
+ * A markup stream may be directly associated with a container via 
setMarkupStream. However, a
+ * container which does not have a markup stream (its getMarkupStream() 
returns null) may inherit a
+ * markup stream from a container above it in the component hierarchy. The 
findMarkupStream() method
+ * will locate the first container at or above this cont

[jira] Commented: (WICKET-836) feedback panels not being updated when inside repeaters

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-836:


Actually, I'm not sure that we should do anything about it. It's not true that 
feedback panel is not update. Feedback panel should be updated regardless of 
whether updateFeedback was called or not. If it's not called. the panel should 
be updated on render. The updateFeedback method is only for getting feedback 
from components that might be removed in onBeforeRender (which is also the 
place  where feedback in repeaters are constructed). 

The problem that we have now, is that when there is an error message registered 
_after_ updateFeedback has been called, the panel doesn't display that message 
(e.g. register feedback message in populateItem(), the panel outside list will 
not display the message)

> feedback panels not being updated when inside repeaters
> ---
>
> Key: WICKET-836
> URL: https://issues.apache.org/jira/browse/WICKET-836
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2, 1.3.0-beta3
>Reporter: Carlos Pita
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: FeedbackPage.html, FeedbackPage.java
>
>
> see the attached example

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



[jira] Commented: (WICKET-406) form fields are reset when a file upload fails

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-406:


I'm not sure, if we can just exctract the fields from multipart request while 
discarding the upload. Normally, when fields fail validation, we display the 
values from post (stored inside formcomponent rawinput). But when upload fails, 
we don't really have those values, do we?

> form fields are reset when a file upload fails
> --
>
> Key: WICKET-406
> URL: https://issues.apache.org/jira/browse/WICKET-406
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.2.2, 1.2.3, 1.2.4, 1.2.5
> Environment: Tomcat 5.5.9 , windows 2000 SP2
>Reporter: Jaime De La Jara
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.3.0-rc1
>
>
> If a form contains some fields and a file field, when an uploads fails (for 
> example exceeds the maximum size) the form fields are reset. A better 
> behaviour would be to group all failed validations and show all the messages 
> at once. The relevant code is in class wicket.markup.html.form.Form in method 
> onFormSubmitted, where the condition of handleMultipart is first checked and 
> if it has not been completed the method returns, without processing the rest 
> of the fields.

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



[jira] Resolved: (WICKET-878) IllegalStateException accessing Session.get() from own Resource implementation

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-878.


Resolution: Fixed

> IllegalStateException accessing Session.get() from own Resource implementation
> --
>
> Key: WICKET-878
> URL: https://issues.apache.org/jira/browse/WICKET-878
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
>Reporter: Thomas Singer
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
>
> I'm getting following assertion:
> java.lang.IllegalStateException: you can only locate or create sessions in 
> the context of a request cycle 
> org.apache.wicket.Session.findOrCreate(Session.java:250) 
> org.apache.wicket.Session.get(Session.java:279) 
> com.syntevo.hpsmart.DownloadResource.getResourceStream(DownloadResource.java:18)
>  
> org.apache.wicket.protocol.http.WicketFilter.getLastModified(WicketFilter.java:708)
>  
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:122)
> See this thread for details: 
> http://www.nabble.com/DownloadLink-hanging-tf420.html

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



[jira] Resolved: (WICKET-745) AbstractAjaxTimerBehavior triggered more than expected after a new Ajax rendering

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-745.


Resolution: Fixed

> AbstractAjaxTimerBehavior triggered more than expected after a new Ajax 
> rendering
> -
>
> Key: WICKET-745
> URL: https://issues.apache.org/jira/browse/WICKET-745
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 1.3.0-beta2
>Reporter: Xavier Hanin
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
>
> When an AbstractAjaxTimerBehavior is rendered in an AjaxResponse due to 
> another Ajax callback than the one triggered by the timer itself, it sends a 
> new setTimeout javascript call to the client, causing the client to call the 
> timer more frequently than expected: x+1 times as expected, where x is the 
> number of times the behavior is rendered in a separate Ajax response.

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



[jira] Commented: (WICKET-914) Tree not "redrawn" when resetting root node

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-914:


Also naither the reload() method is necessary 

> Tree not "redrawn" when resetting root node
> ---
>
> Key: WICKET-914
> URL: https://issues.apache.org/jira/browse/WICKET-914
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
>Reporter: Doug Leeper
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: wicketTest-src.jar
>
>
> I have a tree that I reset the root node when a user selects on another 
> component (Component A).  However, the tree is not "redrawn" until I click on 
> the tree (the previous tree contents are shown).
> Have called Tree.invalidateAll() and
> DefaultTreeModel.nodeStructureChanged(tnode )
> DefaultTreeModel.nodeChanged( tnode )
> DefaultTreeModel.reload() 

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



[jira] Resolved: (WICKET-914) Tree not "redrawn" when resetting root node

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp resolved WICKET-914.


Resolution: Fixed

> Tree not "redrawn" when resetting root node
> ---
>
> Key: WICKET-914
> URL: https://issues.apache.org/jira/browse/WICKET-914
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
>Reporter: Doug Leeper
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: wicketTest-src.jar
>
>
> I have a tree that I reset the root node when a user selects on another 
> component (Component A).  However, the tree is not "redrawn" until I click on 
> the tree (the previous tree contents are shown).
> Have called Tree.invalidateAll() and
> DefaultTreeModel.nodeStructureChanged(tnode )
> DefaultTreeModel.nodeChanged( tnode )
> DefaultTreeModel.reload() 

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



[jira] Commented: (WICKET-914) Tree not "redrawn" when resetting root node

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp commented on WICKET-914:


Hi, thanks for quickstart. This was indeed a bug in Tree, where the root node 
change was not properly detected. It should be fixed now. I also added 
convenience updateTree() method, which takes care of looking up the 
AjaxRequestTarget during ajax response, so it can be called from a 
TreeStateListener handler.

Thus to "fix" your example, you'll have to:

change 
 bTree.invalidateAll() to  bTree.updateTree()  in your 
ATreeStateListener.nodeSelected();

remove
  nodeStructureChanged(root);
  nodeChanged(root); 
  from BTreeModel.setData, as the model takes care of it automatically.

> Tree not "redrawn" when resetting root node
> ---
>
> Key: WICKET-914
> URL: https://issues.apache.org/jira/browse/WICKET-914
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
>Reporter: Doug Leeper
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: wicketTest-src.jar
>
>
> I have a tree that I reset the root node when a user selects on another 
> component (Component A).  However, the tree is not "redrawn" until I click on 
> the tree (the previous tree contents are shown).
> Have called Tree.invalidateAll() and
> DefaultTreeModel.nodeStructureChanged(tnode )
> DefaultTreeModel.nodeChanged( tnode )
> DefaultTreeModel.reload() 

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



svn commit: r571761 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/AbstractTree.java

2007-09-01 Thread knopp
Author: knopp
Date: Sat Sep  1 04:15:53 2007
New Revision: 571761

URL: http://svn.apache.org/viewvc?rev=571761&view=rev
Log:
WICKET-914

Modified:

wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/AbstractTree.java

Modified: 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/AbstractTree.java
URL: 
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/AbstractTree.java?rev=571761&r1=571760&r2=571761&view=diff
==
--- 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/AbstractTree.java
 (original)
+++ 
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/tree/AbstractTree.java
 Sat Sep  1 04:15:53 2007
@@ -31,6 +31,7 @@
 import javax.swing.tree.TreeNode;
 
 import org.apache.wicket.Component;
+import org.apache.wicket.IRequestTarget;
 import org.apache.wicket.ResourceReference;
 import org.apache.wicket.ajax.AjaxRequestTarget;
 import org.apache.wicket.behavior.HeaderContributor;
@@ -847,13 +848,28 @@
TreeNode node = 
(TreeNode)e.getTreePath().getLastPathComponent();
 
// has the tree root changed?
-   if (e.getTreePath().getPathCount() == 1 && 
node.equals(rootItem.getModelObject()))
+   if (e.getTreePath().getPathCount() == 1)
{
invalidateAll();
}
else
{
invalidateNodeWithChildren(node);
+   }
+   }
+
+   /**
+* Convenience method that updates changed portions on tree. You can 
call this method during
+* Ajax response, where calling [EMAIL PROTECTED] 
#updateTree(AjaxRequestTarget)} would be appropriate, but
+* you don't have the AjaxRequestTarget instance. However, it is also 
safe to call this method
+* outside Ajax response.
+*/
+   public final void updateTree()
+   {
+   IRequestTarget target = getRequestCycle().getRequestTarget();
+   if (target instanceof AjaxRequestTarget)
+   {
+   updateTree((AjaxRequestTarget)target);
}
}
 




[jira] Updated: (WICKET-914) Tree not "redrawn" when resetting root node

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp updated WICKET-914:
---

Fix Version/s: 1.3.0-beta4

> Tree not "redrawn" when resetting root node
> ---
>
> Key: WICKET-914
> URL: https://issues.apache.org/jira/browse/WICKET-914
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
>Reporter: Doug Leeper
>Assignee: Matej Knopp
> Fix For: 1.3.0-beta4
>
> Attachments: wicketTest-src.jar
>
>
> I have a tree that I reset the root node when a user selects on another 
> component (Component A).  However, the tree is not "redrawn" until I click on 
> the tree (the previous tree contents are shown).
> Have called Tree.invalidateAll() and
> DefaultTreeModel.nodeStructureChanged(tnode )
> DefaultTreeModel.nodeChanged( tnode )
> DefaultTreeModel.reload() 

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



[jira] Assigned: (WICKET-914) Tree not "redrawn" when resetting root node

2007-09-01 Thread Matej Knopp (JIRA)

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

Matej Knopp reassigned WICKET-914:
--

Assignee: Matej Knopp

> Tree not "redrawn" when resetting root node
> ---
>
> Key: WICKET-914
> URL: https://issues.apache.org/jira/browse/WICKET-914
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 1.3.0-beta2
>Reporter: Doug Leeper
>Assignee: Matej Knopp
> Attachments: wicketTest-src.jar
>
>
> I have a tree that I reset the root node when a user selects on another 
> component (Component A).  However, the tree is not "redrawn" until I click on 
> the tree (the previous tree contents are shown).
> Have called Tree.invalidateAll() and
> DefaultTreeModel.nodeStructureChanged(tnode )
> DefaultTreeModel.nodeChanged( tnode )
> DefaultTreeModel.reload() 

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