Posting a hidden field to a form in a document using javascript

Hi all,

I need to add an input hidden field to an existing form (post).

I have tried a couple things like adding the '<INPUT type=hidden
name=idSelectedURL value=http://server/documents>' to the innerHTML of
the form but it fails.

ie

var sField = "<INPUT type=hidden name=idSelectedURL
value=http://server/documents>";
frm.innerHTML = frm.innerHTML + sField;


also, trying to add an element to the form such as:
var frm = document.getElementById("idForm");
var oField = frm.createElement ('input');
oField.type ="hidden";
oField.name = "idSelectedURL";
oField.value ="http://server/documents";

none of these work and give me a javascript error.

I don't think the createElement method can be used from the form
object, only from the document object. still could not get it working.


If anyone can provide me with some information on how to do this i
would greatly appreciate it.

Thanks in advance.

Sergio

re: Posting a hidden field to a form in a document using javascript

Sergio Otoya wrote:
[color=blue]
> also, trying to add an element to the form such as:
> var frm = document.getElementById("idForm");
> var oField = frm.createElement ('input');
> oField.type ="hidden";
> oField.name = "idSelectedURL";
> oField.value ="http://server/documents";[/color]

Two steps, step one is to create the element e.g.
var input;
if (document.createElement) {
input = document.createElement('input');
input.type = 'hidden';
input.name = 'selectedURL';
input.value = input.defaultValue = 'http://example.com/documents';
then step two is to insert the element where you want it e.g.
frm.appendChild(input);
}

--

Martin Honnen
http://JavaScript.FAQTs.com/

re: Posting a hidden field to a form in a document using javascript

Martin Honnen wrote:
[color=blue]
> Sergio Otoya wrote:[color=green]
>> also, trying to add an element to the form such as:
>> var frm = document.getElementById("idForm");
>> var oField = frm.createElement ('input');
>> oField.type ="hidden";
>> oField.name = "idSelectedURL";
>> oField.value ="http://server/documents";[/color]
>
> Two steps, step one is to create the element e.g.
> var input;
> if (document.createElement) {
> input = document.createElement('input');[/color]

I *strongly* recommend to

1) declare variables only where needed
2) check references before using them

So a better way would be

