removal of id stText in ZC155 causes various javascript failures

[torvista]

...as I was saying:

theForm.state.className = 'hiddenField'; - this sets the class of the input field state to "hiddenField" and so it gets hidden due a css selector. Ok.
theForm.state.setAttribute('className', 'hiddenField'); - this creates a new attribute: className ="hiddenField". Why?

The only thing I can find about this attribute is something to do with React.

Similarly for the label:
document.getElementById("stateLabel").className = 'hiddenField';
document.getElementById("stateLabel").setAttribute('className', 'hiddenField');

[mc12345678]

...as I was saying:

theForm.state.className = 'hiddenField'; - this sets the class of the input field state to "hiddenField" and so it gets hidden due a css selector. Ok.
theForm.state.setAttribute('className', 'hiddenField'); - this creates a new attribute: className ="hiddenField". Why?

The only thing I can find about this attribute is something to do with React.

Similarly for the label:
document.getElementById("stateLabel").className = 'hiddenField';
document.getElementById("stateLabel").setAttribute('className', 'hiddenField');

While I haven't dug into which properties directly affect the associated attribute(s), I came across an example where the property (addressed by the first line of code) is modified, but the attribute was not modified (ie. A getAttribute call was made and it was unchanged.) which would be addressed by the second line of code where the attribute gets set.

That said, though it appears that the intention is to properly address the appropriate pieces of the object. Thing is that the attribute className doesn't exist initially. The attribute class does and is set to whatever the element had originally. The property className does exist and is updated if either the attribute class is updated or the property of className is updated. The attribute class also is similarly updated if either the attribute of class or the property of className are updated.

So what appears to happen is that some additional javascript variables are made available by the code discussed above. That being the attribute className such if someone chose to use that attribute instead of the appropriate class attribute that they would be able to obtain the data...

Otherwise, I can *not* speak to the disconnect of the proposed pull request and what has been seen in more recent code.

[swguy]

Note related issue in Github: #2235.
https://github.com/zencart/zencart/issues/2235

[torvista]

@mc
As always, thanks for taking the time to make a detailed response, and as usual, I've lost it by the second sentence.

I don't think I'm any closer to knowing the answer to "className= whatever"..why is that there?

[haredo]

@torivista
You make me SMILE !!!

[mc12345678]

@mc
As always, thanks for taking the time to make a detailed response, and as usual, I've lost it by the second sentence.

I don't think I'm any closer to knowing the answer to "className= whatever"..why is that there?

Are you asking generally for why className is used at all and set to "hidden", the className property is used or the that the setAttribute of className is used?

[torvista]

Exactly:

why className is used at all

.

[dw08gm]

@torivista
You make me SMILE !!!

Me too. I am sure its largely a punctuation issue.

FWIW IIRC I got rid of (really just remmed) the stText code way back in the early ZC150s and never looked back.

[mc12345678]

Exactly: .

When presenting the "login" page (whatever page uses this javascript), there are two ways to present the "state":
1) User entered
2) Select from a list, but if the list is not populated then enter information.

The default installation offers a text fillable field where the customer can put whatever they want into it (or nothing. The allowance of nothing is set by the minimum settings in admin). However, there is also the opportunity to standardize the content by use of dropdowns.

There are a couple of issues though with the dropdowns. Generally speaking, they need to be flushed out to offer all options that could possibly be considered or when no sub-options are provided then the customer needs to be able to enter the associated state information (again following the minimum requirements). On the full population side, a store could limit the locations for which accounts can be created, to which shipped, or from which payment can be accepted. There are of course ways to allow further customer expansion of that list, but that's a separate topic.

So, when dropdowns are used/forced, there is some level of display control expected. When the selection list doesn't have data, then allow the state field to be displayed, when the main option has data, then hide the text field from the user. Further, if something is manually entered, then the selection changes away from showing the field, but then is returned, it is generally desirable to retain the originally entered information. To do this, the field needs to just be hidden and/or displayed.

So, that change of display is performed through the class designation/assignment. When using the property:
document.getElementById("stateLabel").className = 'hiddenField';

that class is properly referenced by the javascript designation of "className". Attempting to use .class = 'hiddenField'; does not modify the class designation. Note that the above assignment will also affect the attribute 'class' such that using .getAttribute('class') after the above, will result in the value 'hiddenField'. (Read a little more below about set/getAttribute)

In parallel with this, a setAttribute is performed. When using getAttribute, the expectation is that the attribute is a part of the html/page information. In this case it would be expected to be some "text" in the html object 'stateLabel'. You'll note that there is no className="..." when viewing the page source. Now, I believe at a time in the distant past I had a public conversation with DrByte about the use of the setAttribute('className'... aspect. The proper way to obtain the class of the object is to use getAttribute('class'); however, it seems that there was some early consideration where home developers would see the property designation (className) and try to use that in their javascript code; however, getAttribute('className') doesn't exist in base javascript. To get around that issue (having to provide support for each such (mis)usage), the attribute 'className' is set to the same value that the property sets. Therefore one can issue either of the following javascript requests after the attribute 'className' has been set:
var labelClass = document.getElementById("stateLabel").getAttribute('className');
var labelClass2 = document.getElementById("stateLabel").getAttribute('class');

and both will have the same value.

Now, one could possibly argue that this mess of javascript is "unnecessary" for a screen where the dropdown is not used; however, by it being provided out-of-the-box, further usage/development is made easier than trying to locate/force the associated javascript control to be displayed in alternate configurations. Ideally, as has been pushed for edit, this javascript would not interfere with other operations. The input of users/builders/developers like yourself is what identifies that type of issue and gets changes made.

So, now does this clarify at all why a class of hiddenField is assigned?

[torvista]

Sorry for the late response, I had to lie down for a week after the first reading.

I understand that to add/replace a class to an element, you use the command className
document.getElementById("stateLabel").className = 'hiddenField';

and conversely, to get the property/name of the class, you also use the command className
var y = document.getElementById("stateLabel").className;
or
var y = document.getElementById("stateLabel").getAttribute('class')


End of story for me.

You'll note that there is no className="..." when viewing the page source.

I can see classname.

From what I can extract from your massive missive, adding className as a new attribute was related to supporting people making mistakes?

In summary, I still don't see that this attribute does anything, nor is used...so it does not need to be there.