Prev: How to handle special character in javascript
Next: NinjaTrader 6.5 Torrent - www.top-tradesoft.com
From: RobG on 9 Feb 2010 17:54
On Feb 10, 4:57 am, "MC" <mica[removethis]@aisus.com> wrote:
> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>
> news:be291d52-360d-464e-9f26-4e8b612e368d(a)a13g2000vbf.googlegroups.com...
>
>
>
> > On Feb 9, 1:20 pm, "MC" <mica[removethis]@aisus.com> 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.
[...]
> 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
From: David Mark on 9 Feb 2010 18:13
MC wrote:
> "David Mark" <dmark.cinsoft(a)gmail.com> wrote in message
> news:685a01f4-502a-4829-9f5f-04791fbef3a9(a)f15g2000yqe.googlegroups.com...
>> On Feb 9, 2:14 pm, "MC" <mica[removethis]@aisus.com> wrote:
>>> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>>>
>>> news:fae9c4d0-11b6-46ec-a448-a202172ff873(a)b18g2000vba.googlegroups.com...
>>>
>>>
>>>
>>>> On Feb 9, 1:57 pm, "MC" <mica[removethis]@aisus.com> wrote:
>>>>> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>>>>> news:be291d52-360d-464e-9f26-4e8b612e368d(a)a13g2000vbf.googlegroups.com...
>>>>>> On Feb 9, 1:20 pm, "MC" <mica[removethis]@aisus.com> 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[i];
>> 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.
From: MC on 9 Feb 2010 18:36

"David Mark" <dmark.cinsoft(a)gmail.com> wrote in message
news:hksq8a$6ho$1(a)news.eternal-september.org...
> MC wrote:
>> "David Mark" <dmark.cinsoft(a)gmail.com> wrote in message
>> news:685a01f4-502a-4829-9f5f-04791fbef3a9(a)f15g2000yqe.googlegroups.com...
>>> On Feb 9, 2:14 pm, "MC" <mica[removethis]@aisus.com> wrote:
>>>> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>>>>
>>>> news:fae9c4d0-11b6-46ec-a448-a202172ff873(a)b18g2000vba.googlegroups.com...
>>>>
>>>>
>>>>
>>>>> On Feb 9, 1:57 pm, "MC" <mica[removethis]@aisus.com> wrote:
>>>>>> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>>>>>> news:be291d52-360d-464e-9f26-4e8b612e368d(a)a13g2000vbf.googlegroups.com...
>>>>>>> On Feb 9, 1:20 pm, "MC" <mica[removethis]@aisus.com> 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[i];
>>> 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
}
}
}


From: MC on 9 Feb 2010 18:40

"RobG" <rgqld(a)iinet.net.au> wrote in message
news:53680de8-b5c5-4e16-8a81-0b7963b3939c(a)l24g2000prh.googlegroups.com...
On Feb 10, 4:57 am, "MC" <mica[removethis]@aisus.com> wrote:
> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>
> news:be291d52-360d-464e-9f26-4e8b612e368d(a)a13g2000vbf.googlegroups.com...
>
>
>
> > On Feb 9, 1:20 pm, "MC" <mica[removethis]@aisus.com> 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.
[...]
> 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


From: David Mark on 9 Feb 2010 18:41
MC wrote:
> "David Mark" <dmark.cinsoft(a)gmail.com> wrote in message
> news:hksq8a$6ho$1(a)news.eternal-september.org...
>> MC wrote:
>>> "David Mark" <dmark.cinsoft(a)gmail.com> wrote in message
>>> news:685a01f4-502a-4829-9f5f-04791fbef3a9(a)f15g2000yqe.googlegroups.com...
>>>> On Feb 9, 2:14 pm, "MC" <mica[removethis]@aisus.com> wrote:
>>>>> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>>>>>
>>>>> news:fae9c4d0-11b6-46ec-a448-a202172ff873(a)b18g2000vba.googlegroups.com...
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 9, 1:57 pm, "MC" <mica[removethis]@aisus.com> wrote:
>>>>>>> "David Mark" <dmark.cins...(a)gmail.com> wrote in message
>>>>>>> news:be291d52-360d-464e-9f26-4e8b612e368d(a)a13g2000vbf.googlegroups.com...
>>>>>>>> On Feb 9, 1:20 pm, "MC" <mica[removethis]@aisus.com> 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[i];
>>>> 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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: How to handle special character in javascript
Next: NinjaTrader 6.5 Torrent - www.top-tradesoft.com