jQuery and autosuggest and more

[justaguy]

Hi,

I'm a casual user of jQuery. Question, does jQuery support
autosuggest? That is, for instance, I have an form INPUT field of
type: text, and I'd like to execute a database query to retrieve a
list of items upon loading of the page, when a user types a few
letters it would show items that starts with these typed letters, and
then, upon a selection, it would trigger another event, for instance,
submit the form. Is it doable with jQuery? If so, I'd appreciates an
example.

Thanks in advance.

[Gregor Kofler]

Am 2012-09-15 17:19, justaguy meinte:

You must be a "casual user" of any search engine, too.

Follow one of 137,000 hits with
<https://www.google.com/search?client=ubuntu&channel=fs&q=jquery+autosuggest&ie=utf-8&oe=utf-8>

Gregor



--
http://vxweb.net

[justaguy]

> <https://www.google.com/search?client=ubuntu&channel=fs&q=jquery+autos...>
>
> Gregor
>
> --http://vxweb.net

ok, thanks, now you've open the Pandora's box,.. I have more questions
for you.
a) what do you think of this jQuery's autosuggest plug-in? it looks
good.
http://code.drewwilson.com/entry/autosuggest-jquery-plugin
supposed you're familiar with it or similar jQuery plug-in for
autosuggest,
b) how to construct a query for ms sql server?
similar to the following
$query = mysql_query("SELECT * FROM my_table WHERE my_field LIKE '%
$input%'");
c) event trigger upon select.
With this plug-in, it's
selectionAdded: callback function - Custom function that is run when a
selection is made by choosing one from the Results dropdown, or by
using the tab/comma keys to add one. The selection item is passed into
this callback function as 'elem'.
Example: selectionAdded: function(elem){ elem.fadeTo("slow", 0.33); }

would selectionAdded: function(){ document.forms[0].submit(); }
submit the form with the selection data?

Many thanks.

[Gregor Kofler]

Am 2012-09-15 21:11, justaguy meinte:

> ok, thanks, now you've open the Pandora's box,.. I have more questions
> for you.
> a) what do you think of this jQuery's autosuggest plug-in? it looks
> good.

I have no idea. I use my own library and my own autosuggest widget.

http://vxweb.net/autosuggest

small, flexible, gets the job done - all of the time I need it.

With some additional code, I end up with things like that:

http://vxweb.net/xhrpicker

