Wrox Programmer Forums
|
BOOK: Professional JavaScript for Web Developers ISBN: 978-0-7645-7908-0
This is the forum to discuss the Wrox book Professional JavaScript for Web Developers by Nicholas C. Zakas; ISBN: 9780764579080
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional JavaScript for Web Developers ISBN: 978-0-7645-7908-0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old May 10th, 2006, 12:09 AM
Registered User
 
Join Date: May 2006
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I was just wondering if the corrected code should be
var iResult = oStringObject1.localeCompare(oStringObject2);
instead of
var iResult = sStringObject1.localeCompare(oStringObject2);

since sStringObject1 is undefined.

Quote:
quote:Originally posted by nzakas
 AGS,

You are correct, this is indeed a mistake. Thanks for letting me know.

Also, I found all the incorrect spellings of localCompare() you mentioned. You have a sharp eye! I'll log an erratum for each.

Thanks again.

Nicholas C. Zakas
Author, Professional JavaScript for Web Developers (ISBN 0764579088)
http://www.nczonline.net/
 
Old May 10th, 2006, 07:01 AM
nzakas's Avatar
Wrox Author
 
Join Date: Dec 2004
Posts: 217
Thanks: 0
Thanked 5 Times in 5 Posts
Default

Yes, it should be oStringObject1. A typo in my reply (doh!).

Nicholas C. Zakas
Author, Professional JavaScript for Web Developers (ISBN 0764579088)
http://www.nczonline.net/
 
Old May 11th, 2006, 01:00 AM
Authorized User
 
Join Date: May 2006
Posts: 31
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to kaos_frack
Default

It is not a mistake but a note for the next version of the book
This is about browser detection. I've read that Opera can be disguised as Internet Explorer or Mozilla, but 'userAgent' still returns a string which contains 'Opera [version]' at the end of it. Ninth version of Opera (which is still beta) has such options like 'Mask as Internet Explorer' and 'Mask as Mozilla' which do not contain 'Opera [version]'. I tried all the options one by one and entered 'javascript:alert(navigator.userAgent);' in address bar and below is the result.

Identify as Opera: Opera/9.00 (Windows NT 5.1; U; en)

Identify as Internet Explorer: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.00
Mask as Internet Explorer: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en)

Identify as Mozilla: Mozilla/5.0 (Windows NT 5.1; U; en) Opera 9.00
Mask as Mozilla: Mozilla/5.0 (Windows NT 5.1; U; en; rv:1.7.5) Gecko/20041110

Regards,
Jamolkhon

 
Old May 11th, 2006, 09:00 AM
nzakas's Avatar
Wrox Author
 
Join Date: Dec 2004
Posts: 217
Thanks: 0
Thanked 5 Times in 5 Posts
Default

Thanks for the note, I'll be sure to keep it in mind for a next edition.

Nicholas C. Zakas
Author, Professional JavaScript for Web Developers (ISBN 0764579088)
http://www.nczonline.net/
 
Old May 29th, 2006, 07:51 AM
Registered User
 
Join Date: May 2006
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Chapter 8, Page 236

The compareVersions(sVersion1, sVersion2) function.

My apologies if I'm off base here, as my current web-browser doesn't support javascript, so I haven't yet checked this out. It looks like there's a potential problem with the compareVersions function used in the browser and OS detection script built up in chapter 8. In this function, each string is split into an array of sub-strings, using the "." character as a separator. The shortest array is then padded with "0" strings to match the length of the longest array, and then corresponding sub-strings are successively compared. However, although each sub-string is assumed to represent a number, the comparison of each pair of sub-strings is string based. Therefore compareVersions("2.8", "2.11") returns 1 when it should return -1 (because "8" > "11").

I suggest either converting each substring to an integer, or additionally padding the shorter of the two sub-strings with zeroes.

Chris
 
Old May 29th, 2006, 10:50 AM
nzakas's Avatar
Wrox Author
 
Join Date: Dec 2004
Posts: 217
Thanks: 0
Thanked 5 Times in 5 Posts
Default

Chris,

You're right, it is doing a string comparison when it should be a numeric comparison. I'll make a note of it, thanks.

Nicholas

Nicholas C. Zakas
Author, Professional JavaScript for Web Developers (ISBN 0764579088)
http://www.nczonline.net/
 
Old May 30th, 2006, 03:21 PM
Registered User
 
Join Date: May 2006
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Nicholas,

On a related note, the detect.js script built up in chapter 8 also treats navigator.appVersion as a float. At the top of the script you have the following:

var fAppVersion = parseFloat(navigator.appVersion);

In all, there are actually four places where version strings are parsed as floats, and then numerical comparisons are made using these floats. Having considered this in a little more detail, I think this approach is fundamentally flawed. A simple example should illustrate the point - versions "1.1" and "1.10" are clearly ordered, yet both parse to the same floating point value after which it's impossible to reestablish the correct ordering. Since you already have the compareVersions() function for comparing version strings, why not use it, and avoid dealing with floats altogether?

Sorry if I'm being a bit picky here! I realize that few if any of the version numbers actually being compared by this script are likely to ever reach a minor point release of .10 or beyond before the major release number is incremented, but to me it feels like a fly in the ointment of an otherwise very comprehensive detection script. A simple google for detect.js yields several example scripts, none of which come close to being as comprehensive as the script you've created here. Well done!

Chris
 
Old July 18th, 2006, 05:51 PM
Registered User
 
Join Date: Jul 2006
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I didn't see this mentioned so-

Page 23 - Paragraph 2:
For example, if you want to convert the string "1234blue" to an integer, parseInt() would return a value of 1234 because it stops processing one it reaches the character b.

One should be once.

Jeff





Similar Threads
Thread Thread Starter Forum Replies Last Post
mistake in code yami56 Access 3 February 24th, 2005 04:04 PM
mistake in my topics zakarya_hazara Classic ASP Basics 1 October 9th, 2004 02:49 AM
Dangerous mistake revinchalil SQL Server 2000 4 February 4th, 2004 12:06 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.