Javascript library development

[Aaron Gray]

From what I have been looking at for Javascript library development,
browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like the
base level to pitch at.

Anyone add anything ?

Aaron

[Peter Michaux]

On Jul 11, 8:54 am, "Aaron Gray" <[e-mail]:

From what I have been looking at for Javascript library development,

Are you going to be writing your own library?

browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like the
base level to pitch at.

Roughly yes. It depends on your targeted user base and the browsers
they are using. If it is for the general web vs for an intranet where
everyone is using a single browser.

Anyone add anything ?

If you use feature detection and progressive enhancement your library
will fail gracefully in older browsers. It is a sustainable approach.
For example. navigator.userAgent should not appear in your library
code.

There is a lure that a single library can cover all possible
situations. That has never been shown to be true and if such a library
could be written it would be huge. Determining the position of an
element on the page is an example of a big problem.

Identify the requirements for you library and then either find or
write a library to suit that need.

Peter

[Aaron Gray]

"Peter Michaux" <pe**********@gmail.comwrote in message
news:a5**********************************@t54g2000 hsg.googlegroups.com...

On Jul 11, 8:54 am, "Aaron Gray" <[e-mail]:

>From what I have been looking at for Javascript library development,

Are you going to be writing your own library?

Yes.

>browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like
the
base level to pitch at.

Roughly yes. It depends on your targeted user base and the browsers
they are using. If it is for the general web vs for an intranet where
everyone is using a single browser.

Yes, it looks like the cutoff point.

There's the W3C DOM standard introduction and things like
document.documentElement which I have tried to address.

>Anyone add anything ?

If you use feature detection and progressive enhancement your library
will fail gracefully in older browsers. It is a sustainable approach.
For example. navigator.userAgent should not appear in your library
code.

Yes, other than for error reporting :)

There is a lure that a single library can cover all possible
situations. That has never been shown to be true and if such a library
could be written it would be huge.

Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
very expensive for commercial usage. I am looking at creating a frame work
with widget structure a few basic widgets and publish it under the LGPL,
then hopefully if it is anygood others will contribute, thats the idea
anyway.

Determining the position of an
element on the page is an example of a big problem.

Right. I try to use events attached to elements where ever possible.

Identify the requirements for you library and then either find or
write a library to suit that need.

ExtJS is the only contender but as I said it is prohibitorly expensive for
small scale commercial usage.

Aaron

[Peter Michaux]

On Jul 12, 12:02 pm, "Aaron Gray" <[e-mail]:

"Peter Michaux" <[e-mail] in message
news:a5**********************************@t54g2000 hsg.googlegroups.com...

On Jul 11, 8:54 am, "Aaron Gray" <[e-mail]:

From what I have been looking at for Javascript library development,

Are you going to be writing your own library?

Yes.

With all due respect, if you are new enough to browser scripting to be
asking the questions that you are, I suggest you write a few libraries
and really explore the JavaScript language and the browser runtimes
before you release a library to the world. By explore, I mean spend at
least a year reading other libraries, writing example libraries,
reading articles by programmers like Richard Cornford and Douglas
Crockford. Crockford's "javascript: the good parts" book is really the
only book on JavaScript that attempts to explore the lambda-nature of
JavaScript and exploit it for maximum gain. Books about Lisp and
Scheme (especially "Structure and Interpretation of Computer Programs"
by Abelson and Sussman) which are lambda languages, are generally far
higher quality than JavaScript books but the ideas translate to
JavaScript quite readily. Quality books on browser scripting are at
least hard to find.

On the web it is already possible to download JavaScript libraries for
browser scripting with APIs that were published and subsequently
"fixed" by people with little experience writing browser scripts and
who seemed to carry a lot of baggage and/or preconceived ideas about
how to program from whatever language they wrote in before they
arrived in JavaScript. (Usually they programmed in a class-based, non-
lambda language which is almost polar opposite to JavaScript.) These
efforts have resulted in libraries that don't maximize use of the
things JavaScript does well, don't fully acknowledge the realities of
the browser environment and use feature detection to deal with them,
assume they know the right way to do things and end up with an API
that is really difficult to make work with the techniques they would
choose with more experience.