> b) how to construct a query for ms sql server?
> similar to the following
> $query = mysql_query("SELECT * FROM my_table WHERE my_field LIKE '%
> $input%'");

Er... yes. Mine look something like that. Though the WHERE clause makes
more sense with my_field LIKE '{$input}%' - Naturally, the $input value
has to be validated before processing. Get the query result, encode it
properly as whatever your library prefers (I suppose JSON). Return the
JSON string. Firebug can tell you all those details.

Gregor

[justaguy]

Wow, it's very elegant. The third one (Suggest3), autosuggest +
populating another field with a value is very close to what I need.
In my case, I need to
first apply autosuggest (retrieving data from a database), then
populate named or ided field2 and field3 with related data.

I would think your library might be able to tweak it as well. Next
question is, how do we trigger a sql query against a ms sql server
database? And it would be extremely Helpful if you could have another
page that have Only the samples (sample fields) and their functions.

Thanks.

[Gregor Kofler]

Am 2012-09-16 00:48, justaguy meinte:

RTFS:

var as = vxJS.widget.autoSuggest(
document.getElementById("suggestInput"),
{ command: "gimmethedata" },
{
maxEntries: 15,
searchMode: true,
keyElem: document.getElementById("keyInput")
}
);

will fill an additional key input with data, upon picking a suggestion.

If you need to fill an arbitrary number of fields you can forget about
the keyElem reference (it's there for convenience). Instead a

vxJS.event.addListener(as, "choose", function() {
var chosen = this.getChosen();
ElementReference1.value = chosen.customValue1;
ElementReference2.value = chosen.customValue2;
...
}

would do the trick.

> I would think your library might be able to tweak it as well. Next
> question is, how do we trigger a sql query against a ms sql server
> database?

POST contains a JSON encoded xmlHttpRequest field - decode it, get it's
text property (that's what was typed) and do your query.

Your response is again JSON encoded and contains an "entries" array.
Every array entry should at least hold an "id" (in this case not
required, though), a "text" property (the line of text shown) with each
entry and - in this special case a "customValue1" through "customValueN"
property. The rest is up to you. Again: Firebug or Chrom(e|ium) debugger
are very helpful with that.

> And it would be extremely Helpful if you could have another
> page that have Only the samples (sample fields) and their functions.

Dunno whether this will ever happen - in the meantime one has stick to
the page source.

Gregor

[S.T.]

If you're most comfortable with jQuery there's the jQuery UI project
that has quite a few options.

http://jqueryui.com/demos/autocomplete/

Decent tutorial with back-end using PHP:

http://www.jensbits.com/2010/03/29/jquery-ui-autocomplete-widget-with-php-and-mysql/

Footnote, don't know if you were tossing up some quick unsafe sample
code quickly or if you are a little unclear on SQL injection issues.
Greg mentioned it, but your sample code that looked like:
mysql_query("select * where id LIKE %".$_GET['term']."%")

... is practically begging for troubles down the line. Very quick,
non-foolproof but relatively safe PHP SQL injection mini-tutorial*

http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php

* assuming you want/need to stick with PHP's mysql_* set of functions.
Do consider moving to the far safer PHP database methods in the future,
PDO or at least mysqli_* with prepared statements.

[justaguy]

On Sep 17, 3:50 pm, "S.T." <a...@anon.com> wrote:
> On 9/15/2012 8:19 AM, justaguy wrote:
>
> > Hi,
>
> > I'm a casual user of jQuery.  Question, does jQuery support
> > autosuggest?  That is, for instance, I have an form INPUT field of
> > type: text, and I'd like to execute a database query to retrieve a
> > list of items upon loading of the page, when a user types a few
> > letters it would show items that starts with these typed letters, and
> > then, upon a selection, it would trigger another event, for instance,
> > submit the form.  Is it doable with jQuery?  If so, I'd appreciates an
> > example.
>
> If you're most comfortable with jQuery there's the jQuery UI project
> that has quite a few options.
>
> http://jqueryui.com/demos/autocomplete/
>
> Decent tutorial with back-end using PHP:
>

> http://www.jensbits.com/2010/03/29/jquery-ui-autocomplete-widget-with...

>
> Footnote, don't know if you were tossing up some quick unsafe sample
> code quickly or if you are a little unclear on SQL injection issues.
> Greg mentioned it, but your sample code that looked like:
> mysql_query("select * where id LIKE %".$_GET['term']."%")
>
> ... is practically begging for troubles down the line. Very quick,
> non-foolproof but relatively safe PHP SQL injection mini-tutorial*
>
> http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php
>
> * assuming you want/need to stick with PHP's mysql_* set of functions.
> Do consider moving to the far safer PHP database methods in the future,
> PDO or at least mysqli_* with prepared statements.

Thank you very much for the useful and CLEAR note.
I missed jQuery's autocomplete because of misunderstanding of its
term, "autocomplete", I took autocomplete as when we type the first
few letters of a word for a modern web browser and the like the
software automatically complete the whole word for us. And I take
"autosuggest" as giving us Choices when we type... bomber!

The jQuery's autocomplete looks neat. I have a question though.
With regard to the last task of Action/Event upon select,
One way,
"
Supply a callback function to handle the select event as an init
option.
$( ".selector" ).autocomplete({
select: function(event, ui) { ... }
});
"

Another way,
Bind to the select event by type: autocompleteselect.
$( ".selector" ).bind( "autocompleteselect", function(event, ui) {
...
});

Is the "even" and "ui" parameters are optional? Because in our case,
we would only need to
function() {document.forms[0].submit();}


With regard to the db query stmt, I copy the code from others, yeah,
we shouldn't be lazy or get into security trouble.

Again, many thanks.

[S.T.]

On 9/17/2012 2:42 PM, justaguy wrote:

> Thank you very much for the useful and CLEAR note.

You're welcome!

> The jQuery's autocomplete looks neat. I have a question though.
> With regard to the last task of Action/Event upon select,
> One way,
> "
> Supply a callback function to handle the select event as an init
> option.
> $( ".selector" ).autocomplete({
> select: function(event, ui) { ... }
> });
> "
>
> Another way,
> Bind to the select event by type: autocompleteselect.
> $( ".selector" ).bind( "autocompleteselect", function(event, ui) {
> ...
> });
>
> Is the "even" and "ui" parameters are optional? Because in our case,
> we would only need to
> function() {document.forms[0].submit();}

I suppose you don't truly need those parameters, but assuming you need
to pass the autocomplete selection made you'll need to do something with
the ui parameter. ui.item returns the JSON output of the selection chosen.

I usually use autocomplete with AJAX'y type stuff, i.e.
select: function(e,ui) {
$.post("page.php",{selection:ui.item.id});
}

... but nothing stopping you from grabbing part of ui.item and changing
the value of a hidden input in the form or altering the form's action
URL with appended data and then submit().

Suggest you just try:

select: function(event,ui) {
console.log(ui.item)
}

.. to see the returned data, then figure out what data you want to use
and figure out the best means to inject it in the form and then force
the form to submit.

[justaguy]

Great, thank you.

var availableTags = [
"data set 1",
"data set 2"
];

// autosuggest here
$( "#tags" ).autocomplete({
source: availableTags
});
// it works.

// take action upon select

$( ".selector" ).autocomplete({
select: function(event, ui) {

console.log(ui.item);
// attempted with
// console.log(ui) resulted in the same outcome
}
});
// Firebug's console does not show anything, either
ALL or Errors

What am I missing here? Many thanks.

[S.T.]

On 9/17/2012 4:31 PM, justaguy wrote:
>
> var availableTags = [
> "data set 1",
> "data set 2"
> ];
>
> // autosuggest here
> $( "#tags" ).autocomplete({
> source: availableTags
> });
> // it works.
>
> // take action upon select
> $( ".selector" ).autocomplete({
> select: function(event, ui) {
> console.log(ui.item);
> // attempted with
> // console.log(ui) resulted in the same outcome
> }
> });
> // Firebug's console does not show anything, either
> ALL or Errors
>
> What am I missing here? Many thanks.
>

You're using autocomplete() a little off.

/*
I imagine the source will end up server-side
presented as JSON, but...
*/

var availableTags = [
{
key: 1,
title: "Data1",
label: 'Data Set 1'},
{
key: 2,
title: "Data2",
label: 'Data Set 2'},
{
key: 3,
title: "Data3",
label: 'Data Set 3'}
];

$( "#tags" ).autocomplete({
source: availableTags,
select: function(event, ui) {
console.log(ui.item);

// however you want to do the form part...
$("#sel").val(ui.item.value);
console.log("Hidden input set to: "+$("#sel").val());
//$("#toSubmit").submit();

}
});


See: http://jsfiddle.net/wF5ek/1/

[Christoph Becker]

justaguy wrote:
> What am I missing here? Many thanks.

You probably want:

$( "#tags" ).autocomplete({
select: function(event, ui) {
console.log(ui.item);
}
});

And IMHO that's the /most/ basic problem with jQuery and similar
frameworks: they allow one to create amazing results by some trial and
error without even grasping the basics, i.e. what are the semantics of
the code.

About a year ago I've written a simple form generator using jQuery --
without jQuery I couldn't have done it. But as I wasn't able to grasp
the basics of ECMAScript back then, the code is totally crappy, and I
vainly hope, that I'll never have to correct this...

So, even if using jQuery and the loads of jQuery plugins is very
tempting, you might reconsider this approach, and learn basic ECMAScript
*first*. *Then* you might go on using whatever framework you prefer.

--
Christoph M. Becker

[S.T.]

On 9/17/2012 5:04 PM, Christoph Becker wrote:

>
> And IMHO that's the /most/ basic problem with jQuery and similar
> frameworks: they allow one to create amazing results by some trial and
> error without even grasping the basics, i.e. what are the semantics of
> the code.
>
> About a year ago I've written a simple form generator using jQuery --
> without jQuery I couldn't have done it. But as I wasn't able to grasp
> the basics of ECMAScript back then, the code is totally crappy, and I
> vainly hope, that I'll never have to correct this...
>
> So, even if using jQuery and the loads of jQuery plugins is very
> tempting, you might reconsider this approach, and learn basic ECMAScript
> *first*. *Then* you might go on using whatever framework you prefer.
>

You make a valid point but it's a question of resources. Does someone
who primarily does design and/or server-side really need to know, as in
thoroughly know, JavaScript just to enhance the UI here and there and do
some AJAX stuff? Certainly better to know a language than to not, but in
my experience JavaScript's learning curve starts rather flat then gets
steep - and the stuff designers care about nowadays (reliable
cross-browser XHR and DOM manipulation) is towards the top of the steep
section.

As browsers continue to head towards standards that curve will flatten
but, for now, the return on investment just isn't there for most. Not
when one can continue to improve design skills, writing skills, image
retouching, typography, server-side and SQL efficiency, etc. instead of
trying to master some of the more complicated aspects of JS. And not
when their are more-than-adequate crutches like jQuery that provide a
consistent API for others sharing the workload and handle the
complicated stuff done behind the scenes - even if those crutches are
flawed under some obscure scenarios.

There is some truly, truly awful code out there using jQuery - failures
to cache heavily used objects, crazy traversing of the DOM and so on.
Dead simple to find on the web. But even here, the DOM's they're working
against are usually so simple that the horribly inefficient code doesn't
even matter in most cases. It would be nice if more designers and
server-side scripters had a solid JS background but hardly seems like
it's holding the web back.

[justaguy]

Thanks (without your pointing out the how exactly to use the select
method, I would just bang my head on the wall). Got it working
exactly as I want it. Another way, is to bind the FORM element value
to the ui item value.

[justaguy]

console.log(ui.item);

Yeah, that's the key debugging thing for what I need here. I got it
working per my most recent post. Thanks.

[justaguy]

I completely agree.

[justaguy]

Ok, one minor thing, how do we get rid of the dot in front of each
item? For instance,
. item 1
. item 2
n ...
But I just want to have
item 1
item 3
n ...

I commented out the ui-widget class to no avail. A quick glimpse of
jQuery doc does not help neither. Thanks.

[David Mark]

On Sep 17, 8:51 pm, "S.T." <a...@anon.com> wrote:

> On 9/17/2012 5:04 PM, Christoph Becker wrote:
>
>
>
> > And IMHO that's the /most/ basic problem with jQuery and similar
> > frameworks: they allow one to create amazing results by some trial and
> > error without even grasping the basics, i.e. what are the semantics of
> > the code.
>
> > About a year ago I've written a simple form generator using jQuery --
> > without jQuery I couldn't have done it.  But as I wasn't able to grasp
> > the basics of ECMAScript back then, the code is totally crappy, and I
> > vainly hope, that I'll never have to correct this...
>
> > So, even if using jQuery and the loads of jQuery plugins is very
> > tempting, you might reconsider this approach, and learn basic ECMAScript
> > *first*. *Then* you might go on using whatever framework you prefer.
>
> You make a valid point but it's a question of resources. Does someone
> who primarily does design and/or server-side really need to know, as in
> thoroughly know, JavaScript just to enhance the UI here and there and do
> some AJAX stuff?

Of course. Regardless of what canned scripts you include, you still
have to write JS.

> Certainly better to know a language than to not, but in
> my experience JavaScript's learning curve starts rather flat then gets
> steep - and the stuff designers care about nowadays (reliable
> cross-browser XHR and DOM manipulation) is towards the top of the steep
> section.

That's ridiculous. The FAQ has had the basic cross-browser XHR code
for many years. And what sort of DOM manipulation?

>
> As browsers continue to head towards standards that curve will flatten
> but, for now, the return on investment just isn't there for most.

You have missed the boat. If you wrote cross-browser code (unlike the
crap found in jQuery), you could simply serve static content to legacy
IE versions. Other than that, you have very little to worry about.
It's just that projects like jQuery make it seem so hard (part of
their marketing).

> Not
> when one can continue to improve design skills, writing skills, image
> retouching, typography, server-side and SQL efficiency, etc. instead of
> trying to master some of the more complicated aspects of JS.

Is this an argument or your CV? Regardless, none of that adds anything
to the discussion of jQuery.

> And not
> when their are more-than-adequate crutches like jQuery that provide a
> consistent API for others sharing the workload and handle the
> complicated stuff done behind the scenes - even if those crutches are
> flawed under some obscure scenarios.

You just have no clue what you are talking about. You don't know what
"complicated stuff" jQuery is handling, nor do you have any idea when/
where/how it will make the stuff more complicated. Google my name +
"Javascript tips". Invest an hour or so reading and you'll realize
that jQuery isn't helping you at all with any of the "complicated
stuff". Furthermore, the (terrible) API that you've professed to like
in the past is trivial to recreate. It's done (much better) in My
Library, which has been out there for perusal for almost five years.

If you continue to use jQuery as a (broken) crutch, you'll never learn
anything. That's why you continue to see basic DOM scripting as
"obscure" and "complicated stuff".

>
> There is some truly, truly awful code out there using jQuery - failures

If you were qualified to make such an assessment (however accurate),
you'd know that there is some "truly, truly awful" code *inside* of
jQuery, as well as an inappropriate API that just confuses the hell
out of basic issues. Again, read my tips (and if already have, read
them again).

> to cache heavily used objects, crazy traversing of the DOM and so on.

Crazy. :)

> Dead simple to find on the web.

Dead simple. Should be right up your alley. :)

> But even here, the DOM's they're working
> against are usually so simple that the horribly inefficient code doesn't
> even matter in most cases.

Except that the user had to download it, the agent (often a battery-
powered mobile device these days) had to parse and execute it and
(surprise) most of it is unneeded BS. You'd know that if you'd paid
attention the last few years.

> It would be nice if more designers and
> server-side scripters had a solid JS background but hardly seems like
> it's holding the web back.

It's made a colossal, unwieldy mess of the Web (and scrambled the
brains of prospective JS developers). You simply have no frame of
reference.

