DOM to HTML

[MC]

Hi,

I have a need to get the HTML code (and its state). I was thinking of doing
a

var e = document.getElementById("formName");

This will get a dom but not the html.
1. Is there an easy way to convert it to html?
2. Is there a better way to get the html with state?

MC

 

[David Mark]

Hi,

I have a need to get the HTML code (and its state). I was thinking of doing
a

var e = document.getElementById("formName");

It's more compatible to use document.forms.formName or
document.forms['formName'].

This will get a dom but not the html.
Right.

1. Is there an easy way to convert it to html?

Well, you could get a reference to its parent and then get the
innerHTML property (in browsers that support it). Results vary cross-
browser though.

2. Is there a better way to get the html with state?

Depends on what you mean by state (i.e. does that include user
input?). You can certainly traverse the DOM and build the string
yourself, but it is a non-trivial task due primarily to botched
attribute handling in MSHTML (IE).

There is an example of this on the My Library test page.

 

[MC]

David Mark, my favorite javascript guy!

Yes, I am trying to get the user input from checkbox, radio, input, and
select. It seems the input is retrieved via innerHTML but the other is not.

Mica

Hi,

I have a need to get the HTML code (and its state). I was thinking of
doing
a

var e = document.getElementById("formName");

It's more compatible to use document.forms.formName or
document.forms['formName'].

This will get a dom but not the html.
Right.

1. Is there an easy way to convert it to html?

Well, you could get a reference to its parent and then get the
innerHTML property (in browsers that support it). Results vary cross-
browser though.

2. Is there a better way to get the html with state?

Depends on what you mean by state (i.e. does that include user
input?). You can certainly traverse the DOM and build the string
yourself, but it is a non-trivial task due primarily to botched
attribute handling in MSHTML (IE).

There is an example of this on the My Library test page.

 

[MC]

Correction:
The user input from an input is in innerHTML but radio, checkbox, and select
user input is not.

 

[David Mark]

David Mark, my favorite javascript guy!
Hey!


Yes, I am trying to get the user input from checkbox, radio, input, and
select.

There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).

It seems the input is retrieved via innerHTML but the other is not.

The results of that proprietary property are implementation
dependant. You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the form
controls. It sounds as if the browsers you tested were referencing
the defaultChecked and defaultSelected properties for radio/checkbox
inputs and select options, but not the defaultValue property for text
inputs. That's certainly an incongruous approach.

Also, if you must deal with multi-selects, there is no single property
to reference (you have to loop through the options and check the
selected property for each).

And I've got to ask, what is the purpose of this? Seems like a can of
worms that doesn't need to be opened.

Please don't top-post. It screws up the context of the dicussion (and
I don't care to restore it).

 

[MC]

There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).


The results of that proprietary property are implementation
dependant. You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the form
controls. It sounds as if the browsers you tested were referencing
the defaultChecked and defaultSelected properties for radio/checkbox
inputs and select options, but not the defaultValue property for text
inputs. That's certainly an incongruous approach.

Also, if you must deal with multi-selects, there is no single property
to reference (you have to loop through the options and check the
selected property for each).

And I've got to ask, what is the purpose of this? Seems like a can of
worms that doesn't need to be opened.

Please don't top-post. It screws up the context of the dicussion (and
I don't care to restore it).

Purpose: Document a page into an archive (with user input) via ajax. These
pages are basically user forms that are then sent to a document archive
service. Without the user input, archival is useless.

 

[David Mark]

Purpose: Document a page into an archive (with user input) via ajax. These
pages are basically user forms that are then sent to a document archive
service. Without the user input, archival is useless.

Deja vu. Haven't we had this discussion before?

Personally, I would serialize the data without the markup.

 

[MC]

Deja vu. Haven't we had this discussion before?

Personally, I would serialize the data without the markup.

We have and I didn't find an answer. Prior to this, the archival software
was not finished. The archival software is now complete and working like a
champ turning html into beautiful pdf exactly like the html form. So now the
project is going live and I need to resolve this last issue.

 

[David Mark]

We have and I didn't find an answer. Prior to this, the archival software
was not finished. The archival software is now complete and working like a
champ turning html into beautiful pdf exactly like the html form. So now the
project is going live and I need to resolve this last issue.

You will have to traverse the form and build the HTML string yourself
as innerHTML is not an appropriate format to store (varies from one
browser to the next). Have you tried to do that? If you only need
form controls, it is fairly trivial. First define what sort of form
controls will be involved (e.g. what about textareas?)

