Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
multiple dynamic text fields
31 views
Skip to first unread message
hipa
Mar 4, 2012, 8:00:20 AM3/4/12
to
Hi
I posted this question in comp.lang.php but I got redirected here.
I have a page with an autocomplete text field. This works fine. But what
I actually want is adding more text fields with the same autocomplete
options. It must be an orderpage with multiple order lines.
If I choose option 2 from the drop down, 2 text fields are chown. That is
ok, but the autocomplete doesn't work.
But if I manually type "getuser.php?q=2" in a browser I get a page with 2
text boxes where the autocomplete does work.
I don't think I need to show here my complete autocomplete code because I
think this is not the point here.
When text boxes are generated dynamically is there an underlying id or
something given to it? Hope someone can help.
index.php
---------
<!DOCTYPE html>
<html lang="en" >
<head>
<meta charset="utf-8" />
<title>Test</title>
<link href="css/main.css" rel="stylesheet" type="text/css" />
<link href="css/jquery.autocomplete.css" rel="stylesheet"
type="text/css" />
<script type="text/javascript" src="js/jquery-1.5.2.min.js"></
script>
<script type="text/javascript" src="js/
jquery.autocomplete.pack.js"></script>
<script type="text/javascript" src="js/scriptpg.js"></script>
<script type="text/javascript">
function showUser(str)
{
if (str=="")
{
document.getElementById("txtHint").innerHTML="";
return;
}
if (window.XMLHttpRequest)
{// code for IE7+, Firefox, Chrome, Opera, Safari
xmlhttp=new XMLHttpRequest();
}
else
{// code for IE6, IE5
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4 && xmlhttp.status==200)
{
document.getElementById("txtHint").innerHTML=xmlhttp.responseText;
}
}
xmlhttp.open("GET","getuser.php?q="+str,true);
xmlhttp.send();
}
</script>
</head>
<body>
<form>
<select name="users" onchange="showUser(this.value)">
<option value="">Select a number:</option>
<option value="1">1</option>
<option value="2">2</option>
<option value="3">3</option>
<option value="4">4</option>
</select>
</form>
<br />
<div id="txtHint"><b>Number info will be listed here.</b></div>
</body>
</html>
---------------------------------------------------------------
getuser.php
-----------
...
<body>
<?php
$q=$_GET["q"];
for($i=1;$i<=$q;$i++){
echo "<input class='article' type='text' autocomplete='off'><br>";
}
?>
</body>
I posted this question in comp.lang.php but I got redirected here.
I have a page with an autocomplete text field. This works fine. But what
I actually want is adding more text fields with the same autocomplete
options. It must be an orderpage with multiple order lines.
If I choose option 2 from the drop down, 2 text fields are chown. That is
ok, but the autocomplete doesn't work.
But if I manually type "getuser.php?q=2" in a browser I get a page with 2
text boxes where the autocomplete does work.
I don't think I need to show here my complete autocomplete code because I
think this is not the point here.
When text boxes are generated dynamically is there an underlying id or
something given to it? Hope someone can help.
index.php
---------
<!DOCTYPE html>
<html lang="en" >
<head>
<meta charset="utf-8" />
<title>Test</title>
<link href="css/main.css" rel="stylesheet" type="text/css" />
<link href="css/jquery.autocomplete.css" rel="stylesheet"
type="text/css" />
<script type="text/javascript" src="js/jquery-1.5.2.min.js"></
script>
<script type="text/javascript" src="js/
jquery.autocomplete.pack.js"></script>
<script type="text/javascript" src="js/scriptpg.js"></script>
<script type="text/javascript">
function showUser(str)
{
if (str=="")
{
document.getElementById("txtHint").innerHTML="";
return;
}
if (window.XMLHttpRequest)
{// code for IE7+, Firefox, Chrome, Opera, Safari
xmlhttp=new XMLHttpRequest();
}
else
{// code for IE6, IE5
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4 && xmlhttp.status==200)
{
document.getElementById("txtHint").innerHTML=xmlhttp.responseText;
}
}
xmlhttp.open("GET","getuser.php?q="+str,true);
xmlhttp.send();
}
</script>
</head>
<body>
<form>
<select name="users" onchange="showUser(this.value)">
<option value="">Select a number:</option>
<option value="1">1</option>
<option value="2">2</option>
<option value="3">3</option>
<option value="4">4</option>
</select>
</form>
<br />
<div id="txtHint"><b>Number info will be listed here.</b></div>
</body>
</html>
---------------------------------------------------------------
getuser.php
-----------
...
<body>
<?php
$q=$_GET["q"];
for($i=1;$i<=$q;$i++){
echo "<input class='article' type='text' autocomplete='off'><br>";
}
?>
</body>
Jeff North
Mar 4, 2012, 10:33:29 PM3/4/12
to
On Sun, 4 Mar 2012 13:00:20 +0000 (UTC), in comp.lang.javascript hipa
<hipa.i...@telenet.be>
>| But if I manually type "getuser.php?q=2" in a browser I get a page with 2
>| text boxes where the autocomplete does work.
Your are running the php code directly. It has no DTD and therefore
the content is displayed in quirks mode. It is highly probable that
the browser doesn't understand the autocomplete attribute but is using
it's own autocomplete/autofill option.
Browsers have had this option for years so it would be interesting to
see if this attribute will override the browser setting (I doubt it
though).
>| I don't think I need to show here my complete autocomplete code because I
>| think this is not the point here.
>| When text boxes are generated dynamically is there an underlying id or
>| something given to it? Hope someone can help.
You need to specify this information when the element is created (see
getuser.php for alteration).
>|
>| index.php
>| ---------
Why are you mixing HTML5 and XHTML elements? For example, the link
element does not have a closing element, only in XHTML is the />
required.
In HTML5 you can shorten your script elements by using
<script></script> i.e.
<script src="js/jquery-1.5.2.min.js"></script>
<script src="js/jquery.autocomplete.pack.js"></script>
You are using jQuery which comes with it's own AJAX routines - why
re-invent the wheel?
echo "<input class='article' type='text' name='orders[]'><br>";
The name of the element is transmitted on form submit.
Because there are multiple entries then send the information as an
array and handle this server-side.
>| }
>| ?>
>| </body>
<hipa.i...@telenet.be>
<jivp14$brm$1...@speranza.aioe.org> wrote:
>| Hi
>|
>| I posted this question in comp.lang.php but I got redirected here.
>| I have a page with an autocomplete text field. This works fine. But what
>| I actually want is adding more text fields with the same autocomplete
>| options. It must be an orderpage with multiple order lines.
>| If I choose option 2 from the drop down, 2 text fields are chown. That is
>| ok, but the autocomplete doesn't work.
Maybe it doesn't work due to the attribute autocomplete='off'
>| Hi
>|
>| I posted this question in comp.lang.php but I got redirected here.
>| I have a page with an autocomplete text field. This works fine. But what
>| I actually want is adding more text fields with the same autocomplete
>| options. It must be an orderpage with multiple order lines.
>| If I choose option 2 from the drop down, 2 text fields are chown. That is
>| ok, but the autocomplete doesn't work.
>| But if I manually type "getuser.php?q=2" in a browser I get a page with 2
>| text boxes where the autocomplete does work.
the content is displayed in quirks mode. It is highly probable that
the browser doesn't understand the autocomplete attribute but is using
it's own autocomplete/autofill option.
Browsers have had this option for years so it would be interesting to
see if this attribute will override the browser setting (I doubt it
though).
>| I don't think I need to show here my complete autocomplete code because I
>| think this is not the point here.
>| When text boxes are generated dynamically is there an underlying id or
>| something given to it? Hope someone can help.
getuser.php for alteration).
>|
>| index.php
>| ---------
Why are you mixing HTML5 and XHTML elements? For example, the link
element does not have a closing element, only in XHTML is the />
required.
In HTML5 you can shorten your script elements by using
<script></script> i.e.
<script src="js/jquery-1.5.2.min.js"></script>
<script src="js/jquery.autocomplete.pack.js"></script>
You are using jQuery which comes with it's own AJAX routines - why
re-invent the wheel?
The name of the element is transmitted on form submit.
Because there are multiple entries then send the information as an
array and handle this server-side.
>| }
>| ?>
>| </body>
hipa
Mar 8, 2012, 1:14:52 PM3/8/12
to
Op Mon, 05 Mar 2012 14:33:29 +1100, schreef Jeff North:
> On Sun, 4 Mar 2012 13:00:20 +0000 (UTC), in comp.lang.javascript hipa
> <hipa.i...@telenet.be>
> <jivp14$brm$1...@speranza.aioe.org> wrote:
>
>>| Hi
>>|
>>| I posted this question in comp.lang.php but I got redirected here. | I
>>have a page with an autocomplete text field. This works fine. But what |
>>I actually want is adding more text fields with the same autocomplete |
>>options. It must be an orderpage with multiple order lines. | If I
>>choose option 2 from the drop down, 2 text fields are chown. That is |
>>ok, but the autocomplete doesn't work.
>
> Maybe it doesn't work due to the attribute autocomplete='off'
If I remove the autocomplete='off', the result is the same.
>>| But if I manually type "getuser.php?q=2" in a browser I get a page
>>with 2 | text boxes where the autocomplete does work.
>
> Your are running the php code directly. It has no DTD and therefore the
> content is displayed in quirks mode. It is highly probable that the
> browser doesn't understand the autocomplete attribute but is using it's
> own autocomplete/autofill option.
>
> Browsers have had this option for years so it would be interesting to
> see if this attribute will override the browser setting (I doubt it
> though).
Is have a DTD, but I didn't show it in this post. See the three dots
(...).
On the other hand, my autocomplete gets the results from a postgres
database. This does work...
>>| I don't think I need to show here my complete autocomplete code
>>because I | think this is not the point here.
>>| When text boxes are generated dynamically is there an underlying id or
>>| something given to it? Hope someone can help.
>
> You need to specify this information when the element is created (see
> getuser.php for alteration).
When I do it like this:
for($i=1;$i<=$q;$i++){
echo "<input id='article" . $i . "' name='article" . $i . "'
type='text'>";
}
The same happens. It does work if I manually type "getuser.php?q=2" in a
browser. But not when I open the page from the index page.
> On Sun, 4 Mar 2012 13:00:20 +0000 (UTC), in comp.lang.javascript hipa
> <hipa.i...@telenet.be>
> <jivp14$brm$1...@speranza.aioe.org> wrote:
>
>>| Hi
>>|
>>| I posted this question in comp.lang.php but I got redirected here. | I
>>have a page with an autocomplete text field. This works fine. But what |
>>I actually want is adding more text fields with the same autocomplete |
>>options. It must be an orderpage with multiple order lines. | If I
>>choose option 2 from the drop down, 2 text fields are chown. That is |
>>ok, but the autocomplete doesn't work.
>
> Maybe it doesn't work due to the attribute autocomplete='off'
>>| But if I manually type "getuser.php?q=2" in a browser I get a page
>>with 2 | text boxes where the autocomplete does work.
>
> Your are running the php code directly. It has no DTD and therefore the
> content is displayed in quirks mode. It is highly probable that the
> browser doesn't understand the autocomplete attribute but is using it's
> own autocomplete/autofill option.
>
> Browsers have had this option for years so it would be interesting to
> see if this attribute will override the browser setting (I doubt it
> though).
(...).
On the other hand, my autocomplete gets the results from a postgres
database. This does work...
>>| I don't think I need to show here my complete autocomplete code
>>because I | think this is not the point here.
>>| When text boxes are generated dynamically is there an underlying id or
>>| something given to it? Hope someone can help.
>
> You need to specify this information when the element is created (see
> getuser.php for alteration).
for($i=1;$i<=$q;$i++){
echo "<input id='article" . $i . "' name='article" . $i . "'
type='text'>";
}
The same happens. It does work if I manually type "getuser.php?q=2" in a
browser. But not when I open the page from the index page.
Jeff North
Mar 9, 2012, 1:38:23 AM3/9/12
to
On Thu, 8 Mar 2012 18:14:52 +0000 (UTC), in comp.lang.javascript hipa
<hipa.i...@telenet.be>
In your getuser.php file remove all the fluff that is before <?php and
after ?>
See if that helps.
[snip]
<hipa.i...@telenet.be>
after ?>
See if that helps.
[snip]
hipa
Mar 9, 2012, 1:46:34 PM3/9/12
to
Op Fri, 09 Mar 2012 17:38:23 +1100, schreef Jeff North:
> In your getuser.php file remove all the fluff that is before <?php and
> after ?>
>
> See if that helps.
Still the same.
> In your getuser.php file remove all the fluff that is before <?php and
> after ?>
>
> See if that helps.
Jeff North
Mar 10, 2012, 1:19:46 AM3/10/12
to
On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript hipa
<hipa.i...@telenet.be>
The only think left is there might be an error in the scriptpg.js file
which is causing the non-execution of all the scripts on the page.
<hipa.i...@telenet.be>
which is causing the non-execution of all the scripts on the page.
hipa
Mar 11, 2012, 9:55:13 AM3/11/12
to
Op Sat, 10 Mar 2012 17:19:46 +1100, schreef Jeff North:
I found the problem.
I tested it while adding text fields true javascript, that also didn't
work. That got me thinking.
Everytime I add a text field I need to append .autocomplete.
When the autocomplete gets set up when the page loads it will not work on
a text field that is dynamically added.
So this is what I do.
$("#addButton").click(function () {
var newTextBoxDiv = $(document.createElement('div')).attr("id",
'TextBoxDiv' + counter);
newTextBoxDiv.html('<label>Article '+ counter +':</label><input
type="text" name="article' + counter + '" id="article' + counter + '">');
newTextBoxDiv.appendTo("#TextBoxesGroup");
$('#article' + counter + '').autocomplete('datapg.php?
mode=sqlarticle', {width: 200, max: 10});
counter++;
});
I tested it while adding text fields true javascript, that also didn't
work. That got me thinking.
Everytime I add a text field I need to append .autocomplete.
When the autocomplete gets set up when the page loads it will not work on
a text field that is dynamically added.
So this is what I do.
$("#addButton").click(function () {
var newTextBoxDiv = $(document.createElement('div')).attr("id",
'TextBoxDiv' + counter);
newTextBoxDiv.html('<label>Article '+ counter +':</label><input
type="text" name="article' + counter + '" id="article' + counter + '">');
newTextBoxDiv.appendTo("#TextBoxesGroup");
$('#article' + counter + '').autocomplete('datapg.php?
mode=sqlarticle', {width: 200, max: 10});
counter++;
});
David Mark
Mar 12, 2012, 11:16:17 PM3/12/12
to
On Mar 11, 9:55 am, hipa <hipa.inva...@telenet.be> wrote:
> Op Sat, 10 Mar 2012 17:19:46 +1100, schreef Jeff North:
>
> > On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript hipa
> > <hipa.inva...@telenet.be>
> Op Sat, 10 Mar 2012 17:19:46 +1100, schreef Jeff North:
>
> > On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript hipa
> > <jjdj6a$5e...@speranza.aioe.org> wrote:
>
> >>| Op Fri, 09 Mar 2012 17:38:23 +1100, schreef Jeff North: |
> >>| > In your getuser.php file remove all the fluff that is before <?php
> >>and | > after ?>
> >>| >
> >>| > See if that helps.
> >>|
> >>| Still the same.
>
> > The only think left is there might be an error in the scriptpg.js file
> > which is causing the non-execution of all the scripts on the page.
>
> I found the problem.
A problem.
>
> >>| Op Fri, 09 Mar 2012 17:38:23 +1100, schreef Jeff North: |
> >>| > In your getuser.php file remove all the fluff that is before <?php
> >>and | > after ?>
> >>| >
> >>| > See if that helps.
> >>|
> >>| Still the same.
>
> > The only think left is there might be an error in the scriptpg.js file
> > which is causing the non-execution of all the scripts on the page.
>
> I found the problem.
> I tested it while adding text fields true javascript, that also didn't
> work. That got me thinking.
scripts, use good/bad qualifiers (e.g. jQuery contains bad
Javascript).
> Everytime I add a text field I need to append .autocomplete.
> When the autocomplete gets set up when the page loads it will not work on
> a text field that is dynamically added.
> So this is what I do.
>
> $("#addButton").click(function () {
Do you really need more than one click listener for this button?
> var newTextBoxDiv = $(document.createElement('div')).attr("id",
> 'TextBoxDiv' + counter);
newTextBoxDiv.id = 'TextBoxDiv' + counter;
Yes, it's taller, but yours is wider. Also, code in listeners needs to
be as efficient as possible as they react to user input. The "true"
version will be about a hundred times faster (and avoids the
mysterious and misunderstood "attr" method). Far easier to read
too. ;)
> newTextBoxDiv.html('<label>Article '+ counter +':</label><input
> type="text" name="article' + counter + '" id="article' + counter + '">');
> newTextBoxDiv.appendTo("#TextBoxesGroup");
document.getElementById('TextBoxesGroup').appendChild(newTextBoxDiv);
Feel free to write a wrapper for gEBI if you are worried about typing
(shouldn't be). Will just slow things down, but not nearly to the
extent that jQuery does. It's one function call vs. hundreds and
function calls are expensive.
> $('#article' + counter + '').autocomplete('datapg.php?
> mode=sqlarticle', {width: 200, max: 10});
jQuery is highly suspect (it's too slow, not cross-browser and has a
terrible DOM abstraction layer). If that's unacceptable, hand this
part off to somebody else (preferably not a jQuery enthusiast).
> counter++;
That works. :)
hipa
Mar 13, 2012, 4:08:38 PM3/13/12
to
Op Mon, 12 Mar 2012 20:16:17 -0700, schreef David Mark:
> On Mar 11, 9:55 am, hipa <hipa.inva...@telenet.be> wrote:
>> Op Sat, 10 Mar 2012 17:19:46 +1100, schreef Jeff North:
>>
>> > On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript hipa
>> > <hipa.inva...@telenet.be>
>> > <jjdj6a$5e...@speranza.aioe.org> wrote:
>>
>> >>| Op Fri, 09 Mar 2012 17:38:23 +1100, schreef Jeff North: | | > In
>> >>your getuser.php file remove all the fluff that is before <?php and |
>> >>> after ?>
>> >>| >
>> >>| > See if that helps.
>> >>|
>> >>| Still the same.
>>
>> > The only think left is there might be an error in the scriptpg.js
>> > file which is causing the non-execution of all the scripts on the
>> > page.
>>
>> I found the problem.
>
> A problem.
>
>> I tested it while adding text fields true javascript, that also didn't
>> work. That got me thinking.
>
> There is no such thing as "true Javascript". If you want to pigeonhole
> scripts, use good/bad qualifiers (e.g. jQuery contains bad Javascript).
Can you explain this one?
>> Everytime I add a text field I need to append .autocomplete. When the
>> autocomplete gets set up when the page loads it will not work on a text
>> field that is dynamically added. So this is what I do.
>>
>> $("#addButton").click(function () {
>
> document.getElementById('addButton').onclick = function() {
Nothing happens when I click the button.
> Do you really need more than one click listener for this button?
>
>> var newTextBoxDiv =
>> $(document.createElement('div')).attr("id",
>> 'TextBoxDiv' + counter);
>
>
> var newTextBoxDiv = document.createElement('div'); newTextBoxDiv.id =
> 'TextBoxDiv' + counter;
Also nothing happens when the button is clicked.
> Yes, it's taller, but yours is wider. Also, code in listeners needs to
> be as efficient as possible as they react to user input. The "true"
> version will be about a hundred times faster (and avoids the mysterious
> and misunderstood "attr" method). Far easier to read too. ;)
>
>
>> newTextBoxDiv.html('<label>Article '+ counter
>> +':</label><input
>> type="text" name="article' + counter + '" id="article' + counter +
>> '">');
>
> newTextBoxDiv.innerHTML = ...
>
>> newTextBoxDiv.appendTo("#TextBoxesGroup");
>
> document.getElementById('TextBoxesGroup').appendChild(newTextBoxDiv);
>
> Feel free to write a wrapper for gEBI if you are worried about typing
> (shouldn't be). Will just slow things down, but not nearly to the extent
> that jQuery does. It's one function call vs. hundreds and function calls
> are expensive.
>
How is that?
And why is jQuery so bad? I find the autocomplete function pretty
handy :-)
>> $('#article' + counter + '').autocomplete('datapg.php?
>> mode=sqlarticle', {width: 200, max: 10});
>
> You'd be better off with no widget at all as anything built atop jQuery
> is highly suspect (it's too slow, not cross-browser and has a terrible
> DOM abstraction layer). If that's unacceptable, hand this part off to
> somebody else (preferably not a jQuery enthusiast).
Oh you explained it :-)
How would someone else do it. I could off course also just cut the jQuery
part.
>
>> counter++;
>
> That works. :)
Thanks for the reply!
> On Mar 11, 9:55 am, hipa <hipa.inva...@telenet.be> wrote:
>> Op Sat, 10 Mar 2012 17:19:46 +1100, schreef Jeff North:
>>
>> > On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript hipa
>> > <hipa.inva...@telenet.be>
>> > <jjdj6a$5e...@speranza.aioe.org> wrote:
>>
>> >>| Op Fri, 09 Mar 2012 17:38:23 +1100, schreef Jeff North: | | > In
>> >>your getuser.php file remove all the fluff that is before <?php and |
>> >>> after ?>
>> >>| >
>> >>| > See if that helps.
>> >>|
>> >>| Still the same.
>>
>> > The only think left is there might be an error in the scriptpg.js
>> > file which is causing the non-execution of all the scripts on the
>> > page.
>>
>> I found the problem.
>
> A problem.
>
>> I tested it while adding text fields true javascript, that also didn't
>> work. That got me thinking.
>
> There is no such thing as "true Javascript". If you want to pigeonhole
> scripts, use good/bad qualifiers (e.g. jQuery contains bad Javascript).
>> Everytime I add a text field I need to append .autocomplete. When the
>> autocomplete gets set up when the page loads it will not work on a text
>> field that is dynamically added. So this is what I do.
>>
>> $("#addButton").click(function () {
>
> document.getElementById('addButton').onclick = function() {
> Do you really need more than one click listener for this button?
>
>> var newTextBoxDiv =
>> $(document.createElement('div')).attr("id",
>> 'TextBoxDiv' + counter);
>
>
> var newTextBoxDiv = document.createElement('div'); newTextBoxDiv.id =
> 'TextBoxDiv' + counter;
> Yes, it's taller, but yours is wider. Also, code in listeners needs to
> be as efficient as possible as they react to user input. The "true"
> version will be about a hundred times faster (and avoids the mysterious
> and misunderstood "attr" method). Far easier to read too. ;)
>
>
>> newTextBoxDiv.html('<label>Article '+ counter
>> +':</label><input
>> type="text" name="article' + counter + '" id="article' + counter +
>> '">');
>
> newTextBoxDiv.innerHTML = ...
>
>> newTextBoxDiv.appendTo("#TextBoxesGroup");
>
> document.getElementById('TextBoxesGroup').appendChild(newTextBoxDiv);
>
> Feel free to write a wrapper for gEBI if you are worried about typing
> (shouldn't be). Will just slow things down, but not nearly to the extent
> that jQuery does. It's one function call vs. hundreds and function calls
> are expensive.
>
And why is jQuery so bad? I find the autocomplete function pretty
handy :-)
>> $('#article' + counter + '').autocomplete('datapg.php?
>> mode=sqlarticle', {width: 200, max: 10});
>
> You'd be better off with no widget at all as anything built atop jQuery
> is highly suspect (it's too slow, not cross-browser and has a terrible
> DOM abstraction layer). If that's unacceptable, hand this part off to
> somebody else (preferably not a jQuery enthusiast).
How would someone else do it. I could off course also just cut the jQuery
part.
>
>> counter++;
>
> That works. :)
Thanks for the reply!
David Mark
Mar 13, 2012, 6:36:23 PM3/13/12
to
together:
document.getElementById('addButton').onclick = function() {
};
>
> > Feel free to write a wrapper for gEBI if you are worried about typing
> > (shouldn't be). Will just slow things down, but not nearly to the extent
> > that jQuery does. It's one function call vs. hundreds and function calls
> > are expensive.
>
> How is that?
Because jQuery is very poorly written. I recently posted some
>
> > Feel free to write a wrapper for gEBI if you are worried about typing
> > (shouldn't be). Will just slow things down, but not nearly to the extent
> > that jQuery does. It's one function call vs. hundreds and function calls
> > are expensive.
>
> How is that?
examples of this on the JSPerf site, pitting one-liner cross-browser
functions vs. My Library (a four-year-old library) vs. jQuery.
Unbelievably, jQuery was consistently 10-100 times slower at basic
tasks. Attaching listeners was particularly slow (not to mention
awkward). Not long after, they copied my concise on/off methods, but
I doubt that syntactic sugar improved their performance any. :(
http://jsperf.com/browse/david-mark
http://jsperf.com/adding-and-removing-listeners-part-2
> And why is jQuery so bad? I find the autocomplete function pretty
> handy :-)
more than queries and "event normalization" (quotes indicate there's
no "normal" for events like change). Hell, they don't even allow for
setting the - this - object without calling an additional "proxy"
function. :(
>
> >> $('#article' + counter + '').autocomplete('datapg.php?
> >> mode=sqlarticle', {width: 200, max: 10});
>
> > You'd be better off with no widget at all as anything built atop jQuery
> > is highly suspect (it's too slow, not cross-browser and has a terrible
> > DOM abstraction layer). If that's unacceptable, hand this part off to
> > somebody else (preferably not a jQuery enthusiast).
>
> Oh you explained it :-)
> How would someone else do it. I could off course also just cut the jQuery
> part.
of some sort, you will need something along the lines of an
autocomplete/suggest. Somebody more familiar with DOM scripting
(particularly keyboard handling) should be able to bang one out in a
day or two.
A canned widget for jQuery is going to be hampered by jQuery and is
likely to include lots of unneeded features as those projects aim to
appeal to as many users as possible. This is because of ego and a
myth that the presence of lots of users ensures a bug-free script (all
those eyes and all). :)
>
>
>
> >> counter++;
>
> > That works. :)
>
> Thanks for the reply!
Andrew Poulos
Mar 13, 2012, 7:51:38 PM3/13/12
to
On 14/03/2012 9:36 AM, David Mark wrote:
> Because jQuery is very poorly written. I recently posted some
> examples of this on the JSPerf site, pitting one-liner cross-browser
> functions vs. My Library (a four-year-old library) vs. jQuery.
> Unbelievably, jQuery was consistently 10-100 times slower at basic
> tasks. Attaching listeners was particularly slow (not to mention
> awkward). Not long after, they copied my concise on/off methods, but
> I doubt that syntactic sugar improved their performance any. :(
>
> http://jsperf.com/browse/david-mark
> http://jsperf.com/adding-and-removing-listeners-part-2
1. Its unbelievable that jquery is so much slower in the 'setting the
> Because jQuery is very poorly written. I recently posted some
> examples of this on the JSPerf site, pitting one-liner cross-browser
> functions vs. My Library (a four-year-old library) vs. jQuery.
> Unbelievably, jQuery was consistently 10-100 times slower at basic
> tasks. Attaching listeners was particularly slow (not to mention
> awkward). Not long after, they copied my concise on/off methods, but
> I doubt that syntactic sugar improved their performance any. :(
>
> http://jsperf.com/browse/david-mark
> http://jsperf.com/adding-and-removing-listeners-part-2
style attribute' test. It completed about 145K operations/sec versus
3.2M operations/sec for the cross browser way. The cross browser way is
more that 22 times faster!
2. Some of the tests give a script error when run in Firefox 10.0.2.
3. Where are the jquery users to give a different view of the tests/results?
Andrew Poulos
David Mark
Mar 13, 2012, 9:12:22 PM3/13/12
to
>
> 3. Where are the jquery users to give a different view of the tests/results?
>
group as this group sees right through his BS. There's a whole
generation of JS programmers who see jQuery developers as
"everyone" (as in U think UR smarter than everyone) and CLJ as a
Google Grouyp with "just a few bitter old users". And oddly enough,
they do favor IRC. :)
David Mark
Mar 13, 2012, 9:55:11 PM3/13/12
to
On Mar 13, 7:51 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
pertinent info) on loading the first test (and only the first time).
The site doesn't seem to be recording results for FF 10 either.
Here is a typical result from FF 10:-
Chrome 13.0.782 2,885,834 898,102 78,951 1
Chrome 14.0.835 1,622,298 434,627 25,368 3
Chrome 15.0.874 2,450,642 807,696 68,140 3
Chrome 17.0.963 3,155,691 1,474,550 101,658 3
Firefox 6.0.2 1,129,588 435,858 32,674 3
Firefox 8.0 3,135,401 913,051 54,460 2
Firefox Beta 12.0a2 1,874,259 500,396 49,073 1
IE 9.0 720,506 375,765 3,689 1
Opera 11.51 340,953 201,199 2,333 1
Safari 5.1.2 6,167,981 1,614,097 114,380 1
http://jsperf.com/removing-element-attributes-optimized
Should be apparent which column is which. Safari 5 is over 6
*million* attributes removed for the cross-browser rendition. My
Library comes in second with over 1.6 million. jQuery is just over
100 thousand. Think of those numbers in terms of dollars. Not just
for effect, but those seeking to create the next "Facebook Killer" (or
a basic Website that is responsive on battery-powered mobile devices)
should realize that the jQuery authors have been asleep at the switch
for a long time (and this is the latest version, after numerous well-
publicized "optimizations" that reportedly increased performance
hundreds of times over).
Then there's the long since conceded point that jQuery is terrible at
attribute manipulation (i.e. it comes up with a lot of wrong
answers). Granted, most jQuery users don't understand that issue
(which is largely confined to IE 6/7) or how it can affect them.
And, of course, most of the jQuery examples are neither concise nor
easily understood at a glance.
Meanwhile, the "fast, concise, etc." line continues to be parroted by
neophytes who never tried anything else. Show them tests like that
and they'll show you an even less readable example (a lot of $.fn.*
calls) that is slightly faster. Then they'll blither about early
optimization, saving developer time, etc. Of course, a site is
developed once but used many times, but then Web developers generally
have disdain for their users and consider their time far more
valuable. Add up all of the time spent "upgrading", retesting,
redeploying, etc., plus the inevitable cost of pissing off users with
slow or broken pages and all of those "arguments" fall apart.
So how does this please so many? Marketing, plus pigeonholing all
scripts as either "perfect" (seen as impossible) or "imperfect" (all
scripts then) and mistaking empirical evidence (e.g. works today in my
installed browsers!) for proofs. Looking at the code is seen as a
waste of time as how many users are going to look at the code? :)
I've been saying the same thing since 2007 (when I first encountered
the script and before I wrote the "competing" library) while most
others took a "give it a few years and they'll get it right" stance
(which I imagine most regret at this point).
It was never about writing the most efficient and "perfect" code or
patching the most "cross-browser" issues. It's always been about the
reaction I got from the authors (and their fans) after that first
review. That alone told me they'd never get anywhere (and the same
for Prototype, MooTools, etc.) On the contrary, many argue that
convincing lots of beginners to adopt it as a "standard" is getting
somewhere, but it's not anywhere I ever wanted to go and hasn't
improved the code logic or performance a whit.
Seeing them in action (acting on tips I sent over) further convinced
me that they just didn't understand what they were doing and were
virulently opposed to learning (too busy bringing lousy code to
market).
Andrew Poulos
Mar 14, 2012, 12:05:37 AM3/14/12
to
On 14/03/2012 12:55 PM, David Mark wrote:
> On Mar 13, 7:51 pm, Andrew Poulos<ap_p...@hotmail.com> wrote:
>> On 14/03/2012 9:36 AM, David Mark wrote:
>>
>>> Because jQuery is very poorly written. I recently posted some
>>> examples of this on the JSPerf site, pitting one-liner cross-browser
>>> functions vs. My Library (a four-year-old library) vs. jQuery.
>>> Unbelievably, jQuery was consistently 10-100 times slower at basic
>>> tasks. Attaching listeners was particularly slow (not to mention
>>> awkward). Not long after, they copied my concise on/off methods, but
>>> I doubt that syntactic sugar improved their performance any. :(
>>
>>> http://jsperf.com/browse/david-mark
>>> http://jsperf.com/adding-and-removing-listeners-part-2
>>
>> 1. Its unbelievable that jquery is so much slower in the 'setting the
>> style attribute' test. It completed about 145K operations/sec versus
>> 3.2M operations/sec for the cross browser way. The cross browser way is
>> more that 22 times faster!
>>
>> 2. Some of the tests give a script error when run in Firefox 10.0.2.
>
> I only saw an error caught and reported in a pink box (with no
> pertinent info) on loading the first test (and only the first time).
> The site doesn't seem to be recording results for FF 10 either.
The error with no pertinent info comes in Firefox 10.0.2 while its
> On Mar 13, 7:51 pm, Andrew Poulos<ap_p...@hotmail.com> wrote:
>> On 14/03/2012 9:36 AM, David Mark wrote:
>>
>>> Because jQuery is very poorly written. I recently posted some
>>> examples of this on the JSPerf site, pitting one-liner cross-browser
>>> functions vs. My Library (a four-year-old library) vs. jQuery.
>>> Unbelievably, jQuery was consistently 10-100 times slower at basic
>>> tasks. Attaching listeners was particularly slow (not to mention
>>> awkward). Not long after, they copied my concise on/off methods, but
>>> I doubt that syntactic sugar improved their performance any. :(
>>
>>> http://jsperf.com/browse/david-mark
>>> http://jsperf.com/adding-and-removing-listeners-part-2
>>
>> 1. Its unbelievable that jquery is so much slower in the 'setting the
>> style attribute' test. It completed about 145K operations/sec versus
>> 3.2M operations/sec for the cross browser way. The cross browser way is
>> more that 22 times faster!
>>
>> 2. Some of the tests give a script error when run in Firefox 10.0.2.
>
> I only saw an error caught and reported in a pink box (with no
> pertinent info) on loading the first test (and only the first time).
> The site doesn't seem to be recording results for FF 10 either.
running the 'My Library' tests on:
Removing Element Attributes Optimized
Setting inner HTML of DIV (2)
And then there's this error
Has Class (1)
ReferenceError: MJ is not defined.
fileName: http://jsperf.com/bind-jquery-vs-addevent-mjlib/3
lineNumber: 1
[Enough testing for now]
> Here is a typical result from FF 10:-
>
> Chrome 13.0.782 2,885,834 898,102 78,951 1
> Chrome 14.0.835 1,622,298 434,627 25,368 3
> Chrome 15.0.874 2,450,642 807,696 68,140 3
> Chrome 17.0.963 3,155,691 1,474,550 101,658 3
> Firefox 6.0.2 1,129,588 435,858 32,674 3
> Firefox 8.0 3,135,401 913,051 54,460 2
> Firefox Beta 12.0a2 1,874,259 500,396 49,073 1
> IE 9.0 720,506 375,765 3,689 1
> Opera 11.51 340,953 201,199 2,333 1
> Safari 5.1.2 6,167,981 1,614,097 114,380 1
>
> http://jsperf.com/removing-element-attributes-optimized
>
> Should be apparent which column is which. Safari 5 is over 6
> *million* attributes removed for the cross-browser rendition. My
> Library comes in second with over 1.6 million. jQuery is just over
> 100 thousand. Think of those numbers in terms of dollars. Not just
> for effect, but those seeking to create the next "Facebook Killer" (or
> a basic Website that is responsive on battery-powered mobile devices)
> should realize that the jQuery authors have been asleep at the switch
> for a long time (and this is the latest version, after numerous well-
> publicized "optimizations" that reportedly increased performance
> hundreds of times over).
is why my computer theorist friends who can write in a huge number of
languages believe that jQuery serves them well and can't see any issues.
Each app they build appears to be well received.
Andrew Poulos
David Mark
Mar 14, 2012, 12:38:50 AM3/14/12
to
It's an mjlib (whatever that is) test (and not mine).
I thought I added a comment to that to ask that it be deleted from my
tests. How it got there is a bit of a mystery; perhaps a revision that
I abandoned.
David Mark
Mar 14, 2012, 12:56:55 AM3/14/12
to
http://jsperf.com/setting-inner-html-of-div/5
http://jsperf.com/setting-inner-html-of-div
None of these display that pink box on load and none of them indicate
any errors with My Library (or anything else at the moment) in FF
10.0.2 (Windows 7).
I saw the blank error once on load and it didn't indicate anything
wrong with My Library (which subsequently passed its tests). I
suspect I had an old copy of the JSPerf script(s) in my cache that
didn't agree with the current page(s). That can happen if cache
settings are incorrect on the server.
David Mark
Mar 14, 2012, 1:06:49 AM3/14/12
to
library name here]" argument many times. Ask how what browsers they
tested and they'll say the ones that the library authors told them
were safe (per the friendly browser icons). Ask if they tested
anything else (like an older, less capable browser) and they'll say it
doesn't matter to them. Ask if they think that testing exclusively
where the results are a foregone conclusion indicates anything about
future environments and they'll say nobody's perfect, nothing is
assured, etc. It's like there's no grey area; everything is black and
white. If everything is assumed to fail in the future, then there's
really nothing to debate.
But history shows that cross-browser scripts give you the best chance
at avoiding costly rewrites. And even without the history, common
sense should be enough to see through the above "arguments".
> Each app they build appears to be well received.
>
scripting is turned on, etc.? :)
David Mark
Mar 14, 2012, 1:11:42 AM3/14/12
to
David Mark
Mar 14, 2012, 1:49:20 AM3/14/12
to
On Mar 14, 12:38 am, David Mark <dmark.cins...@gmail.com> wrote:
updated 11) with that library either. I think you may have an FF plug-
in issue (JSPerf uses both Quicktime and Flash). Disable other plug-
ins and see if that clears up the problem.
Andrew Poulos
Mar 14, 2012, 2:05:42 AM3/14/12
to
and the errors no longer appear.
Testing in Firefox 11.0 on Windows Server 2008 / Vista
jQuery 10,626 ops/sec
My Lib OO 69,459 ops/sec
My Lib 109.413 ops/sec
Cross Br 157,055 ops/sec
Who'd a thunk that jQuery would be so far behind!
Andrew Poulos
Andrew Poulos
Mar 14, 2012, 2:07:08 AM3/14/12
to
>> Each app they build appears to be well received.
>
> Based on what? A feedback form that only works if jQuery cooperates,
> scripting is turned on, etc.? :)
Andrew Poulos
David Mark
Mar 14, 2012, 3:23:35 AM3/14/12
to
>
> Testing in Firefox 11.0 on Windows Server 2008 / Vista
>
> jQuery 10,626 ops/sec
> My Lib OO 69,459 ops/sec
> My Lib 109.413 ops/sec
> Cross Br 157,055 ops/sec
>
> Who'd a thunk that jQuery would be so far behind!
years. :)
I seem to recall a lot of arguments back in 2007 about how jQuery was
open source and the whole world was behind them and surely it'll get
better, and blah, blah, blah. Didn't work for jQuery or Prototype or
Dojo or any of them. The number of developers involved is not an
indication of present or future quality. It's just a meaningless
metric. Even more irrelevant is the number of users. I once had a guy
tell me Ext JS couldn't have bugs as it was x years old with y number
of users, etc. What can you say to something like that? :(
Still, if the authors/marketers had acted like rational adults and
weren't lying through their teeth about their capabilities and their
script's alleged benefits, I would have been much easier on them.
Wasn't long after the first review that Resig posted his missive about
avoiding CLJ at all costs because it was filled with unfair jerks (or
whatever). The fact that most of his users bought that for years gives
you an idea of the sort of "developers" something like jQuery attracts
(similar to the type of "investors" that Ponzi schemes and buy-real-
estate-for-no-money-down books attract). Some things never change.
Even funnier is that some of these pissed off users/friends/marketers
of jQuery posted links to the reviews to demonstrate... something.
Seems they wanted people to feel sorry for them; of course, they only
demonstrated their own naivete. A more rational explanation for this
bonus coverage is that they were angry because they'd invested time
and money in jQuery, plastered it all over their CV and were worried
about diminished earning potential. Somehow, they want to push the
idea that I'm the angry one; but, oddly enough, I'm quite happy about
jQuery's continuous buffoonery (it's certainly paid to sell it
short). :)
Recently some jackass in the Ext JS forums "fended off" a scathing
review of Sencha Touch by posting a link to a years-old jQuery review.
No answer to the many troubling issues raised in the review, other
than he didn't understand a word of it (!), just a painfully
transparent misdirection. A couple of people responded that they would
like to see better handling of feedback by the company and were buried
in a bunch of marketing babble (e.g. we just love *constructive*
feedback!). They were then accused of being "sock puppets" (as if I am
the only one on the planet that sees through their BS). And seeing all
of the echos of Usenet posts on various Websites made them wonder why
I was going to so much trouble to smear their good names. :(
Yet there are still ostensibly intelligent, experienced (in other
languages and disciplines) programmers out there that fall for this
stuff. I mean, look at all of those happy users; can't be bad. Still,
give them alternatives and they will figure it out soon enough.
David Mark
Mar 14, 2012, 3:28:51 AM3/14/12
to
an avalanche of evidence out there for those who look past the blogs
and cartoons.
>
> >> Each app they build appears to be well received.
>
> > Based on what? A feedback form that only works if jQuery cooperates,
> > scripting is turned on, etc.? :)
>
> Its not a scientific response. The client's happy so I guess they are too.
>
the impact of something like jQuery on their site. One thing is for
sure, it can only get in the way of sales (by excluding visitors) as
it's sure not going to generate any. ;)
hipa
Mar 14, 2012, 5:56:02 PM3/14/12
to
Op Tue, 13 Mar 2012 15:36:23 -0700, schreef David Mark:
Yes I know that, I looked over the closing parentheses at the end. Works
now, thanks!
>
>> > Feel free to write a wrapper for gEBI if you are worried about typing
>> > (shouldn't be). Will just slow things down, but not nearly to the
>> > extent that jQuery does. It's one function call vs. hundreds and
>> > function calls are expensive.
>>
>> How is that?
>
> Because jQuery is very poorly written. I recently posted some examples
> of this on the JSPerf site, pitting one-liner cross-browser functions
> vs. My Library (a four-year-old library) vs. jQuery. Unbelievably,
> jQuery was consistently 10-100 times slower at basic tasks. Attaching
> listeners was particularly slow (not to mention awkward). Not long
> after, they copied my concise on/off methods, but I doubt that syntactic
> sugar improved their performance any. :(
>
> http://jsperf.com/browse/david-mark
> http://jsperf.com/adding-and-removing-listeners-part-2
>
I'll take a look at this one, but have the feeling that you are far more
advanced than me :-)
>> And why is jQuery so bad? I find the autocomplete function pretty handy
>> :-)
>
> I don't believe that's a jQuery function. Alone, jQuery does little more
> than queries and "event normalization" (quotes indicate there's no
> "normal" for events like change). Hell, they don't even allow for
> setting the - this - object without calling an additional "proxy"
> function. :(
>
>
>> >> $('#article' + counter + '').autocomplete('datapg.php?
>> >> mode=sqlarticle', {width: 200, max: 10});
>>
>> > You'd be better off with no widget at all as anything built atop
>> > jQuery is highly suspect (it's too slow, not cross-browser and has a
>> > terrible DOM abstraction layer). If that's unacceptable, hand this
>> > part off to somebody else (preferably not a jQuery enthusiast).
>>
>> Oh you explained it :-)
>> How would someone else do it. I could off course also just cut the
>> jQuery part.
>
> Well, if you have thousands of rows that need to populate a dropdown of
> some sort, you will need something along the lines of an
> autocomplete/suggest. Somebody more familiar with DOM scripting
> (particularly keyboard handling) should be able to bang one out in a day
> or two.
That sounds logical, when thousands of rows need to populate a dropdown.
I kept this in mind, my db isn't very big. It can/will grow, but not to
the extend of thousands and thousands of records.
now, thanks!
>
>> > Feel free to write a wrapper for gEBI if you are worried about typing
>> > (shouldn't be). Will just slow things down, but not nearly to the
>> > extent that jQuery does. It's one function call vs. hundreds and
>> > function calls are expensive.
>>
>> How is that?
>
> Because jQuery is very poorly written. I recently posted some examples
> of this on the JSPerf site, pitting one-liner cross-browser functions
> vs. My Library (a four-year-old library) vs. jQuery. Unbelievably,
> jQuery was consistently 10-100 times slower at basic tasks. Attaching
> listeners was particularly slow (not to mention awkward). Not long
> after, they copied my concise on/off methods, but I doubt that syntactic
> sugar improved their performance any. :(
>
> http://jsperf.com/browse/david-mark
> http://jsperf.com/adding-and-removing-listeners-part-2
>
advanced than me :-)
>> And why is jQuery so bad? I find the autocomplete function pretty handy
>> :-)
>
> I don't believe that's a jQuery function. Alone, jQuery does little more
> than queries and "event normalization" (quotes indicate there's no
> "normal" for events like change). Hell, they don't even allow for
> setting the - this - object without calling an additional "proxy"
> function. :(
>
>
>> >> $('#article' + counter + '').autocomplete('datapg.php?
>> >> mode=sqlarticle', {width: 200, max: 10});
>>
>> > You'd be better off with no widget at all as anything built atop
>> > jQuery is highly suspect (it's too slow, not cross-browser and has a
>> > terrible DOM abstraction layer). If that's unacceptable, hand this
>> > part off to somebody else (preferably not a jQuery enthusiast).
>>
>> Oh you explained it :-)
>> How would someone else do it. I could off course also just cut the
>> jQuery part.
>
> Well, if you have thousands of rows that need to populate a dropdown of
> some sort, you will need something along the lines of an
> autocomplete/suggest. Somebody more familiar with DOM scripting
> (particularly keyboard handling) should be able to bang one out in a day
> or two.
I kept this in mind, my db isn't very big. It can/will grow, but not to
the extend of thousands and thousands of records.
David Mark
Mar 14, 2012, 5:58:31 PM3/14/12
to
might do the trick (and wouldn't require scripting to work).
hipa
Mar 15, 2012, 2:27:36 AM3/15/12
to
Op Wed, 14 Mar 2012 14:58:31 -0700, schreef David Mark:
>> That sounds logical, when thousands of rows need to populate a
>> dropdown. I kept this in mind, my db isn't very big. It can/will grow,
>> but not to the extend of thousands and thousands of records.
>>
>>
> So how many rows do you have in the lookup table? A plain old SELECT
> might do the trick (and wouldn't require scripting to work).
The largest table at this moment has about 160 rows.
>> That sounds logical, when thousands of rows need to populate a
>> dropdown. I kept this in mind, my db isn't very big. It can/will grow,
>> but not to the extend of thousands and thousands of records.
>>
>>
> So how many rows do you have in the lookup table? A plain old SELECT
> might do the trick (and wouldn't require scripting to work).
David Mark
Mar 15, 2012, 2:46:01 AM3/15/12
to
autocomplete/suggest in the future, use script to hide the SELECT and
create a text INPUT (and an OL for the dropdown). If your number of
rows grows significantly, you might want to consider another interface
as an XHR-driven widget will not be usable without scripting.
In any event, no jQuery required. ;)
0 new messages