473,561 Members | 3,076 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

How a delete a object from DOM ?

I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.

Aug 3 '06 #1
22 4163
Cylix wrote:
I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.
Oh, Sorry, I found the way to do so already ...

Suppose "row" is the object going to delete:
row.parentNode. removeChild(row );

Aug 3 '06 #2
Ray
Cylix wrote:
I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.
Can't you remove the <TRfrom the <TBODY>? E.g. for the third row, if
tbody refers to the TBODY element:

tbody.removeChi ld(tbody.childN odes[2]);

Ray

Aug 3 '06 #3
Cylix wrote:
I have a 4row x 1col table, I would like to drop all the content of row
three.
Since Mac IE5.2 does not suppport deleteRow method,
I have also try to set the innerHTML=''; but it does not work.

How can I delete the node from DOM in other way?
Thanks.
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>

Usage:
<script>
$del(ObjectIDSt ring);
</script>

Methods are lame because you have to repeat yourself. They are fine for
toolkits but not applications, which should be created in plain english
or as close as you can get.

hth

http://darwinist.googlepages.com/htmldesktop.html

Aug 3 '06 #4
da*******@gmail .com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write code
that uses such identifiers in non-machine generated Identifiers. All
real javascript programmers can be expected to be familiar with that
formal convention and so bring expectations to their reading of code
that uses Identifiers that start with - $ -, which, when disappointed,
will result in wasted time and effort, thus needlessly increasing code
maintenance costs. (Not to mention the impact of using such
self-evidently obscure Identifiers in code).

Though in practice wrapping calls to - removeChild - in two function
calls, and requiring that Elements referenced have ID attributes would
not be a good idea anyway. In most cases the desire to remove an element
from the DOM implies already having a reference to that element so its
parent's - removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's memory leak
problem would suggest minimising their use in any event.

Richard.
Aug 3 '06 #5
Richard Cornford wrote:
da*******@gmail .com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write code
that uses such identifiers in non-machine generated Identifiers. All
real javascript programmers can be expected to be familiar with that
formal convention and so bring expectations to their reading of code
that uses Identifiers that start with - $ -, which, when disappointed,
will result in wasted time and effort, thus needlessly increasing code
maintenance costs. (Not to mention the impact of using such
self-evidently obscure Identifiers in code).
I disagree, i find it highly intuitive to group functions which handle
dom-related elements, and it works across browsers.

You can talk in vague theory about obscure code and confused
programmers but I'm not convinced. I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html
Though in practice wrapping calls to - removeChild - in two function
calls, and requiring that Elements referenced have ID attributes would
not be a good idea anyway. In most cases the desire to remove an element
from the DOM implies already having a reference to that element so its
parent's - removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's memory leak
problem would suggest minimising their use in any event.
An important consideration, and one of which I was not aware. On the
other hand, it runs like lightning in firefox and microsoft will
readily admit their browser update is long overdue. I'm not
particularly interested in coding to the bugs of a product whose
manufacturers don't even pretend it's good anymore.

$del("id"); is quick and easy and allows you to be more productive.
Richard.
Aug 4 '06 #6
da*******@gmail .com wrote:
Richard Cornford wrote:
>da*******@gmail .com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write
code that uses such identifiers in non-machine generated
Identifiers. All real javascript programmers can be expected to be
familiar with that formal convention and so bring expectations to
their reading of code that uses Identifiers that start with - $ -,
which, when disappointed, will result in wasted time and effort,
thus needlessly increasing code maintenance costs. (Not to mention
the impact of using such self-evidently obscure Identifiers in code).

I disagree,
The existence of the convention in the language's specification is fact.
i find it highly intuitive to group functions which handle
dom-related elements, and it works across browsers.
What 'works' is not really an issue. Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider readability of
your code for programmers who are familiar with the well known and
established conventions.
You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.
Working to programming conventions is such a sensible idea that software
houses tend to formalise a set of conventions and insist that all their
programmers work to those. They don't do that because following
conventions represents a 'vague theory', they do it because it reduces
their code maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions for most
languages coming from various sources, and conventions that are found in
the pertinent language's specification are likely to be common in use.
I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html
Don't be silly.
>Though in practice wrapping calls to - removeChild - in
two function calls, and requiring that Elements referenced
have ID attributes would not be a good idea anyway. In most
cases the desire to remove an element from the DOM implies
already having a reference to that element so its parent's
- removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's
memory leak problem would suggest minimising their use in any
event.