If you use feature detection and progressive enhancement your library
will fail gracefully in older browsers. It is a sustainable approach.
For example. navigator.userAgent should not appear in your library
code.

Yes, other than for error reporting :)

What kind of error reporting?

There is a lure that a single library can cover all possible
situations. That has never been shown to be true and if such a library
could be written it would be huge.

Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
very expensive for commercial usage. I am looking at creating a frame work
with widget structure a few basic widgets and publish it under the LGPL,
then hopefully if it is anygood others will contribute, thats the idea
anyway.

Determining the position of an
element on the page is an example of a big problem.

Right. I try to use events attached to elements where ever possible.

Event target resolution is not what I was referring to in this case.
That would be a really crazy way to identify what was clicked, for
example.

Identify the requirements for you library and then either find or
write a library to suit that need.

ExtJS is the only contender

Why? All the regulars on this group write browser scripts and I think
none uses ExtJS.

but as I said it is prohibitorly expensive for
small scale commercial usage.

If the quality of ExtJS is considered acceptable (which would likely
be highly debated on this newsgroup) then why not fork the last
version of ExtJS that was free for commercial use?

Peter

[Aaron Gray]

"Peter Michaux" <pe**********@gmail.comwrote in message
news:6f**********************************@k37g2000 hsf.googlegroups.com...

On Jul 12, 12:02 pm, "Aaron Gray" <[e-mail]:

>"Peter Michaux" <[e-mail] in message
news:a5**********************************@t54g200 0hsg.googlegroups.com...

On Jul 11, 8:54 am, "Aaron Gray" <[e-mail]:
From what I have been looking at for Javascript library development,

Are you going to be writing your own library?

Yes.

With all due respect, if you are new enough to browser scripting to be
asking the questions that you are, I suggest you write a few libraries
and really explore the JavaScript language and the browser runtimes
before you release a library to the world. By explore, I mean spend at
least a year reading other libraries, writing example libraries,
reading articles by programmers like Richard Cornford and Douglas
Crockford. Crockford's "javascript: the good parts" book is really the
only book on JavaScript that attempts to explore the lambda-nature of
JavaScript and exploit it for maximum gain. Books about Lisp and
Scheme (especially "Structure and Interpretation of Computer Programs"
by Abelson and Sussman) which are lambda languages, are generally far
higher quality than JavaScript books but the ideas translate to
JavaScript quite readily. Quality books on browser scripting are at
least hard to find.

Try John Resig's book and site.

On the web it is already possible to download JavaScript libraries for
browser scripting with APIs that were published and subsequently
"fixed" by people with little experience writing browser scripts and
who seemed to carry a lot of baggage and/or preconceived ideas about
how to program from whatever language they wrote in before they
arrived in JavaScript. (Usually they programmed in a class-based, non-
lambda language which is almost polar opposite to JavaScript.) These
efforts have resulted in libraries that don't maximize use of the
things JavaScript does well, don't fully acknowledge the realities of
the browser environment and use feature detection to deal with them,
assume they know the right way to do things and end up with an API
that is really difficult to make work with the techniques they would
choose with more experience.

Yep, I do agree to some degree.

If you use feature detection and progressive enhancement your library
will fail gracefully in older browsers. It is a sustainable approach.
For example. navigator.userAgent should not appear in your library
code.

Yes, other than for error reporting :)

What kind of error reporting?

If an error occurs in the Library then it uses AJAX to send home an error
report with as much information as it can gather, this is then entered into
a MySQL database app and a report produced and sent by email to me and maybe
me and the user of the library.

There is a lure that a single library can cover all possible
situations. That has never been shown to be true and if such a library
could be written it would be huge.

Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
very expensive for commercial usage. I am looking at creating a frame
work
with widget structure a few basic widgets and publish it under the LGPL,
then hopefully if it is anygood others will contribute, thats the idea
anyway.

