Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #17409

Re: Problem w/ creating dynamic TR and its TDs

Followups directed to: comp.lang.javascript

Show key headers only | View raw

Cezary Tomczyk wrote:

> W dniu 2012-12-02 03:46, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> You can use something like this as a workaround for old IE and problems
>>> with "input type name":
>> There is no such problem.  You are confusing this with changing the value
>> of the `type' property of an `input' element object after the
>> corresponding element has been appended.
> 
> I am refereeing to old IE bug described on
> http://webbugtrack.blogspot.cz/2007/10/bug-235-createelement-is-broken-
> in-ie.html.
> Of course, problem with setting dynamically attribute "name" is only in
> IE 7 and lower.

I have not tested in IE 7.  However, I have created a testcase and tested in 
IE 6.0.2800.1106 on Wine XP SP1 (IEs4Linux):

<http://PointedEars.de/scripts/test/dom/input-submit>

The results of my tests are:

- Without further measures the appended control is not accessible by name
  via the `elements' collection.  (Insofar the entry is correct.)

- Without further measures the appended control *is* submitted.  (The entry
  is incorrect from there.)

In conclusion, it is probably _not_ the implementation of createElement() in 
MSHTML that is broken there, but that of appendChild() and similar methods.  
It is therefore incorrect that to work around this it would be absolutely 
necessary to resort to what is suggested there.  [And JFYI, what you have 
posted here has *nothing* to do with what is suggested there.]

As we have found out here (or was it in de.comp.lang.javascript?) years ago, 
a workaround is to add the control to the `elements' collection if it is not 
yet part of it:

  var input = document.createElement("input");
  var name = "foo";
  input.name = name;
  input.value = "bar";
  form.appendChild(input);

  /* workaround for IE < 8 */
  if (typeof form.elements[name] == "undefined")
  {
    form.elements[name] = input;
  }

As you can see, a disadvantage of that approach is that you lose the 
collection functionality if there is already a control with the same name.  
If that is a problem, I think you will have to combine it with other 
approaches or refer to the new control by other means than the `elements' 
collection.  (But someone – Richard Cornford? – might have already provided 
a solution to that problem as well.)

The same problem and workaround exists with other collections.  IIRC they 
exist with iframes and window.frames[…] as well.
 
>>>       for(var p in attributes){
>>
>> Iterates over enumerable properties of `attributes'.  Better:
>>
>>    for (var keys = Object.keys(attributes), i = 0, len = keys.length;
>>         i < len;
>>         ++i)
>>
>> or pre-ES 5.1 variants thereof.  See also jsx.object.getKeys().
> 
> I tried to use Object.keys many times, but seems that it is very slow.

At least it is reliable and can be rather easily emulated (for enumerable 
properties) down to ES 3.

> See test: http://jsperf.com/loop-for-in-vs-object-keys-foreach/2
> 
> And yes, I remember your opinion about those tests :-)

Good.  You should also know that you are comparing apples and oranges here. 

A for-in statement is _not_ equivalent to either foreach (or the E4X `for 
each') or Object.keys().  By contrast, it iterates over own and *inherited* 
*enumerable* properties in *implementation-dependent* (in ES3, arbitrary) 
order; the iterator is the property name, not the property value.

Object.keys() returns a reference to an Array of the names of all *own* 
enumerable properties (in the same implementation-dependent order as for 
for-in), and *only* those.  [Which is why if you want to emulate 
Object.keys() for enumerable properties, you have to use 
Object.prototype.hasOwnProperty() or emulations thereof.]

>>>         element[p]= attributes[p];
>>
>> Fails to account for the mapping of attribute names that are reserved
>> words to special attribute properties (like "for" → "htmlFor"), and of
>> the `style' attribute.  See also jsx.dom.setAttr().
> 
> Right. Actually I use mapping for attributes:
> 
>          'for' : 'htmlFor',
>          accesskey : 'accessKey',
>          codebase : 'codeBase',
>          frameborder : 'frameBorder',
>          framespacing : 'frameSpacing',
>          nowrap : 'noWrap',
>          maxlength : 'maxLength',
>          'class' : 'className',
>          readonly : 'readOnly',
>          longdesc : 'longDesc',
>          tabindex : 'tabIndex',
>          rowspan : 'rowSpan',
>          colspan : 'colSpan',
>          ismap : 'isMap',
>          usemap : 'useMap',
>          cellpadding : 'cellPadding',
>          cellspacing : 'cellSpacing',
>          contenteditable : 'contentEditable'

Looks good to me.  I will augment the mapping in dom.js with some of those.

>>>       }
>>>
>>>       div.appendChild(element);
>>>       return div.firstChild;
>>
>> I beg your pardon?  What exactly are you creating the `div' element for
>> if you are not returning a reference to it?  Mystical incantation?
> 
> I can not be sure now (it was long time ago), but as I remember I did
> this because <input> element had to be append somewhere to create
> properly <input> element with "name" attribute.

You misremember.

> However, today is not necessary.

It never was.

>>> };
>>>
>>> This is just an example and probably code could be more improved.
>>
>> It is a solution looking for a problem while creating more problems than
>> it fails to solve.   The correct way to address the problem actually
>> posed by the question (as opposed to your answer) is:
>>
>>    var input = document.createElement("input");
>>    input.name = "partnumber" + cnt;
>>    input.id = "partnumber" + cnt;
>>    input.className = "autocomplete";
>>    cell.appendChild(input);
> 
> Well, today I bet that most browsers working with that well. I just
> referred to problems with IE7 and lower during creating dynamically
> <input> element.

See above and below.

Please trim your quotes.


PointedEars, with a random but fitting signature
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Problem w/ creating dynamic TR and its TDs justaguy <lichunshen84@gmail.com> - 2012-12-01 15:17 -0800
  Re: Problem w/ creating dynamic TR and its TDs Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-12-02 00:34 +0100
    Re: Problem w/ creating dynamic TR and its TDs justaguy <lichunshen84@gmail.com> - 2012-12-01 17:06 -0800
    Re: Problem w/ creating dynamic TR and its TDs Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 03:46 +0100
      Re: Problem w/ creating dynamic TR and its TDs justaguy <lichunshen84@gmail.com> - 2012-12-01 19:27 -0800
        Re: Problem w/ creating dynamic TR and its TDs Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-03 22:53 +0100
      Re: Problem w/ creating dynamic TR and its TDs Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-12-02 08:43 +0100
        Re: Problem w/ creating dynamic TR and its TDs Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 16:11 +0100
          Re: Problem w/ creating dynamic TR and its TDs Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-12-02 18:48 +0100
            Re: Problem w/ creating dynamic TR and its TDs Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 19:35 +0100
              Re: Problem w/ creating dynamic TR and its TDs Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 19:39 +0100

csiph-web