An important consideration, and one of which I was not aware.
On the other hand, it runs like lightning in firefox and
microsoft will readily admit their browser update is long
overdue.
Overdue as it may be, commercial browser scripting has to accommodate IE
browsers. If you would prefer to work in some personal 'hobby' market
that is up to you but that does not mean that proposing practices that
are not suitable in a commercial environment is a good idea.
I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.
What it does for you is not relevant. It will potentially get in the way
of the productivity of a third party knowledgeable javascript programmer
attempting to maintain your code as they will have to spend effort
determining that this apparently machine generated Identifier is not
actually machine generated (and then expend effort re-writing your code
to eliminate the faulty Identifiers).

The overall impact of having to stuff a document with an excessive
number of unique element IDs may be less apparent, but it will act to
hinder development in the longer term.

Generally, javascript is easier to write, maintain and understand when
it uses references to objects directly instead of indirectly referring
to them with string values representing names and IDs.

Richard.
Aug 4 '06 #7
Richard Cornford wrote:
da*******@gmail .com wrote:
Richard Cornford wrote:
da*******@gmail .com wrote:
<snip>
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly states that
Identifiers beginning with the - $ - symbol are intended to signify
machine generated Identifiers it is poor javascript design to write
code that uses such identifiers in non-machine generated
Identifiers. All real javascript programmers can be expected to be
familiar with that formal convention and so bring expectations to
their reading of code that uses Identifiers that start with - $ -,
which, when disappointed, will result in wasted time and effort,
thus needlessly increasing code maintenance costs. (Not to mention
the impact of using such self-evidently obscure Identifiers in code).
I disagree,

The existence of the convention in the language's specification is fact.
I disagree that it will add to net confusion or obscurity.
i find it highly intuitive to group functions which handle
dom-related elements, and it works across browsers.

What 'works' is not really an issue.
Sorry I must have misheard you. Could you say that again?
Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider readability of
your code for programmers who are familiar with the well known and
established conventions.
Not all conventions are of equal value. It depends on how well any
convention is suited to the task that your code is intended to achieve.
You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.

Working to programming conventions is such a sensible idea that software
houses tend to formalise a set of conventions and insist that all their
programmers work to those. They don't do that because following
conventions represents a 'vague theory', they do it because it reduces
their code maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions for most
languages coming from various sources, and conventions that are found in
the pertinent language's specification are likely to be common in use.
There are lots of conventions and they don't always agree.
I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.
Don't be puritanical.
Though in practice wrapping calls to - removeChild - in
two function calls, and requiring that Elements referenced
have ID attributes would not be a good idea anyway. In most
cases the desire to remove an element from the DOM implies
already having a reference to that element so its parent's
- removeChild - method could be more easily called directly,
and the impact of giving elements ID attributes on IE's
memory leak problem would suggest minimising their use in any
event.
An important consideration, and one of which I was not aware.
On the other hand, it runs like lightning in firefox and
microsoft will readily admit their browser update is long
overdue.

Overdue as it may be, commercial browser scripting has to accommodate IE
browsers. If you would prefer to work in some personal 'hobby' market
that is up to you but that does not mean that proposing practices that
are not suitable in a commercial environment is a good idea.
You have much more time to test and optimise for speed if you can
express the initial applicaton at some level higher than the base
toolkit. Methods are lame because they don't know anything about your
application.
I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get in the way
of the productivity of a third party knowledgeable javascript programmer
attempting to maintain your code as they will have to spend effort
determining that this apparently machine generated Identifier is not
actually machine generated (and then expend effort re-writing your code
to eliminate the faulty Identifiers).
a) it's a common practice (ask google if you don't believe me)
b) it makes your code shorter and more readable
c) you can combine it with other useful element functions, like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node
d) this approach allows you write applications more quickly.
e) you can then optimise for speed in any areas that are script-heavy.
f) most programmers would know it to be a waste of time to rewrite
something that works for style alone
g) In this particular case, nobody would be confused for more than ten
seconds, if at all, after which this function will save them a great
many keystrokes, without a noticable difference in page performance.
The overall impact of having to stuff a document with an excessive
number of unique element IDs may be less apparent, but it will act to
hinder development in the longer term.
So will long and complicated statements, which are inevitable if you
stick as close as possible to the native javascript/dom methods when
writing your applicatoin.
Generally, javascript is easier to write, maintain and understand when
it uses references to objects directly instead of indirectly referring
to them with string values representing names and IDs.
True, but to get the initial reference you often have to use id, and if
you do this many times in a document, on various events for example,
then you're going to get sick of typing document.getEle mentById() for
such a common task.

