Re: [jQuery] performance issues in IE
Thank you for all the suggestions. Yes, we are most definitely looking at
ways to rein in the big select lists, but that won't happen overnight,
unfortunately. I would argue that hundreds of nodes is fairly big, but not
big enough to explain it taking 12+ seconds to process, especially when the
same operation takes a fraction of a second in FF. I would venture to guess
that it has more to do with IE not liking the algorithm used for some
reason.
I did try doing something involving this:
$('textarea,select,[EMAIL PROTECTED]')
and that completely eliminated the performance problem, but it returns the
elements in the order you specified (all textareas, then all selects, then
all inputs) rather than in the order that they appear in the document. I
couldn't come up with a way to compare 2 nodes and determine which comes
first in the document. Comparing their top/left positions is a possibility.
But I think I'm going to do this by looping through form.elements. It's
easy, fast, and appears to have adequate browser support. And even if it
doesn't work in all browsers, I don't consider this mission-critical
functionality anyway.
Thanks again for the suggestions.
Todd
On 12/20/06, Dave Methvin [EMAIL PROTECTED] wrote:
Did you perhaps mean filter() instead of select()?
Yep, I meant filter(), thanks for the catch.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] performance issues in IE
If anyone cares, here's what I finally resorted to. Thought maybe I could at
least use $(form.elements) and still apply my filter, but IE doesn't treat
form.elements as an array, nor does it appear to treat the individual
elements as true DOM nodes. So as much as it pained me to do it, here's the
(very un-jQuery) solution I came up with:
var fields = document.forms[0].elements;
for (var i = 0; i fields.length; i++) {
var tag = fields[i].tagName.toLowerCase();
if ((tag == 'textarea' || tag == 'select' || (tag == 'input'
fields[i].type == 'text'))
fields[i].style.visibility != 'hidden'
fields[i].style.display != 'none'
!fields[i].disabled)
{
fields[i].focus();
break;
}
}
On 12/20/06, Todd Menier [EMAIL PROTECTED] wrote:
Thank you for all the suggestions. Yes, we are most definitely looking at
ways to rein in the big select lists, but that won't happen overnight,
unfortunately. I would argue that hundreds of nodes is fairly big, but not
big enough to explain it taking 12+ seconds to process, especially when the
same operation takes a fraction of a second in FF. I would venture to guess
that it has more to do with IE not liking the algorithm used for some
reason.
I did try doing something involving this:
$('textarea,select,[EMAIL PROTECTED]')
and that completely eliminated the performance problem, but it returns the
elements in the order you specified (all textareas, then all selects, then
all inputs) rather than in the order that they appear in the document. I
couldn't come up with a way to compare 2 nodes and determine which comes
first in the document. Comparing their top/left positions is a possibility.
But I think I'm going to do this by looping through form.elements. It's
easy, fast, and appears to have adequate browser support. And even if it
doesn't work in all browsers, I don't consider this mission-critical
functionality anyway.
Thanks again for the suggestions.
Todd
On 12/20/06, Dave Methvin [EMAIL PROTECTED] wrote:
Did you perhaps mean filter() instead of select()?
Yep, I meant filter(), thanks for the catch.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] performance issues in IE
Hello,
I'm writing a function in a global script that will apply focus to the first
visible enabled form field on a page. I'm using the following jQuery
expression to find the control:
$('#mainContent
:input:visible:not(:checkbox):not(:button):not(:submit):not(:image):not([EMAIL
PROTECTED]):first')
This works exactly as expected, but unfortunately it's quite slow in IE 7
when there is a fairly large amount of HTML (about 12 seconds on a page that
contains 2 select lists with several hundred options each). I had assumed
that the :first qualifier would cause the search operation to stop after
it finds a match, but that doesn't seem to be the case. And the problem
doesn't seem to be with any of the other specific qualifiers I'm using;
*:first is equally slow.
I think I need to do this the long way, traversing the DOM and checking all
the conditions manually, just so I can stop when a match is found. Unless
anyone can think of a way I can accomplish this and still take advantage of
jQuery's coolness in some way?
Thanks in advance,
Todd
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] performance issues in IE
Thanks Aaron. That unfortunately didn't make it any faster. Plus I don't
think you'd want to apply that filter expression after you've applied the
:first qualifier in the initial expression - that could leave you with
nothing even when there's a match somewhere on the page. Anyway, I had the
initial expression reduced all the way down to:
$(#mainContent *:first)
and it wasn't any better, which is why I think I'm stuck having to traverse
the DOM, as much as I'd like to use a jQuery expression. And as I mentioned,
only IE seems to have a problem with it. It works plenty fast in FF. If
anyone else has any suggestions, I'd love to hear them.
On 12/19/06, Aaron Heimlich [EMAIL PROTECTED] wrote:
Try this (completely untested):
$(#mainContent :input:enabled:visible:first)
.filter([textarea,select,[EMAIL PROTECTED]'text']])
.each(function() {
this.focus();
});
On 12/19/06, Todd Menier [EMAIL PROTECTED] wrote:
Hello,
I'm writing a function in a global script that will apply focus to the
first visible enabled form field on a page. I'm using the following jQuery
expression to find the control:
$('#mainContent
:input:visible:not(:checkbox):not(:button):not(:submit):not(:image):not([EMAIL
PROTECTED]):first')
This works exactly as expected, but unfortunately it's quite slow in IE
7 when there is a fairly large amount of HTML (about 12 seconds on a page
that contains 2 select lists with several hundred options each). I had
assumed that the :first qualifier would cause the search operation to stop
after it finds a match, but that doesn't seem to be the case. And the
problem doesn't seem to be with any of the other specific qualifiers I'm
using; *:first is equally slow.
I think I need to do this the long way, traversing the DOM and checking
all the conditions manually, just so I can stop when a match is found.
Unless anyone can think of a way I can accomplish this and still take
advantage of jQuery's coolness in some way?
Thanks in advance,
Todd
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Issue with jQuery 1.0.3 + ASP.NET LinkButton
Great, thanks! Sorry if this sounds incredibly lazy, but is there a compressed version available for download somewhere or would I need to build it? Not a huge deal - I'm in a Windows environment and don't currently have an SVN client or Ant, but I'll get them if I need to.
ThanksOn 11/7/06, Brandon Aaron [EMAIL PROTECTED] wrote:
If you can, grab the latest from SVN because it is fixed there.--Brandon AaronOn 11/7/06, Todd Menier [EMAIL PROTECTED] wrote: Hello, I'm hoping someone might be able to offer some insight into a rather urgent
issue I'm struggling with. I'm using jQuery in an ASP.NET application, and upon upgrading from jQuery 1.0.1 to 1.0.3, all my LinkButton controls throw an error (event has no properties) when clicked. I've tracked it down to
the fact that in 1.0.1, jQuery.event.fix does a null check on event before attaching the preventDefault function, whereas 1.0.3 does not do this check: if ( event ) { event.preventDefault
= function() { this.returnValue = false; }; If you can stop me at this point and say it's a know issue and there's a fix, great! Otherwise, here's my best attempt at explaining the situation,
and maybe there's a workaround. I *think* the problem has to do with some conflict between jQuery's event binding and the way ASP.NET submits a form from within a script. When these
2 conditions exist, jQuery.event.handle is being called with a null event, and I'm not sure why. If you're not familiar with ASP.NET, a LinkButton control is basically an abstraction of a hyperlink that causes a form post
via _javascript_. The ASP.NET framework renders the following script, and the LinkButton's href calls __doPostBack: script type=text/_javascript_
!-- var theForm = document.forms['aspnetForm']; if (!theForm) {theForm = document.aspnetForm; } function __doPostBack(eventTarget, eventArgument) {if (!theForm.onsubmit || (
theForm.onsubmit() != false)) {theForm.__EVENTTARGET.value = eventTarget;theForm.__EVENTARGUMENT.value = eventArgument;theForm.submit();} } // -- /script
I also have a script that binds to the form submission as follows: $('#aspnetForm').submit(function() { // doesn't matter what's here }); It's the existence of the event binding above, combined with clicking on a
LinkButton, that causes the error. And again, there were no issues in 1.0.1 due the null check. Thanks for any help! Todd ___
jQuery mailing list discuss@jquery.com http://jquery.com/discuss/___
jQuery mailing listdiscuss@jquery.comhttp://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] simple profiling
Since I'm usually taking a lot more from this group than I'm giving back, I thought I'd offer this up if anyone might find it useful. It's a simple global object for tracking code execution time. (I discovered Firebug's console.time
after I'd already written this. Oh well. This one can be used in any browser, anyway.) It has no depedencies on jQuery other than that I happened to use the $ namespace. Feel free to use/extend/modify to your liking.
Usage:$.timer.start();// some code$.timer.mark('optional label');// some code$.timer.pause();// some code to exclude from profiling$.timer.resume();// some code$.timer.mark();
// some code$.timer.show('optional label'); // displays a list of all marks to this point in an alert pop-upThe code:// usage: $.debug({x:x, y:y, z:z})$.debug = function(o) { var s = [];
for (var name in o) s.push(name + ': ' + o[name]) alert(s.join('\n'));}$.timer = { start: function() { this.info = {}; this.count
= 0; this.pauseTime = 0; this.time = new Date().getTime(); }, mark: function(s) { var t = ((this.pauseTime == 0) ? new Date().getTime() : this.pauseTime) - this.time;
this.count++; if (s == undefined) s = 'mark ' + this.count; this.info[s] = '' + t + ' ms (' + (t/1000) + ' s)'; this.time = new Date().getTime(); if (this.pauseTime != 0) this.pauseTime
= this.time; }, pause: function() { if (this.pauseTime == 0) this.pauseTime = new Date().getTime(); }, resume: function() { if (this.pauseTime != 0)
this.time += new Date().getTime() - this.pauseTime; this.pauseTime = 0; }, show: function(s) { this.mark(s); $.debug(this.info); }}
Todd
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] simple profiling
Since I'm usually taking a lot more from this group than I'm giving back, I thought I'd offer this up if anyone might find it useful. It's a simple global object for tracking code execution time. (I discovered Firebug's
console.time
after I'd already written this. Oh well. This one can be used in any browser, anyway.) It has no depedencies on jQuery other than that I happened to use the $ namespace. Feel free to use/extend/modify to your liking.
Usage:$.timer.start();// some code$.timer.mark('optional label');// some code$.timer.pause();// some code to exclude from profiling$.timer.resume();// some code$.timer.mark();
// some code$.timer.show('optional label'); // displays a list of all marks to this point in an alert pop-upThe code:// usage: $.debug({x:x, y:y, z:z})$.debug = function(o) { var s = [];
for (var name in o) s.push(name + ': ' + o[name]) alert(s.join('\n'));}$.timer = { start: function() {
this.info = {}; this.count
= 0; this.pauseTime = 0; this.time = new Date().getTime(); }, mark: function(s) { var t = ((this.pauseTime == 0) ? new Date().getTime() : this.pauseTime) - this.time;
this.count++; if (s == undefined) s = 'mark ' + this.count; this.info[s] = '' + t + ' ms (' + (t/1000) + ' s)'; this.time = new Date().getTime(); if (this.pauseTime != 0) this.pauseTime
= this.time; }, pause: function() { if (this.pauseTime == 0) this.pauseTime = new Date().getTime(); }, resume: function() { if (this.pauseTime != 0)
this.time += new Date().getTime() - this.pauseTime; this.pauseTime = 0; }, show: function(s) { this.mark(s); $.debug(
this.info); }}
Todd
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] retaining checkbox state in IE
Hello,The following test code moves 2 form elements from one location in the DOM to another. Both elements retain their state just fine in FireFox, but in IE the current state of the checkbox is lost when the element is moved:
script$(function() { $('#btn').toggle( function() {$('#d1 input').appendTo('#d2');}, function() {$('#d2 input').appendTo('#d1');} );});/script
button id=btnmove/buttondiv id=d11:input type=checkbox/input type=text//divdiv id=d22:/div
Is there a preferred way to deal with this in jQuery? I can think of a number of ways to deal with it, but I would imagine this is a very common scenario, so I thought I'd ping the group before proceeding with my hack. :-)
Thanks,Todd
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] retaining checkbox state in IE
Thanks. Here's what I ended up doing, if anyone's curious. It would be slick if there were some event that gets fired when an element is moved to a different location in the DOM tree so I wouldn't have to keep track of that (there are a few places in my real code where that could happen), but this will have to do.
$(function() { $('[EMAIL PROTECTED]').click(function() { this.wasChecked = this.checked; }); function move(from, to) { return function() { $(from + ' input').appendTo(to);
$(to + ' [EMAIL PROTECTED]').each(function() {this.checked = this.wasChecked; }); } } $('#btn').toggle(move('#d1', '#d2'), move('#d2', '#d1'));
});On 10/12/06, Klaus Hartl [EMAIL PROTECTED] wrote:
Todd Menier schrieb: Hello, The following test code moves 2 form elements from one location in the DOM to another. Both elements retain their state just fine in FireFox, but in IE the current state of the checkbox is lost when the element is
moved: script $(function() { $('#btn').toggle( function() {$('#d1 input').appendTo('#d2');}, function() {$('#d2 input').appendTo('#d1');}
); }); /script button id=btnmove/button div id=d11:input type=checkbox/input type=text//div
div id=d22:/div Is there a preferred way to deal with this in jQuery? I can think of a number of ways to deal with it, but I would imagine this is a very
common scenario, so I thought I'd ping the group before proceeding with my hack. :-)Not sure, but I think it's nearly impossible to be handled by jQuerywithout much overhead, so this should be regarded as an IE bug to work
around...:$(function() { $('#btn').toggle( function() { var jqInput = $('#d1 input'); var checked = jqInput[0].checked; jqInput.appendTo('#d2')[0].checked = checked;
}, function() { ... } );});-- Klaus___jQuery mailing list
discuss@jquery.comhttp://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] downloading plugins?
Awesome, thanks so much!On 10/7/06, Mike Alsup [EMAIL PROTECTED] wrote: Todd,Just tack ?format=txt on to the end of the url.For example,http://jquery.com/dev/svn/plugins/form/form.js?format=txt Mike___jQuery mailing listdiscuss@jquery.comhttp://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
[jQuery] interesting syntax
Hello,I've been poking around a bit in the jQuery source code. It's been enlightening and has proven that I don't know as much about _javascript_ as I thought I did!Here's a pattern that occurs frequently that I'm really curious about:
new function() { // do stuff}Is the purpose of this just to provide local scope to the variables used? Is there an equivalant syntax that may be more common? I intuitively wouldn't even think the code inside the function would get executed unless the whole thing was proceeded by (), but obviously I'd be wrong. What's really surprising is that I couldn't find any information about this technique in a google search.
Just curious.Thanks,Todd
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] interesting syntax
Michael Geary [EMAIL PROTECTED] wrote: See if this helps: function Stuff() { // do stuff } var stuff1 = new Stuff(); // call the Stuff constructor
var stuff2 = new Stuff; // parens are optionalThanks, the aha! light just went on. It makes total sense now...I didn't know you could call a constructor without parens. It also makes sense that (function(){...})() might be a little more efficient since it's not creating an anonymous object in addition to the function itself, but I imagine that's pretty neglegable and that if you find the code more readable the other way, that's probably an acceptable trade-off.
Thanks to all who replied, it really cleared things up!Todd
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] tableSorter feedback requested!
Thanks for pointing that out, I did look at it when it came out but sort of forgot about it. I initially dismissed it because seemed like it had too many bells and whistles and was much too slow, but that cetainly could be a server issue and not a problem with the plugin. I'll give it another look and see if it's something that can be scaled down a bit to meet my needs. Thanks!ToddOn 8/31/06, Jörn Zaefferer [EMAIL PROTECTED] wrote: A great example of what I'm trying to acheive is the Rico LiveGrid: http://openrico.org/rico/livegrid.page. Very slick demo, but clunky to implement. I'd much prefer a jQuery pluin (or 2). You should take a look at Stefan Petres Live Grid Demo(!): http://interface.eyecon.ro/demos/grid.htmlSee his post for details: http://jquery.com/discuss/2006-August/009898/-- Jörn--Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer___jQuery mailing listdiscuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