[David Mark]

Of course you do. :)

[justaguy]

How do make multiple input fiels/elements using autosuggest?

The following syntax is incorrect:
$( "#tags","#tags2" ).autocomplete({
...
});

And the following is correct but inefficient, what if I have 10 fields
or 20 fields that need autosuggest
$( "#tags").autocomplete({
...
});

$( "#tags2" ).autocomplete({
...
});

Thoughts? Thanks.

[David Mark]

On Sep 17, 3:50 pm, "S.T." <a...@anon.com> wrote:

> On 9/15/2012 8:19 AM, justaguy wrote:
>
> > Hi,
>
> > I'm a casual user of jQuery.  Question, does jQuery support
> > autosuggest?  That is, for instance, I have an form INPUT field of
> > type: text, and I'd like to execute a database query to retrieve a
> > list of items upon loading of the page, when a user types a few
> > letters it would show items that starts with these typed letters, and
> > then, upon a selection, it would trigger another event, for instance,
> > submit the form.  Is it doable with jQuery?  If so, I'd appreciates an
> > example.
>
> If you're most comfortable with jQuery there's the jQuery UI project
> that has quite a few options.

Unfortunately, it is built on top of jQuery. :(

>
> http://jqueryui.com/demos/autocomplete/
>
> Decent tutorial with back-end using PHP:
>

> http://www.jensbits.com/2010/03/29/jquery-ui-autocomplete-widget-with...

Doesn't really matter; you can't use such garbage in production (at
least not on the Web). And yes, I know lots of people do just that.
They typically end up with two documents for every resource due to
their jQuery-based "solution" being far too slow and bloated for
mobile users.

>
> Footnote, don't know if you were tossing up some quick unsafe sample
> code quickly or if you are a little unclear on SQL injection issues.
> Greg mentioned it, but your sample code that looked like:
> mysql_query("select * where id LIKE %".$_GET['term']."%")

Don't concatenate SQL query strings in PHP scripts. And yes, that is
one of the worst examples I've ever seen. Doesn't matter the context,
such code shouldn't be posted where it is likely to be copied.

>
> ... is practically begging for troubles down the line. Very quick,
> non-foolproof but relatively safe PHP SQL injection mini-tutorial*

Relatively safe as compared to what? :(

[David Mark]

On Sep 17, 8:03 pm, Christoph Becker <cmbecke...@gmx.de> wrote:

You need to learn both the language and the DOM. The libraries and
frameworks paint the DOM as a "terrible" set of interfaces, but then
they are trying to sell you on their wonderful "normalization"
solutions. The libraries and frameworks do nothing for the language,
which still must be used when programming with these things.

As for "trial and error", that's exactly what is done with these
things. It's not programming to rearrange patterns of code until they
seem to work (typically in just the browsers on hand).

And ultimately, as anyone with experience will tell you, once you
reach a certain point on the learning curve, you realize that most of
the libraries and frameworks are written by developers that don't know
the language or the DOM well enough to help you.

For example, reading jQuery's code is absolutely cringe-inducing. Five
minutes is enough to realize it can only hinder you. Same for
Mootools, Dojo and the rest of the usual suspects.

Why would this be? Because experienced developers know that monolithic
libraries and frameworks are the exact opposite of what is required
for competent solutions. This is more true today than six years ago
when these things started coming out of the woodwork. So it makes
sense that most of experienced developers stay away from such efforts.
Furthermore, it's very hard to gain practical experience monkeying
around on one of these projects as most of your feedback will come
from fellow inexperienced developers.

The proof is simple: if these things were time-savers, they wouldn't
require endless maintenance. Bad assumptions in the code invariably
lead to unexpected results. These results may be very hard to spot and
you can't rely on user feedback to find them. All you can do is
periodically "upgrade" a large mess of complicated JS and cross your
fingers that the goofs behind these things have *finally* figured out
how to write cross-browser scripts. It's programming by (somebody
else's) crystal ball.

http://en.wikipedia.org/wiki/Cross-browser

Multi-browser designs lead to endless tinkering, which leads to
perpetually unstable projects. Cross-browser designs give you the best
chance of avoiding such instability and therefore save time in the
long run. And as virtually none of the "popular" libraries and
frameworks have ever been cross-browser (though many claim to be),
their dubious results over the last half-dozen years were entirely
predictable.

[S.T.]

On 9/17/2012 7:47 PM, justaguy wrote:

> How do make multiple input fiels/elements using autosuggest?
>
> The following syntax is incorrect:
> $( "#tags","#tags2" ).autocomplete({
> ...
> });
>
> And the following is correct but inefficient, what if I have 10 fields
> or 20 fields that need autosuggest
> $( "#tags").autocomplete({
> ...
> });
>
> $( "#tags2" ).autocomplete({
> ...
> });
>
> Thoughts? Thanks

It's a little difficult to answer without a clearer idea of the end
goal, but as an example you can set the autocomplete based on one
selector - we'll use class name 'autocomplete' here, then change the
data source of that autocomplete event based on focus() events using the
data() method tied to a hard-coded attribute in the various inputs. See:
http://jsfiddle.net/yrPRW/

[David Mark]

Not a bit of which requires or is even simplified by jQuery. Ironic
that you are talking about using jQuery to do anything related to
attributes. No matter how many times you are told that jQuery is (and
always has been) clueless about attributes, you want to use it to read
attributes. Why? Because it says "jQuery" on it? :)

It's interesting that you recently referred to My Library as
"abandonware" when it has had attributes right from the start (roughly
five years ago). Do you see the additional irony here? While it has
sat "abandoned" (think "finished") for five years, jQuery has been
perpetually fiddling with their "attr" (and later "prop") code. Does
constant meddling with code and seemingly endless snafus give you
confidence? Think of jQuery as "franticware". ;)