Also you could modify $del() to accept either elements(by reference) or
IDs and act accordingly.

---
http://darwinist.googlepages.com/htmldesktop.html
(A free, open-source web-based IDE, windowing system, and desktop
environment, in 31kB of html and javascript.)
Richard.
Aug 4 '06 #8
darwinist wrote:
Richard Cornford wrote:
>da*******@gmail .com wrote:
>>Richard Cornford wrote:
da*******@gmail .com wrote:
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly
states that Identifiers beginning with the - $ - symbol
are intended to signify machine generated Identifiers it
is poor javascript design to write code that uses such
identifier s in non-machine generated Identifiers. ...
<snip>
>>I disagree,

The existence of the convention in the language's
specificatio n is fact.

I disagree that it will add to net confusion or obscurity.
Perhaps you should try trimming try quotes you reply to so that the
context of your responses is not ambiguous.

Confusion results form disappointing expectations. It is not
unreasonable for someone to read the convention in the language's
specification and expect others to follow it. When you disregard that
convention for no good reason you are going to cause confusion, and
delays and increased maintenance costs while that confusion is resolved.
>>i find it highly intuitive to group functions which
handle dom-related elements, and it works across browsers.

What 'works' is not really an issue.

Sorry I must have misheard you. Could you say that again?
What 'works' is not really an issue. In allowing the inclusion of the $
symbol in identifiers and then asserting that it should only be used at
the start of a machine generated Identifier the specification had no
choice but allow any Identifier starting with a $ symbol to be legal.
The interpreter cannot know that an Identifier has been machine
generated, and so cannot apply special tokenising/parsing rules for
machine generated Identifiers. Using them where they should not be used
is going to 'work', it is just something that should not be done.
>Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider
readability of your code for programmers who are familiar with the
well known and established conventions.

Not all conventions are of equal value.
No they are not. Conventions are essentially arbitrary, they can all be
disregarded and leave an end result that still 'works'. And there are
numbers of different conventions applying to the same situations and
producing different results. Which conventions get followed is largely a
matter of authority. In a software house there likely are a set of house
conventions for coding in various languages, probably formalised, and
all programming staff are required to conform to those conventions.
However, the set of conventions chosen are not likely to be some
arbitrary notions plucked from the air and imposed as an exercise in
power. They will b chosen because they act to benefit the software
authoring/maintaining process, by making code standard in formal
structure, easily understood and recognisable for what it is. They will
be conventions that the programmers are (more or less) familiar with and
appreciate the motivation for.

The act of specifically stating the convention if the language's
specification pretty much guarantees that any serious javascript
programmer will be familiar with it. From that starting point an formal
coding standards document that overwrites that convention with another
would be ill-conceived.
It depends on how well any convention is suited to the
task that your code is intended to achieve.
Any naming convention could make DOM related method distinct from
others, and may would be less ambiguous themselves, and all others would
avoid facing the reasonable assumption that the convention laid down in
the specification was in use.
>>You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.

Working to programming conventions is such a sensible idea
that software houses tend to formalise a set of conventions
and insist that all their programmers work to those. They
don't do that because following conventions represents a
'vague theory', they do it because it reduces their code
maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions
for most languages coming from various sources, and
conventions that are found in the pertinent language's
specificatio n are likely to be common in use.

There are lots of conventions and they don't always agree.
Of course not. If a formal coding standard say everyone will use one
particular style of block indentation that it immediately precludes all
other styles.
>>I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.

Don't be puritanical.
In any substantial body of code there will be at least one line that is
totally obscure when taken out of context.

But we are not interested in absolute obscurity but rather relative
obscurity. Your:-

$del("something ");

- is inherently obscure, It just needs comparing with alternatives such
as:-

removeDomElemen tById("soemthin g);

In the first case you almost know nothing without the source code for -
$del -, while in the second case the odds are good that the reader does
not have to even go an see what the functions does because its name has
already told them.

<snip>
>>I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get
in the way of the productivity of a third party knowledgeable
javascript programmer attempting to maintain your code as they
will have to spend effort determining that this apparently
machine generated Identifier is not actually machine generated
(and then expend effort re-writing your code to eliminate the
faulty Identifiers).

a) it's a common practice (ask google if you don't believe me)
What is common practice? Using initial $ symbols in javascript code, or
using initial $ symbols to indicate DOM related methods?