Determining the position of an
element on the page is an example of a big problem.

Right. I try to use events attached to elements where ever possible.

Event target resolution is not what I was referring to in this case.
That would be a really crazy way to identify what was clicked, for
example.

For most click events the object that is clicked on is where the click event
is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
me to other uses if there are some :)

>

Identify the requirements for you library and then either find or
write a library to suit that need.

ExtJS is the only contender

Why? All the regulars on this group write browser scripts and I think
none uses ExtJS.

Then where are the general UI libraries that are any good. Bespoke code is
good but it is not generally complatible with other bespoke code and making
libraries is what is interesting to me.

Laying down the right framework is crucial.

>but as I said it is prohibitorly expensive for
small scale commercial usage.

If the quality of ExtJS is considered acceptable (which would likely
be highly debated on this newsgroup) then why not fork the last
version of ExtJS that was free for commercial use?

I have looked at ExtJS's code and yes its not brilliant if you look at the
DOM generated there ar unclosed <div>'s and <ul>'s in the tree control,
unless this is due to a bug in FireBug and DebugBar.

Yahoo's UI is even less self integrated.

Where are the good libraries ? I am not into making just another wheel, I
want a good wheel.

Peter, most of the time I post to newsgroups I am just trying to get
pragmatics of an issue which UseNet is usually great for.

Basically I have been programming in Javascript on and off for over three
years now. And I want my own framework and UI library that works hopefully
on any Javascript 1.6 / ECMA3 compilant browser, hence the questions.

Regards,

Aaron

[Gregor Kofler]

Aaron Gray meinte:

>Quality books on browser scripting are at
least hard to find.

Try John Resig's book and site.

Er... why? Most regulars here - including Peter - have a much better
understanding of JS than the "JavaScript Ninja".

As stated: Crockford's "JS the Good Parts" is definitely worth reading.

For most click events the object that is clicked on is where the click event
is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
me to other uses if there are some :)

Events bubble. Instead of attaching a listener to every node of my XHR
tree widget, one attached to the container of the tree does the job. The
clicked element is identified via its class name.

>>ExtJS is the only contender

Why? All the regulars on this group write browser scripts and I think
none uses ExtJS.

Then where are the general UI libraries that are any good.

Because there are no good "general UI library" - and perhaps never will
be. It's this "general" that causes so much trouble.

Where are the good libraries ? I am not into making just another wheel, I
want a good wheel.

Either write your own (that's the most likely suggestion you gonna get
here), or pick whatever you want and live with the shortcomings.

Gregor


--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Aaron Gray]

"Gregor Kofler" <us****@gregorkofler.atwrote in message
news:Jx*************@nntpserver.swip.net...

Aaron Gray meinte:

>>Quality books on browser scripting are at
least hard to find.

Try John Resig's book and site.

Er... why? Most regulars here - including Peter - have a much better
understanding of JS than the "JavaScript Ninja".

Right I have just looked at the contents on Amazon.

As stated: Crockford's "JS the Good Parts" is definitely worth reading.

Right.

>For most click events the object that is clicked on is where the click
event is needed. Its only DnD that needs anything smarter AFAICS. Please
enlighten me to other uses if there are some :)

Events bubble. Instead of attaching a listener to every node of my XHR
tree widget, one attached to the container of the tree does the job. The
clicked element is identified via its class name.

>>>ExtJS is the only contender
Why? All the regulars on this group write browser scripts and I think
none uses ExtJS.

Then where are the general UI libraries that are any good.

Because there are no good "general UI library" - and perhaps never will
be. It's this "general" that causes so much trouble.

I agree, but am taking up the chalenge to try to make one, may probably fail
but then at least I have tried.

>Where are the good libraries ? I am not into making just another wheel, I
want a good wheel.

Either write your own (that's the most likely suggestion you gonna get
here), or pick whatever you want and live with the shortcomings.

Writing my own is the best option, then atleast if I want to modify it I
know how rather than maybe using a hodgepodge of the others and ending in an
entropic state.

Aaron