[S.T.]

On 9/17/2012 7:54 PM, David Mark wrote:
>>
>> Footnote, don't know if you were tossing up some quick unsafe sample
>> code quickly or if you are a little unclear on SQL injection issues.
>> Greg mentioned it, but your sample code that looked like:
>> mysql_query("select * where id LIKE %".$_GET['term']."%")
>
> Don't concatenate SQL query strings in PHP scripts. And yes, that is
> one of the worst examples I've ever seen. Doesn't matter the context,
> such code shouldn't be posted where it is likely to be copied.
>
>>
>> ... is practically begging for troubles down the line. Very quick,
>> non-foolproof but relatively safe PHP SQL injection mini-tutorial*
>
> Relatively safe as compared to what? :(

Select querying against data intended to be seen by the public while
filtering with concatenated mysql_real_escape_string() has no risk. It's
not a good habit - prepared statements are what you want to use for more
sensitive database operations like an INSERT to selecting against a
supposedly protected and hashed password - but there's no risk in the
situation described in this thread.

[S.T.]

The fact that the OP requested a solution using jQuery played a role in
my jQuery-related answer. Is that confusing?

> It's interesting that you recently referred to My Library as
> "abandonware" when it has had attributes right from the start (roughly
> five years ago). Do you see the additional irony here? While it has
> sat "abandoned" (think "finished") for five years, jQuery has been
> perpetually fiddling with their "attr" (and later "prop") code. Does
> constant meddling with code and seemingly endless snafus give you
> confidence? Think of jQuery as "franticware". ;)