First, the vast majority of the javascript code in the world was written
(or copy and pasted) by people who did not really know what they were
doing (and most of the stuff that can be copy and pasted was written by
equally under informed individuals). As a result any appeal to what is
'common practice' is likely an appeal to 'bad practice'.

Initial $ symbols are commonly abused in actual javascript code, but
they certainly are not commonly misused for any single specific purpose.
They can be used to reflect the use of the $ symbol in other languages
(usually with a significant conceptual mismatch), they can be being used
to indicate values of string type, they can be used to indicate values
that should be regarded as internal or private. Indeed you are the first
person I have read proposing that they be used to indicate DOM related
functions. It is in fact this diversity of $ abuses that suggests that
any use outside of the conventions provided in the specification is
unwise, as no other expectation would be common.
b) it makes your code shorter and more readable
Shorter maybe, but shortness at the cost of readability is not a good
trade-off (as shortness can be machine imposed post development). While
readability is precisely what it does not proved. There is no reason for
a reader to see a $ symbol as having anything to do with DOM related
functions, and very good reasons for them to see the $ symbol as having
something to do with machine generation.
c) you can combine it with other useful element functions, like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node
Wrapping common code structures into parameterised functions is not an
idea that requires, or justifies, a specific naming convention.
dom_make, dom_input and dom_text being just as possible, and
fractionally less obscure.
d) this approach allows you write applications more quickly.
It is well known that the maintenance costs are always a significant
factor in applications.
e) you can then optimise for speed in any areas that
are script-heavy.
There is no relationship between an ability to optimise for speed and
the use of any particular naming convention.
f) most programmers would know it to be a waste of time to
rewrite something that works for style alone
Most programmers would know enough not to write something obscurely in
the first place.
g) In this particular case, nobody would be confused for
more than ten seconds, if at all, after which this function
will save them a great many keystrokes, without a noticable
difference in page performance.
If you were not even aware of the IE memory leak problem I don't think
you have ever written anything with javascript that qualifies you to
make such statements about performance.

Of all the things that may be 'saved' in software authoring I don't
think anyone would seriously propose that keystrokes are something that
needs worrying about.

>The overall impact of having to stuff a document with an
excessive number of unique element IDs may be less apparent,
but it will act to hinder development in the longer term.

So will long and complicated statements, which are inevitable
if you stick as close as possible to the native javascript/dom
methods when writing your applicatoin.

Well? Replacing re-occurring blocks of code with parameterised function
call is normal and sensible. I would question the reason for wrapping
code in a function when that function itself only contains one line of
code.
>Generally, javascript is easier to write, maintain and understand
when it uses references to objects directly instead of indirectly
referring to them with string values representing names and IDs.

True, but to get the initial reference you often have to
use id,
No you don't. In an event driven system like a web browser the starting
point of code execution is usually attached to the DOM elements of
interest, or they can be recovered from the event object (with elements
that have structural relationships to those elements being recoverable
by reference through the DOM), and if you create an element you have a
reference to it at that point and do not need to get another so long as
you don't prematurely throw it away.
and if you do this many times in a document, on various
events for example, then you're going to get sick of typing
document.getEle mentById() for such a common task.
I may if I did. A quick text search for '.getElementByI d(' in all the
60,000 lines of javascript code in the web application I am working on
at the moment shows 220 occurrences.
Also you could modify $del() to accept either elements(by
reference) or IDs and act accordingly.
Given how simple the contents of the actual function is, and the fact
that the programmer should know whether they re dealing with an ID sting
or an object reference at the point of calling the function, it would
probably be better to have two function than have each function call
test and branch.

Richard.
Aug 6 '06 #9
Richard Cornford wrote:
darwinist wrote:
Richard Cornford wrote:
da*******@gmail .com wrote:
Richard Cornford wrote:
da*******@gmail .com wrote:
Two-line function library:
<script>
function $(id){return document.getEle mentById(id);}
function $del(id) {$(id).parentNo de.removeChild( $(id));}
</script>
<snip>

As the specification for javascript (ECMA 262) explicitly
states that Identifiers beginning with the - $ - symbol
are intended to signify machine generated Identifiers it
is poor javascript design to write code that uses such
identifiers in non-machine generated Identifiers. ...
<snip>
>I disagree,

