Re: Tree collapse very slow on firefox 3 for nodes with large # of children - Quickstart attached
i dont really see what we can do to optimize this. i mean, it is
instanteneous in chrome and safari. in IE it is as slow removing all
these nodes as it is adding them so there it seems also we do not
incur any penalty. i am not sure how to optimize this loop for
firefox. we need the tree to be flat as far as actual markup
representation for reason matej already mentioned and because if we
nest things it is much much harder to get all those tree lines to line
up perfectly.
if you have any ideas we are all ears.
-igor
On Tue, Jun 9, 2009 at 8:39 PM, Matt Shannonmshannon.wic...@gmail.com wrote:
Just looking at the firebug profiler, the removeNodes method from tree.js is
the function that is taking way too long to complete. Checking the DOM, it
looks like all nodes in tree regardless of position have their parent node
set as the wicket panel surrounding the tree.
I would have thought ideally that the various branches of the tree have
their parents referring to the true tree node parent rather than a single
common parent. This would allow collapse functions to simply remove all
nodes of the particular element concerned.
I guess it may be worthwhile experimenting with the following function to
see if it can be optimized with limited interference.
Wicket.Tree.removeNodes = function(prefix, nodeList) {
var problem = false;
for (var i = 0; i nodeList.length; i++) {
var e = document.getElementById(prefix + nodeList[i]);
if (e != null) {
e.parentNode.removeChild(e);
} else {
// while developing alert a warning
problem = true;
Wicket.Log.error(Can't find node with id + prefix +
nodeList[i] + . This shouldn't happen - possible bug in tree?);
}
}
if (problem == true) {
Wicket.Tree.askForReload();
}
}
thanks
Matt.
On Wed, Jun 10, 2009 at 10:39 AM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
On Tue, Jun 9, 2009 at 3:41 PM, Matt Shannonmshannon.wic...@gmail.com
wrote:
Hi Igor,
One thing I've learned reading these newsgroups is to not irritate you,
or
you don't get a favourable response :)
isnt that how most things in life work? :)
I've attached a new quickstart that does have the Start class (which I
appreciate makes debugging from an IDE much simpler).
i played around with quickstart. it runs fast in IE8, Safari, and
Chrome. Only Firefox, like you mentioned, is afflicted. I am not sure
why the dom node removal is so slow in firefox, we may have to roll
special javascript just for firefox to handle this...i am not,
however, sure what will work fast because already we are not doing
anything special to remove the dom node.
-igor
The maven jetty plugin is also configured with contextpath /
e.g.
mvn jetty:run
http://localhost:8080
thanks,
Matt.
On Wed, Jun 10, 2009 at 12:45 AM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
seems your quickstart is not a quickstart - eg its missing the Start
launcher usually found in src/test/java of the quickstart
archetype/project.
-igor
On Tue, Jun 9, 2009 at 2:09 AM, Matt Shannonmshannon.wic...@gmail.com
wrote:
Hi,
First time poster, but have been lurking for a few crazy months trying
to
learn and develop with this technology. I'm prototyping a wicket app
for
work, and have been extremely impressed with this framework and also
the
support and information that can be found on these mailing lists.
The one component in wicket I have found that seems most difficult to
leverage in an AJAX / dynamic on demand nature seems to be the tree
component. I've hobbled together a dynamic tree leveraging bits and
pieces
of other peoples work (mostly from this mailing list). The tree seems
to
work ok, but I have run in to a strange performance issue on firefox
when
attempting to collapse a node.
Firefox has serious performance issues when collapsing nodes with a
semi-large number of children (e.g. 100+ children).
I've attached a quickstart that demonstrates the issue (Firefox
3.0.10).
The collapse performance issue does not appear to affect IE6.
I would be interested to see if anyone can conform this issue (based
on
the
attached quickstart), and suggest a mechanism that may combat this.
In my 'real' application, my nodes have real detachable models
associated
with each tree node.
cheers
Matt.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
Re: Tree collapse very slow on firefox 3 for nodes with large # of children - Quickstart attached
seems your quickstart is not a quickstart - eg its missing the Start launcher usually found in src/test/java of the quickstart archetype/project. -igor On Tue, Jun 9, 2009 at 2:09 AM, Matt Shannonmshannon.wic...@gmail.com wrote: Hi, First time poster, but have been lurking for a few crazy months trying to learn and develop with this technology. I'm prototyping a wicket app for work, and have been extremely impressed with this framework and also the support and information that can be found on these mailing lists. The one component in wicket I have found that seems most difficult to leverage in an AJAX / dynamic on demand nature seems to be the tree component. I've hobbled together a dynamic tree leveraging bits and pieces of other peoples work (mostly from this mailing list). The tree seems to work ok, but I have run in to a strange performance issue on firefox when attempting to collapse a node. Firefox has serious performance issues when collapsing nodes with a semi-large number of children (e.g. 100+ children). I've attached a quickstart that demonstrates the issue (Firefox 3.0.10). The collapse performance issue does not appear to affect IE6. I would be interested to see if anyone can conform this issue (based on the attached quickstart), and suggest a mechanism that may combat this. In my 'real' application, my nodes have real detachable models associated with each tree node. cheers Matt. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Tree collapse very slow on firefox 3 for nodes with large # of children - Quickstart attached
On Tue, Jun 9, 2009 at 3:41 PM, Matt Shannonmshannon.wic...@gmail.com wrote: Hi Igor, One thing I've learned reading these newsgroups is to not irritate you, or you don't get a favourable response :) isnt that how most things in life work? :) I've attached a new quickstart that does have the Start class (which I appreciate makes debugging from an IDE much simpler). i played around with quickstart. it runs fast in IE8, Safari, and Chrome. Only Firefox, like you mentioned, is afflicted. I am not sure why the dom node removal is so slow in firefox, we may have to roll special javascript just for firefox to handle this...i am not, however, sure what will work fast because already we are not doing anything special to remove the dom node. -igor The maven jetty plugin is also configured with contextpath / e.g. mvn jetty:run http://localhost:8080 thanks, Matt. On Wed, Jun 10, 2009 at 12:45 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: seems your quickstart is not a quickstart - eg its missing the Start launcher usually found in src/test/java of the quickstart archetype/project. -igor On Tue, Jun 9, 2009 at 2:09 AM, Matt Shannonmshannon.wic...@gmail.com wrote: Hi, First time poster, but have been lurking for a few crazy months trying to learn and develop with this technology. I'm prototyping a wicket app for work, and have been extremely impressed with this framework and also the support and information that can be found on these mailing lists. The one component in wicket I have found that seems most difficult to leverage in an AJAX / dynamic on demand nature seems to be the tree component. I've hobbled together a dynamic tree leveraging bits and pieces of other peoples work (mostly from this mailing list). The tree seems to work ok, but I have run in to a strange performance issue on firefox when attempting to collapse a node. Firefox has serious performance issues when collapsing nodes with a semi-large number of children (e.g. 100+ children). I've attached a quickstart that demonstrates the issue (Firefox 3.0.10). The collapse performance issue does not appear to affect IE6. I would be interested to see if anyone can conform this issue (based on the attached quickstart), and suggest a mechanism that may combat this. In my 'real' application, my nodes have real detachable models associated with each tree node. cheers Matt. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Tree collapse very slow on firefox 3 for nodes with large # of children - Quickstart attached
Just looking at the firebug profiler, the removeNodes method from tree.js is
the function that is taking way too long to complete. Checking the DOM, it
looks like all nodes in tree regardless of position have their parent node
set as the wicket panel surrounding the tree.
I would have thought ideally that the various branches of the tree have
their parents referring to the true tree node parent rather than a single
common parent. This would allow collapse functions to simply remove all
nodes of the particular element concerned.
I guess it may be worthwhile experimenting with the following function to
see if it can be optimized with limited interference.
Wicket.Tree.removeNodes = function(prefix, nodeList) {
var problem = false;
for (var i = 0; i nodeList.length; i++) {
var e = document.getElementById(prefix + nodeList[i]);
if (e != null) {
e.parentNode.removeChild(e);
} else {
// while developing alert a warning
problem = true;
Wicket.Log.error(Can't find node with id + prefix +
nodeList[i] + . This shouldn't happen - possible bug in tree?);
}
}
if (problem == true) {
Wicket.Tree.askForReload();
}
}
thanks
Matt.
On Wed, Jun 10, 2009 at 10:39 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
On Tue, Jun 9, 2009 at 3:41 PM, Matt Shannonmshannon.wic...@gmail.com
wrote:
Hi Igor,
One thing I've learned reading these newsgroups is to not irritate you,
or
you don't get a favourable response :)
isnt that how most things in life work? :)
I've attached a new quickstart that does have the Start class (which I
appreciate makes debugging from an IDE much simpler).
i played around with quickstart. it runs fast in IE8, Safari, and
Chrome. Only Firefox, like you mentioned, is afflicted. I am not sure
why the dom node removal is so slow in firefox, we may have to roll
special javascript just for firefox to handle this...i am not,
however, sure what will work fast because already we are not doing
anything special to remove the dom node.
-igor
The maven jetty plugin is also configured with contextpath /
e.g.
mvn jetty:run
http://localhost:8080
thanks,
Matt.
On Wed, Jun 10, 2009 at 12:45 AM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
seems your quickstart is not a quickstart - eg its missing the Start
launcher usually found in src/test/java of the quickstart
archetype/project.
-igor
On Tue, Jun 9, 2009 at 2:09 AM, Matt Shannonmshannon.wic...@gmail.com
wrote:
Hi,
First time poster, but have been lurking for a few crazy months trying
to
learn and develop with this technology. I'm prototyping a wicket app
for
work, and have been extremely impressed with this framework and also
the
support and information that can be found on these mailing lists.
The one component in wicket I have found that seems most difficult to
leverage in an AJAX / dynamic on demand nature seems to be the tree
component. I've hobbled together a dynamic tree leveraging bits and
pieces
of other peoples work (mostly from this mailing list). The tree seems
to
work ok, but I have run in to a strange performance issue on firefox
when
attempting to collapse a node.
Firefox has serious performance issues when collapsing nodes with a
semi-large number of children (e.g. 100+ children).
I've attached a quickstart that demonstrates the issue (Firefox
3.0.10).
The collapse performance issue does not appear to affect IE6.
I would be interested to see if anyone can conform this issue (based
on
the
attached quickstart), and suggest a mechanism that may combat this.
In my 'real' application, my nodes have real detachable models
associated
with each tree node.
cheers
Matt.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Tree collapse very slow on firefox 3 for nodes with large # of children - Quickstart attached
There is good reason why the markup is flat and not nested. Otherwise
treetable/grid wouldn't be possible.
-Matej
On Wed, Jun 10, 2009 at 5:39 AM, Matt Shannonmshannon.wic...@gmail.com wrote:
Just looking at the firebug profiler, the removeNodes method from tree.js is
the function that is taking way too long to complete. Checking the DOM, it
looks like all nodes in tree regardless of position have their parent node
set as the wicket panel surrounding the tree.
I would have thought ideally that the various branches of the tree have
their parents referring to the true tree node parent rather than a single
common parent. This would allow collapse functions to simply remove all
nodes of the particular element concerned.
I guess it may be worthwhile experimenting with the following function to
see if it can be optimized with limited interference.
Wicket.Tree.removeNodes = function(prefix, nodeList) {
var problem = false;
for (var i = 0; i nodeList.length; i++) {
var e = document.getElementById(prefix + nodeList[i]);
if (e != null) {
e.parentNode.removeChild(e);
} else {
// while developing alert a warning
problem = true;
Wicket.Log.error(Can't find node with id + prefix +
nodeList[i] + . This shouldn't happen - possible bug in tree?);
}
}
if (problem == true) {
Wicket.Tree.askForReload();
}
}
thanks
Matt.
On Wed, Jun 10, 2009 at 10:39 AM, Igor Vaynberg
igor.vaynb...@gmail.comwrote:
On Tue, Jun 9, 2009 at 3:41 PM, Matt Shannonmshannon.wic...@gmail.com
wrote:
Hi Igor,
One thing I've learned reading these newsgroups is to not irritate you,
or
you don't get a favourable response :)
isnt that how most things in life work? :)
I've attached a new quickstart that does have the Start class (which I
appreciate makes debugging from an IDE much simpler).
i played around with quickstart. it runs fast in IE8, Safari, and
Chrome. Only Firefox, like you mentioned, is afflicted. I am not sure
why the dom node removal is so slow in firefox, we may have to roll
special javascript just for firefox to handle this...i am not,
however, sure what will work fast because already we are not doing
anything special to remove the dom node.
-igor
The maven jetty plugin is also configured with contextpath /
e.g.
mvn jetty:run
http://localhost:8080
thanks,
Matt.
On Wed, Jun 10, 2009 at 12:45 AM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
seems your quickstart is not a quickstart - eg its missing the Start
launcher usually found in src/test/java of the quickstart
archetype/project.
-igor
On Tue, Jun 9, 2009 at 2:09 AM, Matt Shannonmshannon.wic...@gmail.com
wrote:
Hi,
First time poster, but have been lurking for a few crazy months trying
to
learn and develop with this technology. I'm prototyping a wicket app
for
work, and have been extremely impressed with this framework and also
the
support and information that can be found on these mailing lists.
The one component in wicket I have found that seems most difficult to
leverage in an AJAX / dynamic on demand nature seems to be the tree
component. I've hobbled together a dynamic tree leveraging bits and
pieces
of other peoples work (mostly from this mailing list). The tree seems
to
work ok, but I have run in to a strange performance issue on firefox
when
attempting to collapse a node.
Firefox has serious performance issues when collapsing nodes with a
semi-large number of children (e.g. 100+ children).
I've attached a quickstart that demonstrates the issue (Firefox
3.0.10).
The collapse performance issue does not appear to affect IE6.
I would be interested to see if anyone can conform this issue (based
on
the
attached quickstart), and suggest a mechanism that may combat this.
In my 'real' application, my nodes have real detachable models
associated
with each tree node.
cheers
Matt.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To