Five years and I've never heard anyone admit to actually using your
library, and sure as hell have never seen a site intended for public use
- any site whatsoever, really - that uses it. In the world of libraries
that's the definition of failure.

We've been through this about a year ago:
"Show some examples."
"No way, you're just asking 'cause you want to steal the scripts."
"OK, a) that's ridiculous and b) it's obvious there are no examples so
quit pretending otherwise as you're further embarrassing yourself."

Anything changed in the past 12 months? Any examples? No? EXACTLY! Pipe
down until you've got something to show. You're fooling no one.

[David Mark]

On Sep 18, 1:53 am, "S.T." <a...@anon.com> wrote:
> On 9/17/2012 7:54 PM, David Mark wrote:
>
>
>
> >> Footnote, don't know if you were tossing up some quick unsafe sample
> >> code quickly or if you are a little unclear on SQL injection issues.
> >> Greg mentioned it, but your sample code that looked like:
> >> mysql_query("select * where id LIKE %".$_GET['term']."%")
>
> > Don't concatenate SQL query strings in PHP scripts. And yes, that is
> > one of the worst examples I've ever seen. Doesn't matter the context,
> > such code shouldn't be posted where it is likely to be copied.
>
> >> ... is practically begging for troubles down the line. Very quick,
> >> non-foolproof but relatively safe PHP SQL injection mini-tutorial*
>
> > Relatively safe as compared to what? :(
>
> Select querying against data intended to be seen by the public while
> filtering with concatenated mysql_real_escape_string() has no risk.

Assuming that function is 100% reliable, what is the "non-foolproof"
designation in aid of? In any event, production applications should
use stored procedures, which eliminate the need to concatenate
anything.

> It's
> not a good habit - prepared statements are what you want to use for more
> sensitive database operations like an INSERT to selecting against a
> supposedly protected and hashed password - but there's no risk in the
> situation described in this thread.

Whether perceived as sensitive or not, you should not be fiddling
around with SQL strings in PHP scripts. I often come across (bad)
examples like "justaguy" presented in ostensibly finished applications.

[David Mark]

A word of advice: implying that I am confused is not going to buy you
any credibility here.

Regardless, my comment simply pointed out the irony of you
recommending jQuery be used to fetch attribute values. Would be just
as ironic if you recommended jQuery for basic XHR or jQuery UI for
monitoring keyboard input. How long have you been hanging around here
and how could you still be recommending jQuery-branded BS for such
tasks?

>
> > It's interesting that you recently referred to My Library as
> > "abandonware" when it has had attributes right from the start (roughly
> > five years ago). Do you see the additional irony here? While it has
> > sat "abandoned" (think "finished") for five years, jQuery has been
> > perpetually fiddling with their "attr" (and later "prop") code. Does
> > constant meddling with code and seemingly endless snafus give you
> > confidence? Think of jQuery as "franticware". ;)
>
> Five years and I've never heard anyone admit to actually using your
> library,

You are either lying or simply haven't had time to read every post for
the last five years.

> and sure as hell have never seen a site intended for public use
> - any site whatsoever, really - that uses it.

And that means what exactly? Clearly you haven't had time to visit
every site on the Web either.

> In the world of libraries
> that's the definition of failure.

Sorry, no. If you were here five years ago when the library was built,
you'd know that I very specifically rejected the notion of marketing
the script to the masses. People mentioned T-shirts, birthday parties
(for scripts?!), etc. and I told them I would not do any of that,
allowing the masses to make up their own minds. In fact, I took the
opposite approach with a plain Jane presentation and constantly
disclaimers that it was really more for example than anything else
(remember I don't like monolithic libraries). You just referenced this
line (in your own clumsy, wrong-headed way) in the last day or so
(something about using My Library would be "stupid").

How ironic that in the "world of libraries", specifically mass-
marketed libraries like jQuery, virtually every denizen ended up with
code just like mine. That, along with the undeniable indefatigability
of the script indicates not only success from the start, but sustained
success over five years. Odd that you aren't grateful for my generous
example; instead you try to poke fun at it every time you post here.
It's almost as if you are a complete moron. (?)

Furthermore, one of the primary needs for an autocomplete/suggest
widget is reliable handling of keyboard input. Guess which library
succeeded on that front when most of the "popular" libraries were
fumbling around with browser sniffing? Yep, your old "foil" My
Library. It's almost as if you haven't read anything since you've been
here. (?)

>
> We've been through this about a year ago:
> "Show some examples."

And who/what are you quoting here?

> "No way, you're just asking 'cause you want to steal the scripts."

Never me. :)

Let me try to simplify this for you: I don't like you (whoever you
are). I would sooner fly to the moon than go out of my way to show you
anything. Make sense? :)

> "OK, a) that's ridiculous and b) it's obvious there are no examples so
> quit pretending otherwise as you're further embarrassing yourself."

