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

[Sergio Otoya]

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=idSelected URL value=http://server/documents>' to the innerHTML of
the form but it fails.

ie

var sField = "<INPUT type=hidden name=idSelected URL
value=http://server/documents>";
frm.innerHTML = frm.innerHTML + sField;
also, trying to add an element to the form such as:
var frm = document.getEle mentById("idFor m");
var oField = frm.createEleme nt ('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

[Martin Honnen]

Sergio Otoya wrote:

also, trying to add an element to the form such as:
var frm = document.getEle mentById("idFor m");
var oField = frm.createEleme nt ('input');
oField.type ="hidden";
oField.name = "idSelectedURL" ;
oField.value ="http://server/documents";

Two steps, step one is to create the element e.g.
var input;
if (document.creat eElement) {
input = document.create Element('input' );
input.type = 'hidden';
input.name = 'selectedURL';
input.value = input.defaultVa lue = '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/

[Thomas 'PointedEars' Lahn]

Martin Honnen wrote:

Sergio Otoya wrote:

also, trying to add an element to the form such as:
var frm = document.getEle mentById("idFor m");
var oField = frm.createEleme nt ('input');
oField.type ="hidden";
oField.name = "idSelectedURL" ;
oField.value ="http://server/documents";
Two steps, step one is to create the element e.g.
var input;
if (document.creat eElement) {
input = document.create Element('input' );

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.create Element) == "function"
|| (t == "object" && document.create Element))
{
var input = document.create Element('input' );
if (input)
{

It should be noted that some versions of Internet Explorer do support
document.create Element() 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.
input.type = 'hidden';
input.name = 'selectedURL';
input.value = input.defaultVa lue = 'http://example.com/documents';
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]
then step two is to insert the element where you want it e.g.
frm.appendChild (input);
Of course, as support for document.create Element() also does not imply
support for elemRef.appendC hild(), 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);
}
} }

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/>

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Martin Honnen wrote:

<snip>

Two steps, step one is to create the element e.g.
var input;
if (document.creat eElement) {
input = document.create Element('input' );

I *strongly* recommend to

1) declare variables only where needed

<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.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote:

Martin Honnen wrote: <snip>

Two steps, step one is to create the element e.g.
var input;
if (document.creat eElement) {
input = document.create Element('input' );

I *strongly* recommend to

1) declare variables only where needed

<snip>

[...]
As ECMAScript does variable instantiation once as it enters the
execution context of a function

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?
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.

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

[Martin Honnen]

Thomas 'PointedEars' Lahn wrote:

Martin Honnen wrote:

var input;
if (document.creat eElement) {
input = document.create Element('input' );

I *strongly* recommend to

1) declare variables only where needed

I see, that is why you have for instance

function createElement(s TagName)
{
var o = null;

if (sTagName
&& typeof document != "undefined"
&& dhtml.isMethodT ype(typeof document.create Element))
{
// remove
sTagName = sTagName.replac e(/<?([^ >]+).*>?/, "$1");

o = document.create Element(sTagNam e);

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

It should be noted that some versions of Internet Explorer do support
document.create Element() but support only the proprietary approach of
a start tag instead of an element type identifier as argument for that
method.
Which IE versions would that be? I am pretty sure that IE 5 and later
support document.create Element('tagnam e') while also supporting the
proprietary document.create Element('<tagna me>') but I don't know of any
version that only supports the latter.

input.type = 'hidden';
input.name = 'selectedURL';
input.value = input.defaultVa lue = 'http://example.com/documents';

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" )

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.create Element('input' ) is a HTMLInputElemen t where
those properties can be set and those checks for properties would only
clutter the code then.

--

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

[Thomas 'PointedEars' Lahn]

Martin Honnen wrote:

Thomas 'PointedEars' Lahn wrote:

Martin Honnen wrote:

var input;
if (document.creat eElement) {
input = document.create Element('input' );
I *strongly* recommend to

1) declare variables only where needed

I see, that is why you have for instance

function createElement(s TagName)
{
var o = null;

if ([...])
{
[...]
o = document.create Element(sTagNam e);

in your lib, isn't it?

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

| [...]
| }
|
| return o;
| }
Anyway, Richard has already told you that there is no block scope in
ECMAScript.
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.

It should be noted that some versions of Internet Explorer do support
document.create Element() but support only the proprietary approach of
a start tag instead of an element type identifier as argument for that
method.

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

Well, in fact *you* brought up the idea (in de.comp.lang.ja vascript),
testing with some IE version ... Have I misunderstood something?

input.type = 'hidden';
input.name = 'selectedURL';
input.value = input.defaultVa lue = 'http://example.com/documents';

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" )

No, frankly with script in a HTML document as is usually the case in
this newsgroup

"Usually" is not "always", and HTML is not restricted to Web browsers.
Waiting for script errors is certainly bad style.
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.create Element('input' ) is a HTMLInputElemen t where
those properties can be set and those checks for properties would only
clutter the code then.

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.create Element(...) *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

[Martin Honnen]

Thomas 'PointedEars' Lahn wrote:

Martin Honnen wrote:

Thomas 'PointedEars' Lahn wrote:

It should be noted that some versions of Internet Explorer do support
document.cre ateElement() but support only the proprietary approach of
a start tag instead of an element type identifier as argument for that
method.

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

Well, in fact *you* brought up the idea (in de.comp.lang.ja vascript),
testing with some IE version ... Have I misunderstood something?

I have certainly not claimed that some IE version doesn't support
document.create Element('tagnam e') while supporting
document.create Element('<tagna me>'). 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/

[Richard Cornford]

Thomas 'PointedEars' Lahn wrote:

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote:

I *strongly* recommend to
1) declare variables only where needed <snip>

[...]
As ECMAScript does variable instantiation once as it
enters the execution context of a function

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.

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.
So I write more precisely: Avoid variables whereever
reasonable;
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.
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;
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.
avoid locals because they are all instantiated
when the local execution context is entered and
so more variables will slow down the initialization
process.
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.
Agreed?
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.

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.

However, the drawbacks of that style are that unused variables
tend to remain in the source code because they are declared
before needed.

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.
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.

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.