The existence of the convention in the language's
specification is fact.
I disagree that it will add to net confusion or obscurity.

Perhaps you should try trimming try quotes you reply to so that the
context of your responses is not ambiguous.
Apologies for not being clear.
Confusion results form disappointing expectations. It is not
unreasonable for someone to read the convention in the language's
specification and expect others to follow it. When you disregard that
convention for no good reason you are going to cause confusion, and
delays and increased maintenance costs while that confusion is resolved.
And I still say this is vague theory when I have presented a practical
example, if an imperfect one, to illustrate just how much "confusion"
would ensue before one sees that $del is delete an element and $make is
make an element and all else in the application is clearer. It's a
style convention, which are project specific, and unenforcable by
interpreters as you say.
>i find it highly intuitive to group functions which
handle dom-related elements, and it works across browsers.

What 'works' is not really an issue.
Sorry I must have misheard you. Could you say that again?

What 'works' is not really an issue. In allowing the inclusion of the $
symbol in identifiers and then asserting that it should only be used at
the start of a machine generated Identifier the specification had no
choice but allow any Identifier starting with a $ symbol to be legal.
The interpreter cannot know that an Identifier has been machine
generated, and so cannot apply special tokenising/parsing rules for
machine generated Identifiers. Using them where they should not be used
is going to 'work', it is just something that should not be done.
If the only practical difference it makes is to how some people
interpret it, then it's a style difference, which has no place in a
language specification. Just cause it's in a spec doesn't mean it
should be followed, when the spec doesn't describe the actual platform
you are writing for.
Making up your own conventions is
your choice, but disregarding well known and established conventions
will make your personal conventions act against the wider
readability of your code for programmers who are familiar with the
well known and established conventions.
Not all conventions are of equal value.

No they are not. Conventions are essentially arbitrary, they can all be
disregarded and leave an end result that still 'works'. And there are
numbers of different conventions applying to the same situations and
producing different results. Which conventions get followed is largely a
matter of authority. In a software house there likely are a set of house
conventions for coding in various languages, probably formalised, and
all programming staff are required to conform to those conventions.
However, the set of conventions chosen are not likely to be some
arbitrary notions plucked from the air and imposed as an exercise in
power. They will b chosen because they act to benefit the software
authoring/maintaining process, by making code standard in formal
structure, easily understood and recognisable for what it is. They will
be conventions that the programmers are (more or less) familiar with and
appreciate the motivation for.

The act of specifically stating the convention if the language's
specification pretty much guarantees that any serious javascript
programmer will be familiar with it. From that starting point an formal
coding standards document that overwrites that convention with another
would be ill-conceived.
Not necessarily, it depends what actual difference it makes.
It depends on how well any convention is suited to the
task that your code is intended to achieve.

Any naming convention could make DOM related method distinct from
others, and may would be less ambiguous themselves, and all others would
avoid facing the reasonable assumption that the convention laid down in
Except manipulating dom objects is so common and important that an
obvious single symbol is very efficient. dom_make takes up more space
on the screen without adding clarity. $make is easier to spot, as well.
>You can talk in vague theory about obscure code and
confused programmers but I'm not convinced.

Working to programming conventions is such a sensible idea
that software houses tend to formalise a set of conventions
and insist that all their programmers work to those. They
don't do that because following conventions represents a
'vague theory', they do it because it reduces their code
maintenance costs by making code quicker to read/understand.
As a result there are sets of well established conventions
for most languages coming from various sources, and
conventions that are found in the pertinent language's
specification are likely to be common in use.
There are lots of conventions and they don't always agree.

Of course not. If a formal coding standard say everyone will use one
particular style of block indentation that it immediately precludes all
other styles.
>I challenge you to find an obscure
line in this entire windowing system:
http://darwinist.googlepages.com/htmldesktop.html

Don't be silly.
Don't be puritanical.

In any substantial body of code there will be at least one line that is
totally obscure when taken out of context.

But we are not interested in absolute obscurity but rather relative
obscurity. Your:-

$del("something ");

- is inherently obscure, It just needs comparing with alternatives such
as:-