Examples of what exactly? And just who are you talking to at this
point? You seem to be having an unattributed discussion with
yourself. :(

>
> Anything changed in the past 12 months? Any examples? No? EXACTLY! Pipe
> down until you've got something to show. You're fooling no one.

Down to the SHOUTING is it? Clearly nothing has changed (for you) in
the last five years. Pity. :(

[David Mark]

For further reading:

http://stackoverflow.com/questions/5874652/prop-vs-attr/5876747

That's just one of hundreds of such questions on SO, each with a
stream of mostly confused answers (as well as further questions). The
primary "answer man" for jQuery is called T.J. Crowder and clearly has
no idea what he's talking about (no coincidence that he's never been
seen around here).

http://stackoverflow.com/questions/6432246/radio-buttons-and-attrchecked-checked-does-not-work-in-ie7?lq=1

http://stackoverflow.com/questions/3121785/set-radio-button-checked-in-jquery-based-on-id?rq=1

Seems jQuery really simplifies basic DOM manipulation. Getting/setting
properties (don't need to mess with attributes 99.9% of the time) has
never been easier. :)

Ironic that this example, as well as My Library, existed long before
the jQuery 1.6 disaster. In fact, they (along with my first review of
jQuery back in 2007) were the impetus for the change to "attr" and
"prop" (the latter function name lifted straight from my example).

http://www.cinsoft.net/attributes.html

That's the one Resig copied into the jQuery repository (and later
deleted when I reminded him of the copyright at the bottom of the
page). He whined and denigrated the lifted code as "common sense" at
the time, yet in five years he never came close to solving the issues
tackled in the example. And, of course, if it really were all "common
sense" (sort of like the feature detection/testing code he lifted from
My Library back in 2008), then why couldn't any of the people
contributing to jQuery come up with the solutions? It's almost as if
they are a bunch of inexperienced greenhorns (not to mention
plagiarists). :(

Unfortunately for those who put their faith in the jQuery "brain
trust", when they tried to use their own "common sense", they botched
the job so badly that they had to partially revert the changes in
1.6.1. All old news for those who have followed this group over the
years. As soon as 1.6 was released, it was predicted here that they'd
follow up with another "upgrade" soon after (they sure as hell
couldn't go forward with what they had).

It's also unfortunate that so many people had blissfully deployed
jQuery without any clue that the original "attr" (which reemerged in
1.6.1) was broken beyond belief (as mentioned in my review from 2007
and later detailed in numerous examples). That huge user base painted
the project into a corner so that they could never fix this method,
which is used extensively in virtually every jQuery application and
example. For years I heard the excuse that "attr" was broken only in
"obscure" or "edge" cases and for years I insisted that was complete
and utter BS (as it clearly turned out to be).

Of course, some will be grateful (despite the ultimately negative
result for jQuery) for my example and others will whine and babble
about the number of contributors to jQuery and how they "keep up" with
the latest browser bugs and that nobody uses My Library (save for the
jQuery authors when they need to find answers). Those others are quite
obviously idiots (see the anonymous poster known only as "S.T.").

By any rational definition (even in the world of JS libraries), jQuery
is an outrageous failure. Furthermore, the management of the project
and subsequent "support" on forums like StackOverflow and jQuery's own
discussion group compounds their failures. The specific (and glaring)
example of "attr" is part of the jQuery foundation (where it meets the
DOM basically) and the flurry of related activity (first affecting
1.6) occurred roughly five years into its run. Furthermore, the
specific issues were discussed to death here and at some point Resig
told his flock to put on blinders where CLJ was concerned. Yes,
really; you can't make this stuff up. :(

Of course, if you measure success by the number of people burned by
these frauds, it's absolutely smashing. ;)

[justaguy]

On Sep 18, 1:17 am, "S.T." <a...@anon.com> wrote:

Ok, that makes sense, thank you. But I ran into a problem when I
attempted to implement it with a project. That is, with identical
code except field id difference and changed accordingly in the
function references.

The error msg is:
TypeError: $("#productid").autocomplete is not a function
[Break On This Error]
select: function(event, ui) {

Notes:
I have a field with id of "productid" in the HTML form and have
replaced "tags" references in the jQuery function references to
"productid". What could have caused it to misfire?

Many thanks.

[justaguy]

Pls ignore it. Something quirky about it. The js code has to be below
HTML form.

[justaguy]

On Sep 18, 1:17 am, "S.T." <a...@anon.com> wrote:

Sorry, I think there's some misunderstanding about this requirement.
That is, I'd like to use the same data set to autosuggest for several
FORM elements. For instance, we have a product list, so, field1,
field2... fieldN would all show the entire same product list.
The above example is nice but but after form submission we get only
one field data.

I'm thinking loud here... is there a way to bind or assign {current
DOM element} to ui item value? If yes, then each field would have its
own value when the form is submitted.

Thanks.

[S.T.]

On 9/18/2012 8:07 AM, justaguy wrote:
>>
>> It's a little difficult to answer without a clearer idea of the end
>> goal, but as an example you can set the autocomplete based on one
>> selector - we'll use class name 'autocomplete' here, then change the
>> data source of that autocomplete event based on focus() events using the
>> data() method tied to a hard-coded attribute in the various inputs. See:http://jsfiddle.net/yrPRW/
>
> Sorry, I think there's some misunderstanding about this requirement.
> That is, I'd like to use the same data set to autosuggest for several
> FORM elements. For instance, we have a product list, so, field1,
> field2... fieldN would all show the entire same product list.
> The above example is nice but but after form submission we get only
> one field data.

This help?

http://jsfiddle.net/6kq9a/

[justaguy]

Very close. I like the Simple Data option but we still need select
method because we need to automatically send the form submission upon
select. What impedes me is this:
how to map {current DOM element/field}.value to ui item value (ok with
the express on the right
but not on the left)
The {current DOM element/field}.value could be "product name 1", could
be "product name 2" etc.
// the following syntax won't work
this.value=ui.item.value;
// then submit the form like
form.submit();

Thanks.

[justaguy]

Actually,
this.value=ui.item.value;
works. Previously, I missed something... bomber.

Thanks.

[David Mark]

Near as you can tell, it *appears* to work. But with which version of
jQuery, which version of jQuery UI and what browser/configuration? In
short, your observation is insignificant.

Look how many times the "value" attribute/property is mentioned here:

http://stackoverflow.com/questions/5874652/prop-vs-attr/5876747

...and deep within this pile of scripts lies code that reads and
writes the "value" property and/or attribute. Are you really
comfortable placing blind faith in such code?

So what have you learned? Trying to figure out the DOM through trial
and error, using a dodgy stack of scripts like jQuery UI is a very
hard way to go. May lead to instant gratification once you happen on a
pattern that seems to work, but that quickly turns to disappointment
when your chosen black boxes are shaken up by their authors. In the
case of jQuery scripts, this happens all the time as the creators are
also trying to figure out the DOM through trial and error. ;)

Instead of trying to be a Jack of all trades, you might consider
writing your application with just HTML and CSS and then delegate
responsibility for the scripted enhancements that you are clearly
incapable of doing on your own. As a bonus, your application will then
work when scripting and/or the required host features are missing or
broken.

http://en.wikipedia.org/wiki/Cross-browser

If you listen to your fellow jQuery enthusiasts, you'll get the idea
that jQuery UI works in virtually every browser (save for a handful of
"older" mobile browsers) and for every user (nobody disables
scripting, right?).

Here's just one example:

http://en.wikipedia.org/wiki/Opera_Mini

"On March 2012, Opera reported 168 million unique Opera Mini active
users and 117 billion page views served during that month. This
represented an 60.4% increase since March 2011."

This is a rare case where browser usage statistics can be taken at
face value. Opera certainly knows how many users they have and how
many pages they peruse per month.

Pay particular attention to this section:

http://en.wikipedia.org/wiki/Opera_Mini#JavaScript_support

"Opera Mini has limited support for JavaScript. Before the page is
sent to the mobile device, its onLoad events are fired and all scripts
are allowed a maximum of two seconds to execute. The setInterval and
setTimeout functions are disabled, so scripts designed to wait a
certain amount of time before executing will not execute at all."

More importantly, assuming your stack of scripts even makes it to the
browser:

"After the scripts have finished or the timeout is reached, all
scripts are stopped and the page is compressed and sent to the mobile
device. Once on the device, only a handful of events are allowed to
trigger scripts:

onUnload: Fires when the user navigates away from a page
onSubmit: Fires when a form is submitted
onChange: Fires when the value of an input control is changed
onClick: Fires when an element is clicked"

Now, your average deluded jQuery abuser will shrug that off with "we
don't care about Opera Mini", but that's missing the point. This
represents one example that clearly contradicts the assertion that the
bloated jQuery UI framework will inconvenience only a handful of users
who are stuck with "older" mobile browsers. Furthermore, you've got to
consider whether it is prudent to flip off 168 million (and growing)
users.

May seem like a bitter pill, but it represents reality. I recommend
you swallow it and forget you ever heard about jQuery. This is the
same advice I'd have given if you'd asked five years ago. Such advice
looks better every year and it seems a good bet that trend will
continue. ;)