Start with something like this:-

function serializeFormHtml(name) {
var el = document.forms[name];
var control, controls = el.elements;
var result = [];

for (var i = controls.length; i-- {
control = controls;
switch (control.tagName.toLowerCase()) {
case 'input':
...
break;
case 'select':
...
break;
case 'textarea':
...
break;
}
}

return result.join('');
}

You will have to fill in the blanks as only you know the context of
your application. For example, other than name and value; what, if
any, attributes should be included? Will there be multi-selects, do
you care about disabled controls, etc.?

 

[MC]

We have and I didn't find an answer. Prior to this, the archival software
was not finished. The archival software is now complete and working like
a
champ turning html into beautiful pdf exactly like the html form. So now
the
project is going live and I need to resolve this last issue.

You will have to traverse the form and build the HTML string yourself
as innerHTML is not an appropriate format to store (varies from one
browser to the next). Have you tried to do that? If you only need
form controls, it is fairly trivial. First define what sort of form
controls will be involved (e.g. what about textareas?)

Start with something like this:-

function serializeFormHtml(name) {
var el = document.forms[name];
var control, controls = el.elements;
var result = [];

for (var i = controls.length; i-- {
control = controls;
switch (control.tagName.toLowerCase()) {
case 'input':
...
break;
case 'select':
...
break;
case 'textarea':
...
break;
}
}

return result.join('');
}

You will have to fill in the blanks as only you know the context of
your application. For example, other than name and value; what, if
any, attributes should be included? Will there be multi-selects, do
you care about disabled controls, etc.?

All of those controls will be dealt with. We are not storing html but
converting html into a pdf representation and it is pretty exact. Its
actually really cool, as users go about their day, their work is
automatically e-archived via ajax, saving them a huge amount of time/money
printing and filing.

What about this? It seems to work.

while (e = oForm.elements[i++]) {
if (e.type == 'checkbox') {
if (e.checked == true) {
e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
if (e.type == 'radio') {
var x = e.name;
if (e.checked == true) {
e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
}

 

[RobG]

There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).

The results of that proprietary property are implementation
dependant.  You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the form
controls.  It sounds as if the browsers you tested were referencing
the defaultChecked and defaultSelected properties for radio/checkbox
inputs and select options, but not the defaultValue property for text
inputs.  That's certainly an incongruous approach.

Also, if you must deal with multi-selects, there is no single property
to reference (you have to loop through the options and check the
selected property for each).

And I've got to ask, what is the purpose of this?  Seems like a can of
worms that doesn't need to be opened.

[...]
Purpose: Document a page into an archive (with user input) via ajax. These
pages are basically user forms that are then sent to a document archive
service. Without the user input, archival is useless.

The results of setting the innerHTML property seems reasonably
consistent across browsers, however getting it is inconsistent.

Why not just submit the form and have the server update the original
HTML with the returned values. Saves a whole load of client-side grief
and much easier to implement.

 

[David Mark]

David Mark, my favorite javascript guy!
Hey!
Yes, I am trying to get the user input from checkbox, radio, input,
and
select.
There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).
It seems the input is retrieved via innerHTML but the other is not.
The results of that proprietary property are implementation
dependant. You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the
form
controls. It sounds as if the browsers you tested were referencing
the defaultChecked and defaultSelected properties for radio/checkbox
inputs and select options, but not the defaultValue property for
text
inputs. That's certainly an incongruous approach.
Also, if you must deal with multi-selects, there is no single
property
to reference (you have to loop through the options and check the
selected property for each).
And I've got to ask, what is the purpose of this? Seems like a can
of
worms that doesn't need to be opened.
Please don't top-post. It screws up the context of the dicussion
(and
I don't care to restore it).
Purpose: Document a page into an archive (with user input) via ajax.
These
pages are basically user forms that are then sent to a document
archive
service. Without the user input, archival is useless.
Deja vu. Haven't we had this discussion before?
Personally, I would serialize the data without the markup.
We have and I didn't find an answer. Prior to this, the archival software
was not finished. The archival software is now complete and working like
a
champ turning html into beautiful pdf exactly like the html form. So now
the
project is going live and I need to resolve this last issue.

You will have to traverse the form and build the HTML string yourself
as innerHTML is not an appropriate format to store (varies from one
browser to the next). Have you tried to do that? If you only need
form controls, it is fairly trivial. First define what sort of form
controls will be involved (e.g. what about textareas?)

Start with something like this:-

function serializeFormHtml(name) {
var el = document.forms[name];
var control, controls = el.elements;
var result = [];

for (var i = controls.length; i-- {
control = controls;
switch (control.tagName.toLowerCase()) {
case 'input':
...
break;
case 'select':
...
break;
case 'textarea':
...
break;
}
}

return result.join('');
}

You will have to fill in the blanks as only you know the context of
your application. For example, other than name and value; what, if
any, attributes should be included? Will there be multi-selects, do
you care about disabled controls, etc.?

All of those controls will be dealt with. We are not storing html but
converting html into a pdf representation and it is pretty exact. Its
actually really cool, as users go about their day, their work is
automatically e-archived via ajax, saving them a huge amount of time/money
printing and filing.

As RobG mentioned, this task is better suited for the server.

What about this? It seems to work.

Those are typically famous last words.

while (e = oForm.elements[i++]) {

I don't care for that style (it raises the question of whether it was
supposed to be two equal signs).

if (e.type == 'checkbox') {
if (e.checked == true) {

if (e.checked) {

The rest is superfluous.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}

Here you have set the attribute, which _should_ show up in the innerHTML.

if (e.type == 'radio') {
var x = e.name;
Why?

if (e.checked == true) {

See above.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
}

Seems redundant other than the unused - x - variable, but you have the
basic idea.

But what about the selects? This is all leading to a much simpler
server-side solution.

 

[MC]

David Mark, my favorite javascript guy!
Hey!
Yes, I am trying to get the user input from checkbox, radio, input,
and
select.
There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).
It seems the input is retrieved via innerHTML but the other is not.
The results of that proprietary property are implementation
dependant. You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the
form
controls. It sounds as if the browsers you tested were referencing
the defaultChecked and defaultSelected properties for radio/checkbox
inputs and select options, but not the defaultValue property for
text
inputs. That's certainly an incongruous approach.
Also, if you must deal with multi-selects, there is no single
property
to reference (you have to loop through the options and check the
selected property for each).
And I've got to ask, what is the purpose of this? Seems like a can
of
worms that doesn't need to be opened.
Please don't top-post. It screws up the context of the dicussion
(and
I don't care to restore it).
Purpose: Document a page into an archive (with user input) via ajax.
These
pages are basically user forms that are then sent to a document
archive
service. Without the user input, archival is useless.
Deja vu. Haven't we had this discussion before?
Personally, I would serialize the data without the markup.
We have and I didn't find an answer. Prior to this, the archival
software
was not finished. The archival software is now complete and working
like
a
champ turning html into beautiful pdf exactly like the html form. So
now
the
project is going live and I need to resolve this last issue.
You will have to traverse the form and build the HTML string yourself
as innerHTML is not an appropriate format to store (varies from one
browser to the next). Have you tried to do that? If you only need
form controls, it is fairly trivial. First define what sort of form
controls will be involved (e.g. what about textareas?)

Start with something like this:-

function serializeFormHtml(name) {
var el = document.forms[name];
var control, controls = el.elements;
var result = [];

for (var i = controls.length; i-- {
control = controls;
switch (control.tagName.toLowerCase()) {
case 'input':
...
break;
case 'select':
...
break;
case 'textarea':
...
break;
}
}

return result.join('');
}

You will have to fill in the blanks as only you know the context of
your application. For example, other than name and value; what, if
any, attributes should be included? Will there be multi-selects, do
you care about disabled controls, etc.?

All of those controls will be dealt with. We are not storing html but
converting html into a pdf representation and it is pretty exact. Its
actually really cool, as users go about their day, their work is
automatically e-archived via ajax, saving them a huge amount of
time/money
printing and filing.

As RobG mentioned, this task is better suited for the server.

What about this? It seems to work.

Those are typically famous last words.

while (e = oForm.elements[i++]) {

I don't care for that style (it raises the question of whether it was
supposed to be two equal signs).

if (e.type == 'checkbox') {
if (e.checked == true) {

if (e.checked) {

The rest is superfluous.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}

Here you have set the attribute, which _should_ show up in the innerHTML.

if (e.type == 'radio') {
var x = e.name;
Why?

if (e.checked == true) {

See above.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
}

Seems redundant other than the unused - x - variable, but you have the
basic idea.

But what about the selects? This is all leading to a much simpler
server-side solution.

Your right, here it is refactored. Still in working on the select.
function processFormData(oForm) {
var e, i = 0;
while (e = oForm.elements[i++]) {
if (e.type == 'checkbox' || e.type == 'radio') {
if (e.checked == true) {
e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
if (e.type == 'select') { // working on this
}
}
}

 

[MC]

There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).

The results of that proprietary property are implementation
dependant. You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the form
controls. It sounds as if the browsers you tested were referencing
the defaultChecked and defaultSelected properties for radio/checkbox
inputs and select options, but not the defaultValue property for text
inputs. That's certainly an incongruous approach.

Also, if you must deal with multi-selects, there is no single property
to reference (you have to loop through the options and check the
selected property for each).

And I've got to ask, what is the purpose of this? Seems like a can of
worms that doesn't need to be opened.

[...]
Purpose: Document a page into an archive (with user input) via ajax. These
pages are basically user forms that are then sent to a document archive
service. Without the user input, archival is useless.

The results of setting the innerHTML property seems reasonably
consistent across browsers, however getting it is inconsistent.

Why not just submit the form and have the server update the original
HTML with the returned values. Saves a whole load of client-side grief
and much easier to implement.


--
Rob

Rob,
Your right. I guess my logic was it was easier to manage one chunk of data
on the client rather than the form submit and innerHTML, and manipulate it
on the server. Better or not I don't know. But it is working now and looks
rather nice and is very useful.
MC

 

[David Mark]

David Mark, my favorite javascript guy!
Hey!
Yes, I am trying to get the user input from checkbox, radio, input,
and
select.
There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).
It seems the input is retrieved via innerHTML but the other is not.
The results of that proprietary property are implementation
dependant. You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the
form
controls. It sounds as if the browsers you tested were referencing
the defaultChecked and defaultSelected properties for radio/checkbox
inputs and select options, but not the defaultValue property for
text
inputs. That's certainly an incongruous approach.
Also, if you must deal with multi-selects, there is no single
property
to reference (you have to loop through the options and check the
selected property for each).
And I've got to ask, what is the purpose of this? Seems like a can
of
worms that doesn't need to be opened.
Please don't top-post. It screws up the context of the dicussion
(and
I don't care to restore it).
Purpose: Document a page into an archive (with user input) via ajax.
These
pages are basically user forms that are then sent to a document
archive
service. Without the user input, archival is useless.
Deja vu. Haven't we had this discussion before?
Personally, I would serialize the data without the markup.
We have and I didn't find an answer. Prior to this, the archival
software
was not finished. The archival software is now complete and working
like
a
champ turning html into beautiful pdf exactly like the html form. So
now
the
project is going live and I need to resolve this last issue.
You will have to traverse the form and build the HTML string yourself
as innerHTML is not an appropriate format to store (varies from one
browser to the next). Have you tried to do that? If you only need
form controls, it is fairly trivial. First define what sort of form
controls will be involved (e.g. what about textareas?)

Start with something like this:-

function serializeFormHtml(name) {
var el = document.forms[name];
var control, controls = el.elements;
var result = [];

for (var i = controls.length; i-- {
control = controls;
switch (control.tagName.toLowerCase()) {
case 'input':
...
break;
case 'select':
...
break;
case 'textarea':
...
break;
}
}

return result.join('');
}

You will have to fill in the blanks as only you know the context of
your application. For example, other than name and value; what, if
any, attributes should be included? Will there be multi-selects, do
you care about disabled controls, etc.?
All of those controls will be dealt with. We are not storing html but
converting html into a pdf representation and it is pretty exact. Its
actually really cool, as users go about their day, their work is
automatically e-archived via ajax, saving them a huge amount of
time/money
printing and filing.

As RobG mentioned, this task is better suited for the server.

What about this? It seems to work.

Those are typically famous last words.

while (e = oForm.elements[i++]) {

I don't care for that style (it raises the question of whether it was
supposed to be two equal signs).

if (e.type == 'checkbox') {
if (e.checked == true) {

if (e.checked) {

The rest is superfluous.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}

Here you have set the attribute, which _should_ show up in the innerHTML.

if (e.type == 'radio') {
var x = e.name; Why?

if (e.checked == true) {

See above.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
}

Seems redundant other than the unused - x - variable, but you have the
basic idea.

But what about the selects? This is all leading to a much simpler
server-side solution.

Your right, here it is refactored. Still in working on the select.
function processFormData(oForm) {
var e, i = 0;
while (e = oForm.elements[i++]) {
if (e.type == 'checkbox' || e.type == 'radio') {
if (e.checked == true) {
e.defaultChecked = true;
} else {
e.defaultChecked = false;
}

Why not just:-

e.defaultChecked = e.checked;

}
if (e.type == 'select') { // working on this

Loop through the options, set defaultSelected to match selected for each.

 

[MC]

MC wrote:




David Mark, my favorite javascript guy!
Hey!
Yes, I am trying to get the user input from checkbox, radio,
input,
and
select.
There are inputs, selects and textareas (checkbox and radio are
_types_ of inputs).
It seems the input is retrieved via innerHTML but the other is
not.
The results of that proprietary property are implementation
dependant. You will have to traverse the DOM and use the checked,
value and selectedIndex properties to determine the states of the
form
controls. It sounds as if the browsers you tested were
referencing
the defaultChecked and defaultSelected properties for
radio/checkbox
inputs and select options, but not the defaultValue property for
text
inputs. That's certainly an incongruous approach.
Also, if you must deal with multi-selects, there is no single
property
to reference (you have to loop through the options and check the
selected property for each).
And I've got to ask, what is the purpose of this? Seems like a
can
of
worms that doesn't need to be opened.
Please don't top-post. It screws up the context of the dicussion
(and
I don't care to restore it).
Purpose: Document a page into an archive (with user input) via
ajax.
These
pages are basically user forms that are then sent to a document
archive
service. Without the user input, archival is useless.
Deja vu. Haven't we had this discussion before?
Personally, I would serialize the data without the markup.
We have and I didn't find an answer. Prior to this, the archival
software
was not finished. The archival software is now complete and working
like
a
champ turning html into beautiful pdf exactly like the html form. So
now
the
project is going live and I need to resolve this last issue.
You will have to traverse the form and build the HTML string yourself
as innerHTML is not an appropriate format to store (varies from one
browser to the next). Have you tried to do that? If you only need
form controls, it is fairly trivial. First define what sort of form
controls will be involved (e.g. what about textareas?)

Start with something like this:-

function serializeFormHtml(name) {
var el = document.forms[name];
var control, controls = el.elements;
var result = [];

for (var i = controls.length; i-- {
control = controls;
switch (control.tagName.toLowerCase()) {
case 'input':
...
break;
case 'select':
...
break;
case 'textarea':
...
break;
}
}

return result.join('');
}

You will have to fill in the blanks as only you know the context of
your application. For example, other than name and value; what, if
any, attributes should be included? Will there be multi-selects, do
you care about disabled controls, etc.?
All of those controls will be dealt with. We are not storing html but
converting html into a pdf representation and it is pretty exact. Its
actually really cool, as users go about their day, their work is
automatically e-archived via ajax, saving them a huge amount of
time/money
printing and filing.
As RobG mentioned, this task is better suited for the server.

What about this? It seems to work.
Those are typically famous last words.

while (e = oForm.elements[i++]) {
I don't care for that style (it raises the question of whether it was
supposed to be two equal signs).

if (e.type == 'checkbox') {
if (e.checked == true) {
if (e.checked) {

The rest is superfluous.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
Here you have set the attribute, which _should_ show up in the
innerHTML.

if (e.type == 'radio') {
var x = e.name;
Why?

if (e.checked == true) {
See above.

e.defaultChecked = true;
} else {
e.defaultChecked = false;
}
}
}
Seems redundant other than the unused - x - variable, but you have the
basic idea.

But what about the selects? This is all leading to a much simpler
server-side solution.

Your right, here it is refactored. Still in working on the select.
function processFormData(oForm) {
var e, i = 0;
while (e = oForm.elements[i++]) {
if (e.type == 'checkbox' || e.type == 'radio') {
if (e.checked == true) {
e.defaultChecked = true;
} else {
e.defaultChecked = false;
}

Why not just:-

e.defaultChecked = e.checked;

}
if (e.type == 'select') { // working on this

Loop through the options, set defaultSelected to match selected for each.

David...

This is why your my favorite JS expert You offer great tutilage without
judgement. I did this because there might be an initial default in code and
this will remove it.

Thank you!!!!
MC
PS. Don't tell pointy ears, but I vote you #1...I can't stand to hear his
ranting

 

[David Mark]

MC wrote:

[...]

David...

This is why your my favorite JS expert

Glad I could help!

You offer great tutilage without
judgement.

I try.

I did this because there might be an initial default in code and
this will remove it.

Yes, it will clobber all of the defaults (as you wanted).

Thank you!!!!
MC
PS. Don't tell pointy ears, but I vote you #1...I can't stand to hear his
ranting

It's not really a contest, but thanks for your support!