removeDomElemen tById("soemthin g);

In the first case you almost know nothing without the source code for -
$del -, while in the second case the odds are good that the reader does
not have to even go an see what the functions does because its name has
already told them.
Besides the fact that the this approach makes the programs much
shorter, allowing context to be seen more quickly, anyone browsing the
code ought to have sufficient commentary as to why something is being
deleted, and what it is. An application must be allowed its own
linguistic context in which things like "del" have a known meaning. In
a file-system-based command line it would be assumed it was a file, in
any web-application that's gui heavy, it might mean a gui element. The
$ just makes it even more clear in the context of that particular
project.
<snip>
>I'm not particularly interested in coding to the bugs of a
product whose manufacturers don't even pretend it's good
anymore.

$del("id"); is quick and easy and allows you to be more
productive.

What it does for you is not relevant. It will potentially get
in the way of the productivity of a third party knowledgeable
javascript programmer attempting to maintain your code as they
will have to spend effort determining that this apparently
machine generated Identifier is not actually machine generated
(and then expend effort re-writing your code to eliminate the
faulty Identifiers).
a) it's a common practice (ask google if you don't believe me)

What is common practice? Using initial $ symbols in javascript code, or
using initial $ symbols to indicate DOM related methods?
The latter, to return elements by id or reference. I don't know if many
people use $make and $del and $input and $text, but I liked the idea
and the syntax so much (being a php programmer, which I think a lot of
js programmers are these days), that I extended the idea for my
windowing system.
First, the vast majority of the javascript code in the world was written
(or copy and pasted) by people who did not really know what they were
doing (and most of the stuff that can be copy and pasted was written by
equally under informed individuals). As a result any appeal to what is
'common practice' is likely an appeal to 'bad practice'.
Your primary argument against using the $ to denote dom elements is one
of convention, to avoid confusing people who are experienced
javascript programmers. What if they're experienced in these bad
practices?
Initial $ symbols are commonly abused in actual javascript code, but
they certainly are not commonly misused for any single specific purpose.
They can be used to reflect the use of the $ symbol in other languages
(usually with a significant conceptual mismatch), they can be being used
to indicate values of string type, they can be used to indicate values
that should be regarded as internal or private. Indeed you are the first
person I have read proposing that they be used to indicate DOM related
functions. It is in fact this diversity of $ abuses that suggests that
any use outside of the conventions provided in the specification is
unwise, as no other expectation would be common.
b) it makes your code shorter and more readable

Shorter maybe, but shortness at the cost of readability is not a good
trade-off (as shortness can be machine imposed post development). While
readability is precisely what it does not proved. There is no reason for
a reader to see a $ symbol as having anything to do with DOM related
functions, and very good reasons for them to see the $ symbol as having
something to do with machine generation.
If you're open to the idea of project-specific style-conventions, then
as I've said it's a matter of a few seconds to see the consistent
convention in any application that uses the dollar sign this way. I
propose it because so many web applications are getting so gui heavy,
and it's the shortest, clearest means of distinction that I can see.
c) you can combine it with other useful element functions, like
$make(tagname, id); // make an element
$input(type, name, value, [id]) // make an input
$text(text) // make a text node

Wrapping common code structures into parameterised functions is not an
idea that requires, or justifies, a specific naming convention.
dom_make, dom_input and dom_text being just as possible, and
fractionally less obscure.
You can spot a dollar sign more easily in a sea of roman characters.
d) this approach allows you write applications more quickly.

It is well known that the maintenance costs are always a significant
factor in applications.
Yes, which is why brevity and readability are so important.
e) you can then optimise for speed in any areas that
are script-heavy.

There is no relationship between an ability to optimise for speed and
the use of any particular naming convention.
If you can express the initial prototype more quickly and clearly then
yes, there is.
f) most programmers would know it to be a waste of time to
rewrite something that works for style alone

Most programmers would know enough not to write something obscurely in
the first place.
Your equation of clarity with an absolute naming convention, is close
minded. There is much more to clarity.
g) In this particular case, nobody would be confused for
more than ten seconds, if at all, after which this function
will save them a great many keystrokes, without a noticable
difference in page performance.

If you were not even aware of the IE memory leak problem I don't think
you have ever written anything with javascript that qualifies you to
make such statements about performance.
Lucky for me I don't care what you think I'm qualified to do.
Of all the things that may be 'saved' in software authoring I don't
think anyone would seriously propose that keystrokes are something that
needs worrying about.
Brevity of code is not just keystrokes. You can look at more code at
once and still see more comments and whitespace. The code is closer to
english and no matter how well you get to know any computer language,
english will be clearer, especially when you've been away from the
project for a while or someone else takes over some of it.
The overall impact of having to stuff a document with an
excessive number of unique element IDs may be less apparent,
but it will act to hinder development in the longer term.
So will long and complicated statements, which are inevitable
if you stick as close as possible to the native javascript/dom
methods when writing your applicatoin.


