[jira] Commented: (WICKET-3281) autolink doesn't work with relative paths in borders
[ https://issues.apache.org/jira/browse/WICKET-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974712#action_12974712 ] Anatoly Kupriyanov commented on WICKET-3281: BTW, how to click autolink from a test case? > autolink doesn't work with relative paths in borders > > > Key: WICKET-3281 > URL: https://issues.apache.org/jira/browse/WICKET-3281 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14 >Reporter: Anatoly Kupriyanov > Attachments: wicketbug.tgz > > > Take the "navomatic" wicket example and move the Page2.java and Page2.html > into an another java-package - relative paths in the NavomaticBorder.html > will be resolved incorrectly, they resolved against current page, but not > against NavomaticBorder.html. > So, I cannot use autolink functionality from bordes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3281) autolink doesn't work with relative paths in borders
[ https://issues.apache.org/jira/browse/WICKET-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anatoly Kupriyanov updated WICKET-3281: --- Attachment: wicketbug.tgz Unit test > autolink doesn't work with relative paths in borders > > > Key: WICKET-3281 > URL: https://issues.apache.org/jira/browse/WICKET-3281 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14 >Reporter: Anatoly Kupriyanov > Attachments: wicketbug.tgz > > > Take the "navomatic" wicket example and move the Page2.java and Page2.html > into an another java-package - relative paths in the NavomaticBorder.html > will be resolved incorrectly, they resolved against current page, but not > against NavomaticBorder.html. > So, I cannot use autolink functionality from bordes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3281) autolink doesn't work with relative paths in borders
[ https://issues.apache.org/jira/browse/WICKET-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anatoly Kupriyanov updated WICKET-3281: --- Comment: was deleted (was: Unit test) > autolink doesn't work with relative paths in borders > > > Key: WICKET-3281 > URL: https://issues.apache.org/jira/browse/WICKET-3281 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14 >Reporter: Anatoly Kupriyanov > Attachments: wicketbug.tgz > > > Take the "navomatic" wicket example and move the Page2.java and Page2.html > into an another java-package - relative paths in the NavomaticBorder.html > will be resolved incorrectly, they resolved against current page, but not > against NavomaticBorder.html. > So, I cannot use autolink functionality from bordes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3281) autolink doesn't work with relative paths in borders
autolink doesn't work with relative paths in borders Key: WICKET-3281 URL: https://issues.apache.org/jira/browse/WICKET-3281 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.14 Reporter: Anatoly Kupriyanov Take the "navomatic" wicket example and move the Page2.java and Page2.html into an another java-package - relative paths in the NavomaticBorder.html will be resolved incorrectly, they resolved against current page, but not against NavomaticBorder.html. So, I cannot use autolink functionality from bordes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1964) Add IBehavior.isVisibilityAllowed(Component) or so
[ https://issues.apache.org/jira/browse/WICKET-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924308#action_12924308 ] Anatoly Kupriyanov commented on WICKET-1964: Google for it by "make invisible if model object is null" keywords http://apache-wicket.1842946.n4.nabble.com/make-invisible-if-model-object-is-null-td1874965.html > Add IBehavior.isVisibilityAllowed(Component) or so > -- > > Key: WICKET-1964 > URL: https://issues.apache.org/jira/browse/WICKET-1964 > Project: Wicket > Issue Type: New Feature > Components: wicket >Reporter: Anatoly Kupriyanov >Assignee: Igor Vaynberg > Fix For: 1.5-M3 > > > A behavior should able to control component's visibility. > Discussion > http://www.nabble.com/make-invisible-if-model-object-is-null-tt20769823.html > explains useful usecase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1404) Investigate default focus support (on Page or RequestCycle)
[
https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922023#action_12922023
]
Anatoly Kupriyanov commented on WICKET-1404:
It's bad idea to set focus from the onload event. This event could occur after
a control is visible and a user starts edit the control - focus suddenly jumps
to another one.
I hate this - I open page, it still loading but login/password form already
rendered and while I'm typing a password, page finishes loading and focus
suddenly jumps to the login box, it could reveal my password.
Usually it's better to put getElementById('" + component.getMarkupId() +
"').focus() right after form component.
> Investigate default focus support (on Page or RequestCycle)
> ---
>
> Key: WICKET-1404
> URL: https://issues.apache.org/jira/browse/WICKET-1404
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 1.3.1
>Reporter: James Carman
>Priority: Minor
> Fix For: 1.5-M3
>
> Attachments: WICKET-1404.patch
>
>
> We need something which gives a component the focus when the page loads.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[ https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679169#action_12679169 ] Anatoly Kupriyanov commented on WICKET-2127: I understand, I mean somebody should just fix the code in wicket source itself. The code "while ... Wicket.replaceAll" is very inefficient - it creates a lot of string objects and has bad algorithmic complexity (quadratic instead of linear). It could be done by single replace(/.../g) which should work much more faster. > Javascript function Wicket.replaceAll is unbearably slow > > > Key: WICKET-2127 > URL: https://issues.apache.org/jira/browse/WICKET-2127 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: Firefox 3.0.5, Opera 9.2 (windows) >Reporter: Sean Patrick Floyd >Assignee: Matej Knopp > Fix For: 1.4-RC3 > > Attachments: wicketReplaceAll.js > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I use AbstractAjaxTimerBehavior to update many different components on my > pages periodically. > After a while, the browser occupies 50% or more of the system resources. > I used the javascript profiler in firebug and found that Wicket.replaceAll is > responsible for 60+ percent of javascript processing time. > The problem is that sequential string processing is used instead of much > faster regular expressions -- 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-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678927#action_12678927
]
kan.izh edited comment on WICKET-2127 at 3/4/09 1:25 PM:
Also
function removeIframeMark(text) {
var markerRe = new RegExp(marker, "g") //this variable could be cached
somewhere globally, so we could avoid regex compilation every time if it
affects performance
return text.replace(markerRe, "")
}
Wicket.decode1 = function(text) {
return text.replace(/\]\^/g, "]")
}
was (Author: kan.izh):
Also
function removeIframeMark(text) {
var markerRe = new RegExp(marker, "g") //this variable could
be cached somewhere globally, so we could avoid regex compilation if it affects
performance
return text.replace(markerRe, "");
}
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678927#action_12678927
]
Anatoly Kupriyanov commented on WICKET-2127:
Also
function removeIframeMark(text) {
var markerRe = new RegExp(marker, "g") //this variable could
be cached somewhere globally, so we could avoid regex compilation if it affects
performance
return text.replace(markerRe, "");
}
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
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-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678925#action_12678925
]
kan.izh edited comment on WICKET-2127 at 3/4/09 1:19 PM:
I am not sure what do you want to do, but you can use RegExp object, so this:
function(str, from, to) {
var re = from.replace(/(\W)/g, "\\$1");
return str.replace(new RegExp(re, "g"), to);
}
But my advice, don't do generic method replaceAll, but use replace with g
modifier. Say in method
function markIframe(text) {
var t = text;
var r = /<\s*iframe/i;
while ((m = t.match(r)) != null) {
t = Wicket.replaceAll(t, m[0], "<" + marker +
m[0].substring(1));
}
return t;
}
it's enough just do
function markIframe(text) {
return text.replace(/<\s*iframe/ig, "<"+marker + "iframe");
}
was (Author: kan.izh):
I am not sure what do you want to do, but you can use RegExp object, so
this:
function(str, from, to) {
var re = from.replace(/(\W)/g, "\\$1");
return str.replace(new RegExp(re, "g"), to);
}
But my advice, don't do generic method replaceAll, but use replace with g
modifier. Say in method
function markIframe(text) {
var t = text;
var r = /<\s*iframe/i;
while ((m = t.match(r)) != null) {
t = Wicket.replaceAll(t, m[0], "<" + marker +
m[0].substring(1));
}
return t;
}
it's enough just do
function markIframe(text) {
return text.replace(/<\s*iframe/ig, "<"+marker);
}
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
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-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678925#action_12678925
]
kan.izh edited comment on WICKET-2127 at 3/4/09 1:16 PM:
I am not sure what do you want to do, but you can use RegExp object, so this:
[code]
function(str, from, to) {
var re = from.replace(/(\W)/g, "\\$1");
return str.replace(new RegExp(re, "g"), to);
}
[/code]
But my advice, don't do generic method replaceAll, but use replace with g
modifier. Say in method
function markIframe(text) {
var t = text;
var r = /<\s*iframe/i;
while ((m = t.match(r)) != null) {
t = Wicket.replaceAll(t, m[0], "<" + marker +
m[0].substring(1));
}
return t;
}
it's enough just do
function markIframe(text) {
return text.replace(/<\s*iframe/ig, "<"+marker);
}
was (Author: kan.izh):
I am not sure what do you want to do, but you can use RegExp object, so
this:
function(str, from, to) {
var re = from.replace(/(\W)/g, "\\$1");
return str.replace(new RegExp(re, "g"), to);
}
But my advice, don't do generic method replaceAll, but use replace with g
modifier. Say in method
function markIframe(text) {
var t = text;
var r = /<\s*iframe/i;
while ((m = t.match(r)) != null) {
t = Wicket.replaceAll(t, m[0], "<" + marker +
m[0].substring(1));
}
return t;
}
it's enough just do
function markIframe(text) {
return text.replace(/<\s*iframe/ig, "<"+marker);
}
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
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-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678925#action_12678925
]
kan.izh edited comment on WICKET-2127 at 3/4/09 1:16 PM:
I am not sure what do you want to do, but you can use RegExp object, so this:
function(str, from, to) {
var re = from.replace(/(\W)/g, "\\$1");
return str.replace(new RegExp(re, "g"), to);
}
But my advice, don't do generic method replaceAll, but use replace with g
modifier. Say in method
function markIframe(text) {
var t = text;
var r = /<\s*iframe/i;
while ((m = t.match(r)) != null) {
t = Wicket.replaceAll(t, m[0], "<" + marker +
m[0].substring(1));
}
return t;
}
it's enough just do
function markIframe(text) {
return text.replace(/<\s*iframe/ig, "<"+marker);
}
was (Author: kan.izh):
I am not sure what do you want to do, but you can use RegExp object, so
this:
[code]
function(str, from, to) {
var re = from.replace(/(\W)/g, "\\$1");
return str.replace(new RegExp(re, "g"), to);
}
[/code]
But my advice, don't do generic method replaceAll, but use replace with g
modifier. Say in method
function markIframe(text) {
var t = text;
var r = /<\s*iframe/i;
while ((m = t.match(r)) != null) {
t = Wicket.replaceAll(t, m[0], "<" + marker +
m[0].substring(1));
}
return t;
}
it's enough just do
function markIframe(text) {
return text.replace(/<\s*iframe/ig, "<"+marker);
}
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678925#action_12678925
]
Anatoly Kupriyanov commented on WICKET-2127:
I am not sure what do you want to do, but you can use RegExp object, so this:
function(str, from, to) {
var re = from.replace(/(\W)/g, "\\$1");
return str.replace(new RegExp(re, "g"), to);
}
But my advice, don't do generic method replaceAll, but use replace with g
modifier. Say in method
function markIframe(text) {
var t = text;
var r = /<\s*iframe/i;
while ((m = t.match(r)) != null) {
t = Wicket.replaceAll(t, m[0], "<" + marker +
m[0].substring(1));
}
return t;
}
it's enough just do
function markIframe(text) {
return text.replace(/<\s*iframe/ig, "<"+marker);
}
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1897) StatelessForm submitted to the wrong page
[ https://issues.apache.org/jira/browse/WICKET-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anatoly Kupriyanov updated WICKET-1897: --- Attachment: jira1897.patch Patch to fix the problem and unit-test. > StatelessForm submitted to the wrong page > - > > Key: WICKET-1897 > URL: https://issues.apache.org/jira/browse/WICKET-1897 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.4-M3 >Reporter: Adrian Sandor >Assignee: Johan Compagner > Fix For: 1.4-RC3 > > Attachments: jira1897.patch, wickettest.zip > > > I made a small application to reproduce the problem. You can download it from > http://aditsu.net/wickettest.zip , I'll try to attach it too. > Dependencies: jetty 6, wicket 1.4-m3, slf4j, log4j > Steps to reproduce: > 1. Run the test.Start class > 2. Open http://localhost:8080 in a browser > 3. Open http://localhost:8080/page2 in a new tab > 4. Go to the first tab and click submit > Result: > WicketRuntimeException: unable to find component with path form on stateless > page [Page class = test.Page2, id = 0, version = 0] > It looks like the 2 pages are created with the same id in 2 different > pagemaps, but when I submit the form, it goes to the second pagemap and finds > the second page (with no form on it). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-693) What to do with the wicket dtd?
[ https://issues.apache.org/jira/browse/WICKET-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673863#action_12673863 ] Anatoly Kupriyanov commented on WICKET-693: --- This DTD defines only wicket:id and wicket:preview attributes, but doesn't define any wicket elements. Is it just not finished or am I missing something? Answering previous question, you need make a , which will point to the wicket-xhtml1.4-strict.dtd, but it will not work well while .dtd is not complete. Afair, in IDEA it's possible to name file as .xhtml, instead .html, it gives more strict validations. > What to do with the wicket dtd? > --- > > Key: WICKET-693 > URL: https://issues.apache.org/jira/browse/WICKET-693 > Project: Wicket > Issue Type: Bug > Components: site, wicket >Reporter: Martijn Dashorst >Assignee: Timo Rantalaiho > Fix For: 1.3.6, 1.4-RC2 > > > The current dtd is located at the wicket.sf.net site, and may not even work. > We need to come up with a solution for the wicket dtd and fix this for the > future: > ./jdk-1.4/wicket/src/site/resources/DTD/wicket-1.0-xhtml11.dtd: SYSTEM > "http://wicket.sourceforge.net/DTD/wicket-xhtml1.dtd"; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1964) Add IBehavior.isVisibilityAllowed(Component) or so
Add IBehavior.isVisibilityAllowed(Component) or so -- Key: WICKET-1964 URL: https://issues.apache.org/jira/browse/WICKET-1964 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Anatoly Kupriyanov Fix For: 1.4-RC2, 1.5-M1 A behavior should able to control component's visibility. Discussion http://www.nabble.com/make-invisible-if-model-object-is-null-tt20769823.html explains useful usecase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