[S.T.]

On 9/18/2012 2:24 PM, David Mark wrote:
> Furthermore, you've got to
> consider whether it is prudent to flip off 168 million (and growing)
> users.

http://i.imgur.com/N0Rsb.png

[David Mark]

What a pretty picture! :)

Now go back and read the parts you snipped. ;)

[Christoph Becker]

David Mark wrote:
> You need to learn both the language and the DOM.

Thank you for clarifying this. :-) My wording was mistaken, as I meant
not the language (ECMAScript), but in fact the hosting environment
(DOM). Even if jQuery gives some functions such as jQuery.map(), which
IMHO should be available in ECMAScript "directly".

--
Christoph M. Becker

[Michael Haufe (TNO)]

Array.map() exists in JavaScript 1.6+

Array.prototype.map() is defined in the current ECMAScript standard
<http://es5.github.com/#x15.4.4.19>

[David Mark]

On Sep 18, 7:53 pm, Christoph Becker <cmbecke...@gmx.de> wrote:
> David Mark wrote:
> > You need to learn both the language and the DOM.
>
> Thank you for clarifying this. :-)

You're welcome.

> My wording was mistaken, as I meant
> not the language (ECMAScript), but in fact the hosting environment
> (DOM).  Even if jQuery gives some functions such as jQuery.map(), which
> IMHO should be available in ECMAScript "directly".

That is a good point. jQuery is such a hodgepodge that it does have a
few fillers that are unrelated to the DOM. Of course, you still have
to know the language to call methods of any sort.

Also brings up that jQuery has always been marketed as one large
script; there's no builder to exclude the bits you don't need. It's
just not modular in that sense. I remember a few years back when
criticized about this very issue, one of the authors (probably Resig)
shot back that it was in hundreds of pieces (and how much more
"modular" does it need to be?!). Of course, it was/is in hundreds of
pieces for the developers writing it, but the users always ended up
with a single monolith. :(

I think they are trying to write a "roll your own" builder now. They'd
do well to see another of my examples:

http://www.cinsoft.net/mylib-builder.asp

...Or perhaps they already have. :)

For the example at hand, DOM + Ajax/Requester should be enough for the
core and the keyboard add-on is easily the best at what it does.
That's about all that is required; a competent JS/CSS developer should
be able to put the pieces together to create a cross-browser auto-
complete/suggest widget that suits their needs. It's not the instant
gratification of downloading junk from the "jQuery Universe", but it
sure travels farther and lasts longer.

Last two widgets I wrote using My Library were an auto-suggest and
date picker, which shared a lot of common code. Very lightweight and
efficient; they work perfectly in IE 5.5-10 (though a bit degraded in
5.5 and 6) and don't foul up iPads, iPhones, etc. either. As for
ancient browsers (or crippled browsers like Opera Mini), they bail out
safely, leaving plain old SELECT and INPUT controls. That's the way
this stuff is supposed to work and the code that enables such
performance has been online (and virtually unchanged) for going on
five years.

[Christoph Becker]

Michael Haufe (TNO) wrote:
> Array.map() exists in JavaScript 1.6+
>
> Array.prototype.map() is defined in the current ECMAScript standard
> <http://es5.github.com/#x15.4.4.19>

Thanks for the correction. I was not yet aware of the ECMAscript 5
improvements regarding applicative programming -- the set seems quite
complete. :-)

BTW: I wanted to look up browser compatibility information on
<https://developer.mozilla.org/>, but the DNS lookup fails. Has anybody
some information about that?

--
Christoph M. Becker

[S.T.]

On 9/18/2012 3:40 PM, David Mark wrote:
> What a pretty picture! :)
>
> Now go back and read the parts you snipped. ;)

I read it. Same as always - total disconnect from the marketplace
coupled with an over-valued opinion of your own understanding results in
really bad advice.

[David Mark]

You must have missed the bit about how jQuery abusers would react to
such an example. I suggest you read it again. ;)

[Thomas 'PointedEars' Lahn]

About your DNS configuration: It is borken. I can access that site.