[Richard Cornford]

Aaron Gray wrote:

Peter Michaux wrote:

>On Jul 12, 12:02 pm, Aaron Gray wrote:

>>Peter Michaux wrote:

<snip>

>>>Are you going to be writing your own library?

Yes.

With all due respect, if you are new enough to browser scripting
to be asking the questions that you are, I suggest you write a
few libraries and really explore the JavaScript language and the
browser runtimes before you release a library to the world.

<snip>

>Books about Lisp and Scheme (especially "Structure and
Interpretation of Computer Programs" by Abelson and Sussman)
which are lambda languages, are generally far higher quality
than JavaScript books but the ideas translate to JavaScript
quite readily. Quality books on browser scripting are at
least hard to find.

Try John Resig's book and site.

That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-

"Since valid HTML is simply a subset of XML, having an efficient way to
parse and browser DOM documents is an absolutely essential for making
JavaScript development easier."

"Even if you're not completely familiar with XML, you will get great
satisfaction knowing that all HTML documents (which are, in the eyes of
the browser, XML documents) have a DOM representation that is ready to
use."

"Since the use of JavaScript in nonbrowser settings (e.g., server-side
JavaScript) is still rather experimental, the feature set of JavaScript
is still very browser-centric. Thus, the features available in
JavaScript are very closely tied to how browsers evolve and which
features they (or their users) deem as the most important."

"Additionally, an object can contain a set of properties, all of which
are simply references to other objects (such as strings, numbers,
arrays, etc.)."

"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."

"The this variable will always refer to the object that the code is
currently inside of."

"In JavaScript, null, 0, '', false, and undefined are all equal (==) to
each other, since they all evaluate to false. This means that if you use
the code test == false, it will evaluate true if test is also undefined
or equal to null, which may not be what you want."

"Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined"

"Compression should be used as the final step, just before putting your
code into production, as your code will frequently become obfuscated
beyond recognition."

"This particular naming convention arose due to the fact that words such
as class, for, float, and text are all reserved words in JavaScript."

- and many other examples of technical fallacies, misconceptions and bad
practices.

Peter's point is, in effect, that if you don't know enough about
javascript and browser scripting to recognise a bad book when you see
one then maybe you should be a bit circumspect about rushing into
designing a library and dumping it on a community who have less
understanding of what they are doing than you do.

<snip>

Basically I have been programming in Javascript on and off for
over three years now. And I want my own framework and UI
library that works hopefully on any Javascript 1.6 / ECMA3
compilant browser, hence the questions.

Well, it will make a change for IceBrowser, Konqueror and NetFront to
get a look-in.

Richard.

[Aaron Gray]

"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:g5*******************@news.demon.co.uk...

Aaron Gray wrote:

>Peter Michaux wrote:

>>On Jul 12, 12:02 pm, Aaron Gray wrote:
Peter Michaux wrote:

<snip>

>Try John Resig's book and site.

That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-

"Since valid HTML is simply a subset of XML, having an efficient way to
parse and browser DOM documents is an absolutely essential for making
JavaScript development easier."

"Even if you're not completely familiar with XML, you will get great
satisfaction knowing that all HTML documents (which are, in the eyes of
the browser, XML documents) have a DOM representation that is ready to
use."

"Since the use of JavaScript in nonbrowser settings (e.g., server-side
JavaScript) is still rather experimental, the feature set of JavaScript is
still very browser-centric. Thus, the features available in JavaScript are
very closely tied to how browsers evolve and which features they (or their
users) deem as the most important."

"Additionally, an object can contain a set of properties, all of which are
simply references to other objects (such as strings, numbers, arrays,
etc.)."

"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."

"The this variable will always refer to the object that the code is
currently inside of."

"In JavaScript, null, 0, '', false, and undefined are all equal (==) to
each other, since they all evaluate to false. This means that if you use
the code test == false, it will evaluate true if test is also undefined or
equal to null, which may not be what you want."

"Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined"

"Compression should be used as the final step, just before putting your
code into production, as your code will frequently become obfuscated
beyond recognition."