Well? Replacing re-occurring blocks of code with parameterised function
call is normal and sensible. I would question the reason for wrapping
code in a function when that function itself only contains one line of
code.
To save 10 - 20 bytes per call.
Generally, javascript is easier to write, maintain and understand
when it uses references to objects directly instead of indirectly
referring to them with string values representing names and IDs.
True, but to get the initial reference you often have to
use id,

No you don't. In an event driven system like a web browser the starting
point of code execution is usually attached to the DOM elements of
interest, or they can be recovered from the event object (with elements
that have structural relationships to those elements being recoverable
by reference through the DOM), and if you create an element you have a
reference to it at that point and do not need to get another so long as
you don't prematurely throw it away.
Interesting, I'll try to be more efficient with my references.
and if you do this many times in a document, on various
events for example, then you're going to get sick of typing
document.getEle mentById() for such a common task.

I may if I did. A quick text search for '.getElementByI d(' in all the
60,000 lines of javascript code in the web application I am working on
at the moment shows 220 occurrences.
Also you could modify $del() to accept either elements(by
reference) or IDs and act accordingly.

Given how simple the contents of the actual function is, and the fact
that the programmer should know whether they re dealing with an ID sting
or an object reference at the point of calling the function, it would
probably be better to have two function than have each function call
test and branch.
Good idea.
Richard.
Aug 7 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

52
26975
by: Newsnet Customer | last post by:
Hi, Statement 1: "A dynamically created local object will call it's destructor method when it goes out of scope when a procedure returms" Agree. Statement 2: "A dynamically created object will call it's destructor when it is made a target of a delete".
1
3833
by: Nimmi Srivastav | last post by:
There's a rather nondescript book called "Using Borland C++" by Lee and Mark Atkinson (Que Corporation) which presents an excellent discussion of overloaded new and delete operators. In fact there are quite a few things that I learned that I did not know before. For example, while I knew that the new and delete operators can be overloaded...
11
912
by: Jonan | last post by:
Hello, For several reasons I want to replace the built-in memory management with some custom built. The mem management itlsef is not subject to my question - it's ok to the point that I have nice and working allocation deallocation routines. However, I don't want to loose the nice extras of new operator, like - constructor calling,...
1
3879
by: Douglas Peterson | last post by:
class Allocator { public: virtual void * Alloc(size_t) = 0; virtual void * Free(void*) = 0; }; class Object { public:
11
23038
by: Squid Seven | last post by:
I create a pointer to an item: CardSession *cardSession; Then, later, I use new to create an instance of the item and assign it to that pointer: cardSession = new CardSession(); In another function, I want to test if an object is assigned to that
5
6683
by: Jeff User | last post by:
Hello ..NET 1.1, VS 2003, C# & asp.net I have tried to follow msdn instructions and samples but I can not get an event to fire for this button on the datagrid. There has to be something obvious missing here, but after 2 days I am ready to explode ! Please help. To create the Delete button I selected the grid in design view, clicked the...
5
1874
by: tom | last post by:
Hi, I'm overriding my operator new and operator delete for two classes, one inherited from the other, so I can use my own memory pool. A simplified version of what I have is below: class BaseClass { BaseClass(); virtual ~BaseClass(); virtual void baseFunction();
6
3843
by: polocar | last post by:
Hi, I'm writing a program in Visual C# 2005 Professional Edition. This program connects to a SQL Server 2005 database called "Generations" (in which there is only one table, called "Generations"), and it allows the user to add, edit and delete the various records of the table. "Generations" table has the following fields: "IDPerson",...
9
2905
by: Money | last post by:
If I allocate memory like this int *ptr = new int; Can I apply delete ptr; instead of delete ptr; since I am only allocating memory for 1 integer.
15
4996
by: LuB | last post by:
I am constantly creating and destroying a singular object used within a class I wrote. To save a bit of time, I am considering using 'placement new'. I guess we could also debate this decision - but for the sake of this post ... I'm searching for an answer that assumes said decision. If I allocate memory in the class declaration: char...
0
7644
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7568
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
7858
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8085
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7614
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
6206
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
0
5185
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
1
2066
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
892
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.