RegExp to alter an element name?

V

VK

Hello!

Given a string like
<input type="button" name="b1" value="Button">

I want to locate the element's name (b1) and replace it with this very name
+ some spice.

And of course it can be any kind of loose HTML syntacs:
name="b1"
NAME="b1"
name='b1'
NAME=b1
....

So it's something like (totally wrong expression, I know):
/name=(s+|'|")(name)/$1+my_spice/i

But I did not work with regexp for a longest time, and I'm just too lazy
(sorry to admit) to read manuals over again just for one case.
Any Samaritan soul around here?
 
M

Michael Winter

Given a string like <input type="button" name="b1" value="Button">

I want to locate the element's name (b1) and replace it with this very
name + some spice.

And of course it can be any kind of loose HTML syntacs:
name="b1"
NAME="b1"
name='b1'
NAME=b1
...

Try:

str = str.replace(
/(name=)([\"\']?)([\w.:-]+|[^\"]+|[^\']+)\2/i,
'$1$2$3' + stuff + '$2'
);

where 'str' is your string, and 'stuff' is your spice [sic]. I've given it
a quick test, and it appears to handle everything you want it to. There
might be a simpler option, though.

By the way, it will accept value with and without both kinds of quotes,
but if quotes are omitted, the value must conform to the Specification.
That is, only letters, numbers, underscores (_), periods (.), colons :)),
and hyphens (-) will be accepted.

[snip]

Good luck,
Mike
 
M

Michael Winter

On Sat, 27 Nov 2004 15:56:24 GMT, Michael Winter

[snip]
str = str.replace(
/(name=)([\"\']?)([\w.:-]+|[^\"]+|[^\']+)\2/i,
'$1$2$3' + stuff + '$2'
);

I just realised that I've reintroduced a problem I initially removed. With
the regular expression above, the second saved match contains either a
quote character, or nothing if the attribute value wasn't quoted in the
first place. When the replacement string is constructed, the result of
this match - a quote or nothing - will be used again, which means that as
it stands, the 'stuff' string would have to conform to the same
restrictions as unquoted values:

[snip]
That is, only letters, numbers, underscores (_), periods (.), colons
:)), and hyphens (-) will be accepted.

Presumably, you're taking a string obtained from innerHTML, modifying it,
and placing it back into the document. That would account for the leniency
you wanted as different browsers normalise the innerHTML string in
different ways.

If the restriction I unintentionally imposed is unacceptable, one way
around it is to use a function, rather than a string, with
String.prototype.replace:

var stuff = '...';
function addStuff() {
var s = arguments[2] || '"';
return arguments[1] + s + arguments[3] + stuff + s;
}

str = str.replace(
/(name=)([\"\']?)([\w.:-]+|[^\"]+|[^\']+)\2/i,
addStuff
);

The only problem here is that IE only supports a function argument with
JScript 5.5+ (IE 5.5+/WinME/WinXP). Though a toString method could be
defined which performs the original operation:

addStuff.toString = function() {
return '$1$2$3' + stuff + '$2';
};

IE normalises its innerHTML strings so that unnecessary quotes are removed
- back to square one.

If you do reach this point, you'll have to abandon my suggestion. The last
recourse would be the String.prototype.split method, however IE's
implementation is broken[1] when used with regular expressions.

Mike


[1] Well, it doesn't conform to ECMA-262, 3rd Ed.
 
V

VK

It may help I guess if I explain what am I doing.

I'm finishing my European vacations next week (irrelevant to JavaScript,
just to start the speech :)
I want to make a .js library to handle tables dynamically (add/remove/clone
rows, attach the behaviors to cells etc.)

The OP's RegExp was a part of my method to clone rows in IE tables (under
TOM).
As IE doesn't allow to operate on the ROW level (you have to go cell by
cell), for rows cloning within the same table, I did:

for (i=0;oldRow.cells.length;i++) {
var oCell = newRow.insertCell();
oCell.innerHTML = oldRow.cells.innerHTML;
}

The problem pops up if we have an enclosing form with form elements inside
the cloning cells. Obviously the cloned row will contain the cloned form
elements as well with the same names.
I thought the simplest fix would be to use a RegExp to alter the source
element name before pass it to the target?
 
M

Michael Winter

[snip]
As IE doesn't allow to operate on the ROW level (you have to go cell by
cell), for rows cloning within the same table, I did:

[snip]

An alternative approach could be to clone the row with the Node.cloneNode
method. Something like:

var newRow = rowParent.cloneNode(true),
newInputs = newRow.getElementsByTagName('INPUT');
for(var i = 0, n = newInputs.length; i < n; ++i) {
newInputs.name = /* ... */;
}
rowParent.appendChild(newRow);

Mike
 
R

RobB

Michael Winter said:
[snip]
As IE doesn't allow to operate on the ROW level (you have to go cell by
cell), for rows cloning within the same table, I did:

[snip]

An alternative approach could be to clone the row with the Node.cloneNode
method. Something like:

var newRow = rowParent.cloneNode(true),
newInputs = newRow.getElementsByTagName('INPUT');
for(var i = 0, n = newInputs.length; i < n; ++i) {
newInputs.name = /* ... */;
}
rowParent.appendChild(newRow);

Mike
RobB wrote:
<snip>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
<head> <snip>
var alldivs = document.getElementsByTagName('DIV'); <snip>

XHTML DOMs are case sensitive (like XHTML mark-up) and because the tag
and attribute names are all lowercase in the mark-up they are expected
to also be all lowercase when being referred to with scripts.

Additionally, the namespace qualified ('NS' prefixed) methods (when
available) produce more reliable results in XHTML DOMs.

I noticed MW used:
newInputs = newRow.getElementsByTagName('INPUT');

....and would appreciate their insight into this issue. I've always -
until recently - used lower-case tagnames, making comparisons with
DOM-returned strings using case-insensitive regexes to avoid browser
differences. However I've noticed numerous experienced programmers
utilizing upper-case tagnames as parameters to DOM methods. Why?
 
R

Richard Cornford

On another thread, R Cornford wrote:


I noticed MW used:


...and would appreciate their insight into this issue.
I've always - until recently - used lower-case tagnames,
making comparisons with DOM-returned strings using
case-insensitive regexes to avoid browser differences.
However I've noticed numerous experienced programmers
utilizing upper-case tagnames as parameters to DOM methods.
Why?

The difference between an HTML DOM, which is case insensitive
(theoretically) and in which tagName properties are upper-case, and an
XHTML DOM, which is case sensitive and has lower case tag names (that
may additionally be namespace qualified).

When Mike posts mark-up it is HTML (usually HTML 4.01 strict), so it is
an HTML DOM that he is expecting to be scripting. When you post mark-up
it is invariably XHTML, and so logic would suggest that it is the XHTML
DOM that you intend to be scripting.

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,682
Members
48,796
Latest member
Greg L.

Latest Threads

Top