"This particular naming convention arose due to the fact that words such
as class, for, float, and text are all reserved words in JavaScript."

- and many other examples of technical fallacies, misconceptions and bad
practices.

I thought he looked a bit young :)

You typed in all that ?

Have not read the book just read his web site which on the whole is pritty
good.

Yeah, you only have to look at the second hand price of the "new"ish book on
Amazon.

Oh well its probably okay for some people. I will probably still buy the
book just to see if there are some gems in it, then pass it on as a hand me
down if I don't then still want to keep it.

So its back to Douglas then, there's some goodies from him on Yahoo theatre
:-

http://developer.yahoo.com/yui/theater/

Peter's point is, in effect, that if you don't know enough about
javascript and browser scripting to recognise a bad book when you see one
then maybe you should be a bit circumspect about rushing into designing a
library and dumping it on a community who have less understanding of what
they are doing than you do.

Javascript is a real evolving thing, I have been learning it and relearning
it looking ahead at Javascript 2.0 and getting a good overview of the lay of
the land.

<snip>

>Basically I have been programming in Javascript on and off for
over three years now. And I want my own framework and UI
library that works hopefully on any Javascript 1.6 / ECMA3
compilant browser, hence the questions.

Sorry that should be Javascript 1.5.

Well, it will make a change for IceBrowser, Konqueror and NetFront to get
a look-in.

I want to write the foundations to include as many browsers as possible from
a reasonable baseline, thats the plan anyway if it is possible then its
worth doing.

I am basically putting together a base level "legacy" support library, and
do a test set for it so that it can be tested on a range of browsers.

To be clever but not too clever with the level of Javascript coding is the
name of the game, some of the newer stuff is just too clever for its own
good, substituting efficiency and readability for technical prowesk.

Thanks Richard, some of those quotes were quite funny :)

Aaron

[Richard Cornford]

Aaron Gray wrote:

Richard Cornford wrote:

>Aaron Gray wrote:

>>Peter Michaux wrote:
On Jul 12, 12:02 pm, Aaron Gray wrote:
Peter Michaux wrote:

<snip>

>>Try John Resig's book and site.

That "John Resig's book" would be "Pro JavaScript Techniques"?
The book that contains:-

<snip>

>"This particular naming convention arose due to the fact that
words such as class, for, float, and text are all reserved words
in JavaScript."

- and many other examples of technical fallacies, misconceptions
and bad practices.

I thought he looked a bit young :)

Youth would not, it itself, be a barrier to understanding javascript.
ES3 is not that complex else it would not be possible for its
specification to be just 170 odd page (with 10% of that entirely devoted
to regular expressions).

You typed in all that ?

No, I copied it from a list I have in a document. Though I did type the
list originally so I cannot promise that it is typo free. I used them as
humorous signatures for a month or so (john Resig didn't see the joke),
but have stopped now. The fear was express that my quoting them might be
taken as an endorsement.

Have not read the book just read his web site which on the whole
is pritty good.

YMMV

Yeah, you only have to look at the second hand price of the
"new"ish book on Amazon.

Low is it?

<snip>

I want to write the foundations to include as many browsers as
possible from a reasonable baseline, thats the plan anyway if
it is possible then its worth doing.

I don't think "possible" == "worth doing" holds.

I am basically putting together a base level "legacy" support
library, and do a test set for it so that it can be tested on
a range of browsers.

To be clever but not too clever with the level of Javascript
coding is the name of the game, some of the newer stuff is
just too clever for its own good, substituting efficiency
and readability for technical prowesk.

Yes, the last couple of years have seen the arrival of "do it this way
because it is cool". Talking design to people who take that attitude is
a bit like beating your head against a wall. (What is the best part of
beating your head against a wall? - Stopping.)

Thanks Richard, some of those quotes were quite funny :)