var t; // see below
if ((t = typeof document.createElement) == "function"
|| (t == "object" && document.createElement))
{
var input = document.createElement('input');
if (input)
{

It should be noted that some versions of Internet Explorer do support
document.createElement() but support only the proprietary approach of
a start tag instead of an element type identifier as argument for that
method. Therefore using a wrapper method, like createElement() as
defined in JSX:dhtml.js[1], should be considered.
[color=blue]
> input.type = 'hidden';
> input.name = 'selectedURL';
> input.value = input.defaultValue = 'http://example.com/documents';[/color]

There is still the caveat here that the host object may not provide the
properties accessed herewith. Although such an implementation could
be considered borken (as it implements a method defined in the W3C Core
DOM but not properties defined in the W3C HTML DOM), it should be taken
into account that host objects may not allow to add properties (as
specified in ECMAScript) and so trying to add them could result in an
exception or a script error. Therefore, it appears to be wiser to check
the properties accessed later for existence, too:

if (input
&& typeof input.type != "undefined"
&& typeof input.name != "undefined"
&& typeof input.value != "undefined")
{
// [assignment to properties of the host object]
[color=blue]
> then step two is to insert the element where you want it e.g.
> frm.appendChild(input);[/color]

Of course, as support for document.createElement() also does not imply
support for elemRef.appendChild(), the latter method should be checked
for existence prior to call in order to avoid script errors (the `t'
variable declared previously can be reused here; however isMethod() and
isMethodType() defined in JSX:types.js[1] provide a more convenient way
of testing):

if ((t = typeof frm.appendChild) == "function"
|| (t == "object" && frm.appendChild))
{
frm.appendChild(input);
}
}[color=blue]
> }
>[/color]

See also the second section of <http://pointedears.de/scripts/test/whatami>
(or <http://pointedears.ml-webhosting.de/scripts/test/whatami>).


PointedEars
___________
[1] base URI: <http://pointedears.de/scripts/> or
<http://pointedears.ml-webhosting.de/scripts/>

re: Posting a hidden field to a form in a document using javascript

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Martin Honnen wrote:[/color]
<snip>[color=blue][color=green]
>> Two steps, step one is to create the element e.g.
>> var input;
>> if (document.createElement) {
>> input = document.createElement('input');[/color]
>
> I *strongly* recommend to
>
> 1) declare variables only where needed[/color]
<snip>

That is the sort of silly advice that promotes the running misconception
that ECMAScript is block-scoped like Java.

As ECMAScript does variable instantiation once as it enters the
execution context of a function it is conceptually closer to the code's
actual behaviour to declare all local variables together at the top of a
function (either just before any inner function declarations or just
after; preferably before, as that means it is always only necessary to
move upwards to find the declarations of variables used in
closures/nested scopes, and it places the local variable declarations
alongside the function's formal parameter definitions.).

Doing so reduces the potential for declaring the same variable more than
once (regardless of how harmless that may be, except in terms of
execution speed) and gives the author a single place to look to
determine whether any identifier used is declared locally (rather than
having to scan the entire function body looking for - var - keywords)
(or a clear sequence of locations when nested scopes are involved).

It also allows the local variable declarations to take the form of a
list and so reduce the number of occurrences of the - var - keyword, and
so reduce the size of the resulting code.

Richard.

re: Posting a hidden field to a form in a document using javascript

Richard Cornford wrote:
[color=blue]
> Thomas 'PointedEars' Lahn wrote:[color=green]
>> Martin Honnen wrote:[/color]
> <snip>[color=green][color=darkred]
>>> Two steps, step one is to create the element e.g.
>>> var input;
>>> if (document.createElement) {
>>> input = document.createElement('input');[/color]
>>
>> I *strongly* recommend to
>>
>> 1) declare variables only where needed[/color]
> <snip>
>
> [...]
> As ECMAScript does variable instantiation once as it enters the
> execution context of a function[/color]

You're right, my bad. I noticed in Venkman, however, that globals are
not instantiated before their declaration/initialization in SpiderMonkey,
the JavaScript 1.5 implementation in Gecko-based browsers. So I write
more precisely: Avoid variables whereever reasonable; avoid globals,
especially avoid them to be declared unconditionally when not needed
as they are not instantiated when the global execution context is
entered, at least not Gecko-based browsers; avoid locals because they
are all instantiated when the local execution context is entered and
so more variables will slow down the initialization process. Agreed?
[color=blue]
> it is conceptually closer to the code's actual behaviour to declare all
> local variables together at the top of a function [...]
> It also allows the local variable declarations to take the form of a
> list and so reduce the number of occurrences of the - var - keyword, and
> so reduce the size of the resulting code.[/color]

However, the drawbacks of that style are that unused variables tend to
remain in the source code because they are declared before needed. As
a result of the latter the editing source code becomes more difficult
because introducing a new variable requires scrolling to move the cursor
to the position where the variable declaration (list) is located. A good
two-pane editor removes the need for the latter and so removes that
drawback; however, such an editor is not always available for everyone.


PointedEars
--
"The good news is that [in the future] we will have a good operating
system and programming language. The bad news is that they will be
Unix and C++."
-- Richard P. Gabriel

re: Posting a hidden field to a form in a document using javascript

Thomas 'PointedEars' Lahn wrote:
[color=blue]
> Martin Honnen wrote:
>[/color]
[color=blue][color=green]
>> var input;
>> if (document.createElement) {
>> input = document.createElement('input');[/color]
>
>
> I *strongly* recommend to
>
> 1) declare variables only where needed[/color]

I see, that is why you have for instance

function createElement(sTagName)
{
var o = null;

if (sTagName
&& typeof document != "undefined"
&& dhtml.isMethodType(typeof document.createElement))
{
// remove


sTagName = sTagName.replace(/<?([^ >]+).*>?/, "$1");

o = document.createElement(sTagName);

in your lib, isn't it?
Anyway, Richard has already told you that there is no block scope in
ECMAScript.

[color=blue]
> It should be noted that some versions of Internet Explorer do support
> document.createElement() but support only the proprietary approach of
> a start tag instead of an element type identifier as argument for that
> method.[/color]

Which IE versions would that be? I am pretty sure that IE 5 and later
support document.createElement('tagname') while also supporting the
proprietary document.createElement('<tagname>') but I don't know of any
version that only supports the latter.

[color=blue][color=green]
>> input.type = 'hidden';
>> input.name = 'selectedURL';
>> input.value = input.defaultValue = 'http://example.com/documents';[/color]
>
>
> There is still the caveat here that the host object may not provide the
> properties accessed herewith.[/color]
[color=blue]
> Therefore, it appears to be wiser to check
> the properties accessed later for existence, too:
>
> if (input
> && typeof input.type != "undefined"
> && typeof input.name != "undefined"
> && typeof input.value != "undefined")[/color]

No, frankly with script in a HTML document as is usually the case in
this newsgroup and as it was certainly the case in that weeks old thread
you are following up to I think one can safely assume that the object
created with document.createElement('input') is a HTMLInputElement where
those properties can be set and those checks for properties would only
clutter the code then.

--

Martin Honnen
http://JavaScript.FAQTs.com/

re: Posting a hidden field to a form in a document using javascript

Martin Honnen wrote:
[color=blue]
> Thomas 'PointedEars' Lahn wrote:[color=green]
>> Martin Honnen wrote:[color=darkred]
>>> var input;
>>> if (document.createElement) {
>>> input = document.createElement('input');[/color]
>>
>> I *strongly* recommend to
>>
>> 1) declare variables only where needed[/color]
>
> I see, that is why you have for instance
>
> function createElement(sTagName)
> {
> var o = null;
>
> if ([...])
> {
> [...]
> o = document.createElement(sTagName);
>
> in your lib, isn't it?[/color]

Yes, because, e.g., it continues with

| [...]
| }
|
| return o;
| }
[color=blue]
> Anyway, Richard has already told you that there is no block scope in
> ECMAScript.[/color]

And I explained that behavior differs between global and local execution
context which should be considered when declaring variables. Neither of
our statements was precise enough.
[color=blue][color=green]
>> It should be noted that some versions of Internet Explorer do support
>> document.createElement() but support only the proprietary approach of
>> a start tag instead of an element type identifier as argument for that
>> method.[/color]
>
> Which IE versions would that be? I am pretty sure that IE 5 and later
> support document.createElement('tagname') while also supporting the
> proprietary document.createElement('<tagname>') but I don't know of any
> version that only supports the latter.[/color]

Well, in fact *you* brought up the idea (in de.comp.lang.javascript),
testing with some IE version ... Have I misunderstood something?
[color=blue][color=green][color=darkred]
>>> input.type = 'hidden';
>>> input.name = 'selectedURL';
>>> input.value = input.defaultValue = 'http://example.com/documents';[/color]
>>
>> There is still the caveat here that the host object may not provide the
>> properties accessed herewith.
>>
>> Therefore, it appears to be wiser to check
>> the properties accessed later for existence, too:
>>
>> if (input
>> && typeof input.type != "undefined"
>> && typeof input.name != "undefined"
>> && typeof input.value != "undefined")[/color]
>
> No, frankly with script in a HTML document as is usually the case in
> this newsgroup[/color]

"Usually" is not "always", and HTML is not restricted to Web browsers.
Waiting for script errors is certainly bad style.
[color=blue]
> and as it was certainly the case in that weeks old thread you are
> following up to I think one can safely assume that the object
> created with document.createElement('input') is a HTMLInputElement where
> those properties can be set and those checks for properties would only
> clutter the code then.[/color]

As for the subject of the thread, that does not matter; it was of course
a general note about programming style. But even if I took that into
account, support for one method does by no means imply the support for
another, so both should be checked for. *At least* the return value of
document.createElement(...) *has* to be checked for by a reasonable
developer before applying it, as W3C DOM Level 2+ Core specifies
(implicitely) that the method may either return an element object
reference or not:

<http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-2141741547>
<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-2141741547>

As for the age of the thread, I have been absent for a while again and
now comment on whereever I find that necessary, no matter the age of the
thread. This is a high-traffic group and I am just trying to keep pace ...


PointedEars
--
Two things are infinite: the universe and stupidity.
And the former I'm not so sure about.
-- Albert Einstein

re: Posting a hidden field to a form in a document using javascript

Thomas 'PointedEars' Lahn wrote:
[color=blue]
> Martin Honnen wrote:
>
>[color=green]
>>Thomas 'PointedEars' Lahn wrote:
>>[/color][/color]
[color=blue]
>[color=green][color=darkred]
>>>It should be noted that some versions of Internet Explorer do support
>>>document.createElement() but support only the proprietary approach of
>>>a start tag instead of an element type identifier as argument for that
>>>method.[/color]
>>
>>Which IE versions would that be? I am pretty sure that IE 5 and later
>>support document.createElement('tagname') while also supporting the
>>proprietary document.createElement('<tagname>') but I don't know of any
>>version that only supports the latter.[/color]
>
>
> Well, in fact *you* brought up the idea (in de.comp.lang.javascript),
> testing with some IE version ... Have I misunderstood something?[/color]

I have certainly not claimed that some IE version doesn't support
document.createElement('tagname') while supporting
document.createElement('<tagname>'). Someone might have shown up in the
newsgroup and used the latter and then I might have pointed out that
that is IE only but certainly not to imply that the former is not
suppored by IE.


--

Martin Honnen
http://JavaScript.FAQTs.com/

re: Posting a hidden field to a form in a document using javascript

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> Thomas 'PointedEars' Lahn wrote:[color=darkred]
>>> I *strongly* recommend to
>>> 1) declare variables only where needed[/color]
>> <snip>
>>
>> [...]
>> As ECMAScript does variable instantiation once as it
>> enters the execution context of a function[/color]
>
> You're right, my bad. I noticed in Venkman, however, that
> globals are not instantiated before their declaration/
> initialization in SpiderMonkey, the JavaScript 1.5
> implementation in Gecko-based browsers.[/color]

If that were true code such as:-

if(x){
alert((typeof x));
}
var x = 4;

- executed in the global context, would error when the - if - expression
was evaluated as - x - would not, at that point, have been created as a
property of the global object (which is the Variable object in the
global execution context).

That code does not error in Mozilla/Gecko browsers so it looks to me as
if ECMA 262 (3rd edition) is properly implemented in this respect and so
variable instantiation happens once (for each script element) as
execution enters the global execution context. Making the positioning of
variable declarations using the - var - keyword as insignificant as it
is in function body code.
[color=blue]
> So I write more precisely: Avoid variables whereever
> reasonable;[/color]

An easily misdirecting form of words. Avoiding variables may be achieved
by re-resolving long property accessors rather than caching the most
specific object reference in a local variable. And qualifying it with
'wherever reasonable' requires judgement best made from the position of
having gained the sort of knowledge, understanding and experience that
significantly diminishes the need for the conscious application of
formal rules.
[color=blue]
> avoid globals, especially avoid them to be declared
> unconditionally when not needed as they are not
> instantiated when the global execution context is
> entered, at least not Gecko-based browsers;[/color]

I see no evidence of aberrant behaviour from Gecko browsers in this
respect, and I would never recommend disregarding ECMA 262 in favour of
what would be (if it was true) incorrect behaviour on the part of just
one ECMAScript implementation when writing to the specification would
not result in any errors.
[color=blue]
> avoid locals because they are all instantiated
> when the local execution context is entered and
> so more variables will slow down the initialization
> process.[/color]

In DHTML execution speed can be very significant, in other contexts you
might choose to trade execution speed for source code clarity. So rather
than re-using one 'temp' local variable for many tasks, you might choose
to have an explicitly named local variable for each distinct task.

I would imagine that the creation of the Activation/Variable object is
considerably more time consuming than the creation of a named property
of that object.
[color=blue]
> Agreed?[/color]

Not really. While there undoubtedly are numerous formal disciplines that
should be applied to code authoring, and so recommended to newcomers,
there is also value in the application of informed pragmatism. An overly
rule-based approach to code authoring strikes me as likely to result in
inflexible attitudes and reduce the potential for creativity and
invention. And if code authoring could be exclusively rule-based then it
could be automated and we would all be out of work.

Rather than trying to formulate some sort of new rule for the
creation/declaration/use of variables it strikes me as better that
people understand the specified mechanism, and anything that is
considered a related issue, and apply that knowledge to the context in
which they are working. I would expect to see similar manifestations of
the application of that understanding, but I wouldn't want to try to
formalise those similar manifestations into code authoring rules.
[color=blue][color=green]
>> it is conceptually closer to the code's actual behaviour
>> to declare all local variables together at the top of a
>> function [...] It also allows the local variable declarations
>> to take the form of a list and so reduce the number of
>> occurrences of the - var - keyword, and so reduce the size
>> of the resulting code.[/color]
>
> However, the drawbacks of that style are that unused variables
> tend to remain in the source code because they are declared
> before needed.[/color]

I can see that happening either way. Personally, I tend to go through a
phase of formal verification of local variables (at least in large
functions) once I have the code working. Aided by only having to look in
one location for all of the local variables; simple - select, search,
and if a local variable is not found in the finished function body it
can be deleted from the list.
[color=blue]
> As a result of the latter the editing source code
> becomes more difficult because introducing a new variable
> requires scrolling to move the cursor to the position
> where the variable declaration (list) is located. A good
> two-pane editor removes the need for the latter and so
> removes that drawback; however, such an editor is not always
> available for everyone.[/color]

Allow coding style to be determined by the possibility that very
occasionally there may be no alternative to editing code in Notepad? I
don't think so.

Richard.