About Array.prototype.map(): Information in the current ECMAScript Support
Matrix is sparse on that, indeed, so the following is more or less copy-
pasted from my thesis' results that I am going to publish later this year
(sorry about the delay, that's real life interfering when you least expect
it).

Array.prototype.map(callback : Function[, thisArg : Object]) : number|int

* ECMAScript Ed. 5 [15.4.4.19]

* Microsoft JScript
- 5.5.6330 1/11 (*)
- 9.0.16440 11/11 (+)

* Netscape/Mozilla JavaScript
- 1.5 1/11 (*)
- 1.6 11/11 (+)

* Google V8
- 3.7.12.12 11/11 (+)

* Apple JavaScriptCore
- 531.22.7 11/11 (+)

* Opera ECMAScript
- 7.02 1/11 (*)
- 8.0 4/11 (*)
- 9.52 11/11 (+)

* KDE JavaScript
- 4.6.5 11/11 (+)

Legend: (*) partial support (passes some, but not all testcases)
(+) full support (passes all testcases)

Only changes between tested versions of an implementation are listed.

The following host environments have been used for the tests:

* JScript
- Version 5.5.6330 in Internet Explorer 5.50.4807.2300
(Mozilla/4.0 (compatible; MSIE 5.5; Windows 98))
- Version 5.6.6626 in Internet Explorer 6.0.2800.1106
(Mozilla/4.0 (compatible; MSIE 6.0; Windows 98))
- Version 5.7.22589 in Internet Explorer 7.0.5730.13
for Windows Server 2003
(Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322;
.NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648;
.NET CLR 3.0.4506.2152; .NET CLR 3.5.30729))
- Version 5.8.23141 in Internet Explorer 8.0.6001.18702IC for Windows XP
Pro 2002 SP3
(Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;
.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152;
.NET CLR 3.5.30729))
- Version 9.0.16440 in Internet Explorer 9.0.8112.16421 for Windows 7 Pro
32-bit SP1
(Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0))

* Netscape/Mozilla JavaScript
- Version 1.5 in Firefox 1.0.8 for Windows
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13)
Gecko/20060410 Firefox/1.0.8)
- Version 1.6 in Firefox for Windows 1.5.0.12
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12)
Gecko/20070508 Firefox/1.5.0.12)
- Version 1.7 in Firefox for Windows 2.0
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1)
Gecko/20061010 Firefox/2.0)
- Version 1.8 in Firefox for Windows 3.0.19
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.19)
Gecko/2010031422 Firefox/3.0.19)
- Version 1.8.1 in Debian Iceape (SeaMonkey) 2.0.11-9
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20111108
Iceape/2.0.11)
- Version 1.8.5 in Debian Iceweasel (Firefox) 10.0.2
(Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Iceweasel/10.0.2)

* Google V8
- Version 3.7.12.12 in Chrome 17.0.963.78 (Developer Build 125577 Linux)
(Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.11 (KHTML, like Gecko)
Chrome/17.0.963.78 Safari/535.11)
- Version 3.8.9.5 in Google Chrome 18.0.1025.45 beta for Linux
(Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.19 (KHTML, like Gecko)
Chrome/18.0.1025.45 Safari/535.19)

* Apple JavaScriptCore
- Version 531.22.7 in Safari for Windows 4.0.5 (531.22.7)
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/531.22.7
(KHTML, like Gecko) Version/4.0.5 Safari/531.22.7)
- Version 7533.18.5 in Safari for Windows 5.0.2 (7533.18.5)
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.18.1
(KHTML, like Gecko) Version/5.0.2 Safari/533.18.5)
- Version 7534.52.7 in Safari 5.1.2 (7534.52.7) for Windows 7 32-bit SP1
(Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.52.7 (KHTML, like Gecko)
Version/5.1.2 Safari/534.52.7)

* Opera ECMAScript
- Version 7.02 in Opera 7.02.2668 for Windows XP 32-bit
(Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1) Opera 7.02
[en])
- Version 8.0 in Opera 8.0.7561 for Windows
(Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.0)
- Version 9.27 in Opera 9.27.8841 for Windows
(Opera/9.27 (Windows NT 5.1; U; en))
- Version 9.52 in Opera 9.52.10108 for Windows
(Opera/9.52 (Windows NT 5.1; U; en))
- Version 9.62 in Opera 9.62.10467 for Windows
(Opera/9.62 (Windows NT 5.1; U; en) Presto/2.1.1)
- Version 9.64 in Opera 9.64.10487 for Windows
(Opera/9.64 (Windows NT 5.1; U; en) Presto/2.1.1)
- Version 10.53 in Opera 10.53.3374 for Windows
(Opera/9.80 (Windows NT 5.1; U; en) Presto/2.5.24 Version/10.53)
- Version 10.54 in Opera 10.54.3423 for Windows
(Opera/9.80 (Windows NT 5.1; U; en) Presto/2.5.24 Version/10.54)
- Version 11.61 in Opera 11.61.1250 for Linux
(Opera/9.80 (X11; Linux i686; U; en) Presto/2.10.229 Version/11.61)

* KDE JavaScript
- Version 4.6.5 in Konqueror for Linux 4.6.5
(Mozilla/5.0 (compatible; Konqueror/4.6; Linux 2.6.39.3-pe; X11; i686;
de) KHTML/4.6.5 (like Gecko))


HTH

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Christoph Becker]

Thomas 'PointedEars' Lahn wrote:

> Christoph Becker wrote:
>> BTW: I wanted to look up browser compatibility information on
>> <https://developer.mozilla.org/>, but the DNS lookup fails. Has anybody
>> some information about that?
>
> About your DNS configuration: It is borken. I can access that site.

I was able to access the site later in the evening. I should have
reported this; sorry for any inconvenience.

> About Array.prototype.map(): Information in the current ECMAScript Support
> Matrix is sparse on that, indeed, so the following is more or less copy-
> pasted from my thesis' results that I am going to publish later this year
> (sorry about the delay, that's real life interfering when you least expect
> it).

> HTH

Yes, that's very useful information. Thank you.

--
Christoph M. Becker

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> Array.prototype.map(callback : Function[, thisArg : Object]) : number|int

That is a copy-and-paste error. Of course, Array.prototype.map() returns a
reference to an Array instance, not a number.

--
PointedEars