I thought so. (That or they'd make you cry.)

Richard.

[Peter Michaux]

On Jul 12, 4:02 pm, "Aaron Gray" <[e-mail]:

[snip]

If an error occurs in the Library then it uses AJAX to send home an error
report with as much information as it can gather, this is then entered into
a MySQL database app and a report produced and sent by email to me and maybe
me and the user of the library.

This is a nice idea but don't rely on the navigator.userAgent string
completely. The message the browser sends to the server could also
include the results of your feature tests. Then you could determine if
the navigator.userAgent correlates to the feature test results. Even
then you might have trouble. Just for IE6 there are many different
configurations and effectively IE6 could be seen as at least tens of
different browsers depending on the operating system configuration,
security options in the browser, etc.

Probably best to send this message with something very low tech like
creating an image element and setting the src property. Using
XMLHttpRequest for this would likely disable many of the browsers from
which you would like to receive messages from even being able to send
the message. In fact perhaps you'd want to try sending the message a
few different ways to make sure the message got through.

For most click events the object that is clicked on is where the click event
is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
me to other uses if there are some :)

There are many other situations where event delegation could be handy.
If you have a list and you are adding and removing elements, it is
simpler if the list is listening for events rather than having to add
listeners to each element as it is inserted.

Identify the requirements for you library and then either find or
write a library to suit that need.

ExtJS is the only contender

Why? All the regulars on this group write browser scripts and I think
none uses ExtJS.

Then where are the general UI libraries that are any good. Bespoke code is
good but it is not generally complatible with other bespoke code and making
libraries is what is interesting to me.

Laying down the right framework is crucial.

For a foundation, I'd suggest starting with a multi-browser event
library. That contains plenty of browser bugs and you will need to
make decisions about how to handle the various problems. For example,
in versions of Safari up to something like version 2.0.2, there was a
bug where prevent default didn't work for click and double click
events when the handler was added with addEventHandler. If the handler
is added by setting the onclick property of the element then prevent
default does work. As far as I know there is no feature test to detect
this issue. However these versions of Safari are getting old. What is
the right thing to do? The event library problem alone allows for very
rich exploration into the building of a multi-browser library. It has
been for me anyway. Building a solution entails feature detection
techniques, realizing "general" is a problem as Gregor rightly notes,
API design, knowing how to build a small solution with the JavaScript
language, etc.

but as I said it is prohibitorly expensive for
small scale commercial usage.

If the quality of ExtJS is considered acceptable (which would likely
be highly debated on this newsgroup) then why not fork the last
version of ExtJS that was free for commercial use?

I have looked at ExtJS's code and yes its not brilliant if you look at the
DOM generated there ar unclosed <div>'s and <ul>'s in the tree control,
unless this is due to a bug in FireBug and DebugBar.

Yahoo's UI is even less self integrated.

Where are the good libraries?

They seem to be hard to find.

I am not into making just another wheel, I
want a good wheel.

The mainstream libraries are certainly not perfectly round wheels. So
if you need a round one you may have to build your own. First you need
to decide the requirements for your library.

Peter, most of the time I post to newsgroups I am just trying to get
pragmatics of an issue which UseNet is usually great for.

Basically I have been programming in Javascript on and off for over three
years now. And I want my own framework and UI library that works hopefully
on any Javascript 1.6 / ECMA3 compilant browser, hence the questions.

I think learning as much as you can about feature testing techniques
is the most productive way to start. There is an article in the
group's FAQ notes which is a probably a very good place to start.

http://www.jibbering.com/faq/faq_not...er_detect.html

Peter

[Gregor Kofler]

Aaron Gray meinte:

"Gregor Kofler" <us****@gregorkofler.atwrote in message
news:Jx*************@nntpserver.swip.net...

>Because there are no good "general UI library" - and perhaps never will
be. It's this "general" that causes so much trouble.

I agree, but am taking up the chalenge to try to make one, may probably fail
but then at least I have tried.

My "core library" is about 15k: some DOM functions, event handling, some
small prototype extensions. If I need XHR the according library eats up
another 8-9k, most of it for Douglas' JSON functions. Another small
library does drag and drop (5k).

On top of those small scripts I write my widgets. Works for me.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Jorge]

On Jul 13, 3:04*am, "Richard Cornford" <[e-mail]>
wrote:

That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-

(...)

"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."

javascript:a= new String("Hola");alert(a === (a+ ""));alert(typeof a);

--false, object.

javascript:a= "Hola";alert(a === (a+ ""));alert(typeof a);

--true, string.
--Jorge.

[Jorge]

On Jul 13, 3:04 am, "Richard Cornford" <[e-mail]>
wrote:

That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-
(...)
"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."

javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--object, false, string.

javascript:a= "Hola";alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--string, true, string.

--Jorge.

[Thomas 'PointedEars' Lahn]

Peter Michaux wrote:

On Jul 11, 8:54 am, "Aaron Gray" <[e-mail]:

>browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks
like the base level to pitch at.

Roughly yes. It depends on your targeted user base and the browsers they
are using. If it is for the general web vs for an intranet where

^^^^^^^^^^^^^^^^^

everyone is using a single browser.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This should be understood as an AND-connected condition about the truth of
the statement. An intranet does _not_ mean everybody using it is using the
same user agent. And even if that applies *now*, it is very likely _not_ to
be true in the foreseeable future. Think about employees using mobile
devices like iPhone, for example.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

Jorge wrote:

"Richard Cornford" wrote:

>That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-
(...)
"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."

javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--object, false, string.

javascript:a= "Hola";alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--string, true, string.

What exactly is the point you are trying to make here?

( ) Your confirming that John Resig does not know what he is writing about.
( ) Your not understanding what a String object is.

(It is a radio button group. Choose one.)
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Jorge]

On Jul 13, 11:39*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Jorge wrote:

"Richard Cornford" wrote:

That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-
(...)
"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."

javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--object, false, string.

javascript:a= "Hola";alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--string, true, string.

What exactly is the point you are trying to make here?

( ) Your confirming that John Resig does not know what he is writing about.
( ) Your not understanding what a String object is.

(It is a radio button group. *Choose one.)

(·) Your not understanding what a String object is.

javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
+= ""));
--object, true, false, string, object, true.
--Jorge.

[Gregor Kofler]

Jorge meinte:

javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
+= ""));
--object, true, false, string, object, true.

Still, what's your point? Everything works as expected.

"String objects are created by calling the constructor new String(). The
String object wraps Javascript's string primitive data type with the
methods described below. The global function String() can also be called
without new in front to create a primitive string. String literals in
JavaScript are primitive strings.

Because Javascript automatically converts between string primitives and
String objects, you can call any of the methods of the String object on
a string primitive. JavaScript automatically converts the string
primitive to a temporary String object, calls the method, then discards
the temporary String object." [1]

Gregor
[1]
<http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Strin g>
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Thomas 'PointedEars' Lahn]

Jorge wrote:

Thomas 'PointedEars' Lahn wrote:

>Jorge wrote:

>>"Richard Cornford" wrote:
That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-
(...)
"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."
javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--object, false, string.
javascript:a= "Hola";alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--string, true, string.

What exactly is the point you are trying to make here?

( ) Your confirming that John Resig does not know what he is writing about.
( ) Your not understanding what a String object is.

(It is a radio button group. Choose one.)

(·) Your not understanding what a String object is.

I see.

javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
+= ""));
--object, true, false, string, object, true.

You have not named the implementation that you have tested with. However,
it works there as specified. Yet you missed the point:

"foo" is a primitive string value. new String("foo"), on the other hand, is
a reference to a newly created String object (which is rather bloated, in
comparison). While the string concatenation operation, be it `+' or `+=',
works for both values as operands (same "type" and mixed), its result is
(unsurprisingly) always a primitive string value, _not_ (a reference to) a
String object (as e.g. the `typeof' operation shows when applied to it).

IOW, John Resig does not know what he is writing about (there). Hopefully,
you will begin to as of now.
HTH

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Jorge]

On Jul 14, 10:07*am, Gregor Kofler <[e-mail]:

Jorge meinte:

javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
+= ""));
--object, true, false, string, object, true.

Still, what's your point?

That yes, that string concatenation (even when fed with string
object(s)) yields string primitive values not string objects.

Try with "string".concat("string") and ["string"].join("string"), and
the results are the same :

javascript:alert(typeof (new String("Hola")).concat(""));
--string.

javascript:alert(typeof [new String("Hola")].join(""));
--string.

Still, Resig is right in the sense that a there's no way to modify a
string object. Or not ?

--Jorge.

[Peter Michaux]

On Jul 14, 10:27 am, Jorge <[e-mail]:

On Jul 14, 10:07 am, Gregor Kofler <[e-mail]:

Jorge meinte:

javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
+= ""));
--object, true, false, string, object, true.

Still, what's your point?

That yes, that string concatenation (even when fed with string
object(s)) yields string primitive values not string objects.

Try with "string".concat("string") and ["string"].join("string"), and
the results are the same :

javascript:alert(typeof (new String("Hola")).concat(""));
--string.

javascript:alert(typeof [new String("Hola")].join(""));
--string.

Just out of curiosity, since you are using the javascript protocol for
testing, do you know about the console in the Firebug extension for
Firefox?

Still, Resig is right in the sense that a there's no way to modify a
string object. Or not ?

You can modify a String object at least in the sense you can add
properties to it.

var s = new String("Hola");

alert(s.doAlert) ; undefined

s.doAlert = function() {
alert(this);
};

alert(s.doAlert) ; function()...

s.doAlert() ; makes an alert "Hola"

Peter

[Jorge]

On Jul 14, 6:07*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>
(...)

( ) Your not understanding what a String object is.

(It is a radio button group. Choose one.)

(...)

IOW, John Resig does not know what he is writing about (there).
Hopefully, you will begin to as of now.

( ) You forgot to take today's medication.
( ) You ran out of pills.

(It is a radio button group. Choose one.)

:-)

Regards,
--Jorge.

[Jorge]

On Jul 14, 7:41*pm, Peter Michaux <[e-mail]:

On Jul 14, 10:27 am, Jorge <[e-mail]:

On Jul 14, 10:07 am, Gregor Kofler <[e-mail]:

Jorge meinte:

javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
+= ""));
--object, true, false, string, object, true.

Still, what's your point?

That yes, that string concatenation (even when fed with string
object(s)) yields string primitive values not string objects.

Try with "string".concat("string") and ["string"].join("string"), and
the results are the same :

javascript:alert(typeof (new String("Hola")).concat(""));
--string.

javascript:alert(typeof [new String("Hola")].join(""));
--string.

Just out of curiosity, since you are using the javascript protocol for
testing, do you know about the console in the Firebug extension for
Firefox?

Still, Resig is right in the sense that a there's no way to modify a
string object. Or not ?

You can modify a String object at least in the sense you can add
properties to it.

Ok. Let's say that "there's no way to change the string in a string
object". (?)

--Jorge.

[Peter Michaux]

On Jul 14, 10:41 am, Peter Michaux <[e-mail]:

s.doAlert() ; makes an alert "Hola"

Oops. I've been programming more Lisp than JavaScript lately. Make
that ";" a "//".

Peter

[Mike Duffy]

"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in news:g5gpba$1bs$1
$8*******@news.demon.co.uk:

Jorge wrote:

There is another pattern to be observed here; that superficial success
(...) results in massive overconfidence. The belief
that you have cracked the problem, seen the truth, learnt everything of
importance and entered the inner circle. It is a dangerous phenomenon,
partly because it encourages people to go out and do things that may not
be such a good idea in retrospect, and partly because confidence that
you already know everything can be a huge barrier to learning more
(and/or recognising that you may be wrong).

This can be said about almost any discipline. It may be though, that
programming languages make the mistakes more obvious, much in the same way
that it is impossible to proof-read your own prose.

Also, when you only see the final product, it is not obvious how much time
was spent exploring dead-end paths. (Also called "hands-on" learning.)