By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,426 Members | 2,928 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,426 IT Pros & Developers. It's quick & easy.

Javascript form help

P: n/a
I am just learning Javascript and I would like to create a basic form
that gives me two options. This will be using either checkbox or radio
input type, however I would like the second option to allow the user to
type in a value. Also, I would like the 2nd option only editable if
the button for that option is selected.

All I can seem to find is basic examples of forms, and none of which
have this feature. The form would look something like this:

@ = button

@ Option 1
@ Option 2 : [ box where user types in info ]

Anyone tried this before?

Jul 5 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
drec wrote:
I am just learning Javascript and I would like to create a basic form
that gives me two options. This will be using either checkbox or radio
input type, however I would like the second option to allow the user
to type in a value. Also, I would like the 2nd option only editable
if the button for that option is selected.

All I can seem to find is basic examples of forms, and none of which
have this feature. The form would look something like this:

@ = button

@ Option 1
@ Option 2 : [ box where user types in info ]

Anyone tried this before?
Something like this:

<input type="checkbox" id="b1" onclick="javascript:if (this.checked)
{getElementById('i1').style.display = 'block';} else
{getElementById('i1').style.display = 'none';}"/>
<input type="text" id="i1" style="display:none"/>
Jul 5 '06 #2

P: n/a
Paul Lautman said the following on 7/5/2006 3:44 PM:
drec wrote:
>I am just learning Javascript and I would like to create a basic form
that gives me two options. This will be using either checkbox or radio
input type, however I would like the second option to allow the user
to type in a value. Also, I would like the 2nd option only editable
if the button for that option is selected.

All I can seem to find is basic examples of forms, and none of which
have this feature. The form would look something like this:

@ = button

@ Option 1
@ Option 2 : [ box where user types in info ]

Anyone tried this before?

Something like this:
Not, not "something like this". Why try to hide/show a textbox and
rearrange the flow of the page, or leave it blank, instead of modifying
the readOnly attribute....

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jul 6 '06 #3

P: n/a
Randy Webb wrote:
Paul Lautman said the following on 7/5/2006 3:44 PM:
>drec wrote:
>>I am just learning Javascript and I would like to create a basic
form that gives me two options. This will be using either checkbox
or radio input type, however I would like the second option to
allow the user to type in a value. Also, I would like the 2nd
option only editable if the button for that option is selected.

All I can seem to find is basic examples of forms, and none of which
have this feature. The form would look something like this:

@ = button

@ Option 1
@ Option 2 : [ box where user types in info ]

Anyone tried this before?

Something like this:

Not, not "something like this". Why try to hide/show a textbox and
rearrange the flow of the page, or leave it blank, instead of
modifying the readOnly attribute....
Go stick your head in a pig! Why not something "like" this? This shows how
to influence the properties of a field based on the setting of a checkbox,
which was what the OP was asking for. Hopefully, once given the pointer to
the overall method, they can figure out how to change other properties. This
is how people (including me) learn how to do things for themselves. This was
a piece of code that I happened to have in an editor at the time that I saw
the original post. It at least gives some idea of how to influence the
properties of one element by the setting of another. Your post
contributes...not a lot, apart from showing how rude you can be.

For future reference a far better post would have been along the lines of:
################################################## ###################################
Or closer to what the OP asked for, you could put:
<input type="checkbox" id="b1" onclick="javascript:if (this.checked)
{getElementById('i1').readOnly = false;} else {getElementById('i1').readOnly
= true;}"/>
<input type="text" id="i1" READONLY/>
################################################## ###################################

Note how much more helpful such a post is.
Jul 6 '06 #4

P: n/a
Paul Lautman wrote:
Randy Webb wrote:
>Paul Lautman said the following on 7/5/2006 3:44 PM:
<snip>
>>Something like this:

Not, not "something like this". Why try to hide/show
a textbox and rearrange the flow of the page, or leave
it blank, instead of modifying the readOnly attribute....

Go stick your head in a pig! ... apart from showing how
rude you can be.

For future reference a far better post would have been
along the lines of:
################################################## #####
Or closer to what the OP asked for, you could put:
<input type="checkbox" id="b1" onclick="javascript:if
In javascript syntax the - javascript: - at the beginning of the onclick
attribute value represents a label, but as no - break - or continue -
statements (labelled or otherwise) appear in the code any label is
redundant. Microsoft have decided to use this construct to indicate
which scripting language should be used to interpret the intrinsic event
attribute value, but when used in this way no label exists in the
resulting code. The practical result of this is that - javascirpt: - is
dangerous to use as a label in an intrinsic event attribute value
because it will not be seen as such by IE browsers. However, as IE
browsers default to interpreting intrinsic event attributes as JScript
unless action is taken to change the default scripting language for a
page (i.e. another language is employed on the page first) there is
generally no point in attempting to express to IE that it needs to
interpret an intrinsic event attribute value in any special way.
(this.checked) {getElementById('i1').readOnly = false;} else
Using the unqualified Identifier - getElementById - in the value of an
intrinsic event handling attribute can only be successful in
environments where the - document - object is on the resulting
internally generated function's scope chain. This can only be the case
if the scope chains of such functions are explicitly augmented by the
browser. While it is not uncommon, such augmentation is not specified in
any standard, and so not required (so should not be expected outside of
known environments) and unlikely to be consistent where it is
implemented. In reality there a browsers that do not undertake such
augmentation and browsers that do but do not include the - document -
object on such scope chains. Thus using such an unqualified Identifier
will guarantee otherwise avoidable script failure in some environments;
it is non-reliable code used where a considerably more reliable
alternative is trivially available.

However, when form controls appear in a form element that is intended to
submit data to a server a reference from one intrinsic event handling
attribute value to another control in the same form is most reliably
achieved using the first control's - form - property, the elements -
collection of that form and the name of the control that is being
referenced:-

this.form.elements['otherFieldName']
{getElementById('i1').readOnly = true;}"/>
Testing a boolean value in order to branch into the assignment of one of
two boolean values is needlessly indirect. The same could be achieved
with:-

getElementById('i1').readOnly = !this.checked;

- or:-

this.form.elements['otherFieldName'].readOnly = !this.checked;
<input type="text" id="i1" READONLY/>
The penultimate slash above implies an attempt to write XHTML, but this
cannot be the case as XHTML uses case sensitive attribute names and the
read only attribute in XHTML is all lower case (and should be written
readonly="readonly"). In SGML such a penultimate slash (SGML application
languages where the SGML declaration asserts SHORTTAG YES (as is the
case with HTML 4)) changes the interpretation of the above into:-

<input type="text" id="i1" READONLY>&gt;

(implying a text chevron following the element).

Few browsers actually follow this requirement of SGML parsing when
interpreting HTML documents, ignoring the slash instead, but that does
not mean that it is a good idea to include such constructs in documents
that are expected to be interpreted as HTML. Doing so is likely to
introduce confusion in the minds of human readers as to which type of
mark-up is being employed (and in our context, which type of DOM is
being scripted as a result) and it will force an HTML browser to engage
in error-correction while interpreting the document (with potentially
inconstant results and inevitable overheads).
################################################## ######
Overall this design pattern promotes unreliable outcomes (regardless of
which property is used to 'disable' the field). We are dealing with a
minor GUI enhancement and it doesn't really matter if the ability to
enable/disable the field on the client is available as the server code
should be set up to ignore anything entered into the potentially
disabled field if the corresponding checkbox is not checked.
Enabling/disabling the field on the client just makes it more apparent
to the user that the checkbox selection relates to the field.

If the HTML loads with the field readonly, disabled or hidden and
client-side scripting is not capable of rendering it non-readonly,
enabled or visible then the field will remain unavailable to the user
even if the checkbox is checked, potentially rendering the entire form
non-viable as a mechanism for entering the required data. This is a bad
design choice, and potentially costly if the purpose of the form is
ultimately to enable the user to hand over their money.

A better strategy would load the form in a fully usable state and then
have a script render the field readonly, disabled or hidden (either
onload or following the parsing of the form element). This has the
advantage that whenever the script could not enable the field it will
also not be able to disable it with this initial action. The ability to
initially render the field unavailable implies the symmetrical ability
to later make it available again in response to interaction with the
checkbox, but when the script fails to initially act on the field the
result will not be an unusable form.
Note how much more helpful such a post is.
7% more helpful would be my judgement, but then I would consider the
overall effect about 75% harmful because of the issues I have enumerated
above.

Richard.
Jul 6 '06 #5

P: n/a
Richard Cornford wrote:
>lots of blah blah blah snipped
Richard.
Many of the constructs that you criticised were inserted by pressing the
appropriate buttons in HTML-Kit. This may not make them correct, but it is
how they were created in order to help the OP quickly.

Whilst very informative, your post lacked a clear set of lines stating
exactly how to do it (less is more).

I hadn't put the elements into a form as I was just testing approaches to
see what happened, otherwise I would have referenced the form object. When
someone asks how to do something, I try to point them into the right general
direction so that they can start to learn. I don't tend to write a complete
bullet proof web site.

The OP could copy the elements from my post and have something working to
play with in seconds. Picking the relevant stuff from your one would not be
so quick.

You seem to be suggesting that no one should attempt to help anyone on a
USENET newsgroup unless they are an acknowledged expert and have covered
every possible base before posting. Sorry to disappoint you but that isn't
the way this works. You wouldn't have enough time in your life to write full
critiques of every post that wasn't 100% the proper way to do things. This
doesn't stop them from being very helpful to others.

Imagine if every question resulted in a 1000 word essay on the dos and
don'ts. Nightmare!
Jul 6 '06 #6

P: n/a
Paul Lautman wrote:
Richard Cornford wrote:
>>lots of blah blah blah snipped
Richard.

Many of the constructs that you criticised were inserted
by pressing the appropriate buttons in HTML-Kit.
If those buttons produces mystical incantations, sub-optimal logic,
unreliable constructs and confused, non-standard mark-up, it is
questionable whether pressing them would ever be appropriate.
This may not make them correct,
It does not. It is unrealistic to suggest that poor code would become
any less poor as a result of being generated by a machine. Indeed being
generated by a machine is realistically expected to result in poor
javascript code, as a machine could never be expected apply more
knowledge to the decisions it makes than the person who programmed it
and whatever knowledge it could apply would not be intelligently
applied.

Most of the practical issues relating to browser scripting are questions
of script design. Machines will not be able to cope with those issues
until AI exists (at which point we are probably all out of work).
but it is how they were created in order to help
the OP quickly.
Helping the OP quickly (assuming the posted code represents 'help') and
the code being output by a machine does not abdicate you from being
responsible for posting it.
Whilst very informative, your post lacked a clear set of
lines stating exactly how to do it (less is more).
There is no reason why it should as it represented nothing but comments
on the shortcomings of the code you posted and the implemented design
pattern.
I hadn't put the elements into a form as I was just
testing approaches to see what happened, otherwise I
would have referenced the form object.
Using an ID to get a reference to a form element is an approach that is
only appropriate for the special (and unusual) case of from controls
that are not part of a form, while it is clear from the OP that subject
here was controls within a form.
When someone asks how to do something, I try to
point them into the right general direction
That is nice, but what makes you think you know what the right direction
is?
so that they can start to learn.
If you show someone irrelevant constructs, poor logic, unreliable and
inappropriate methods all used in an unreliable design what do you
expect would be learnt? With the sources of information on browser
scripting being predominantly bad one of the main barriers the novice
faces is identifying and unlearning much that should never have been
presented in the first place.
I don't tend to write a complete bullet proof web site.
Hmm.
The OP could copy the elements from my post and have
something working to play with in seconds.
And maybe weave its consequences through hundreds of lines of code, web
pages, etc. before finding out what makes it unreliable, inappropriate
and poorly designed.
Picking the relevant stuff from your
one would not be so quick.
Doing complex things well should not be expected to be instant.
You seem to be suggesting that no one should attempt to
help anyone on a USENET newsgroup unless they are an
acknowledged expert
I don't expect everyone who answers questions here to be experts, but I
do expect them to want to here their mistakes pointed out to them as it
is understanding and learning from their mistakes that will allow them
to avoid repeating them, and eventually turn them into experts.
and have covered every possible base before posting.
Covering every applicable possibility is a good thing. If the OPs
sufficiently narrow their context it is even relatively easy to know the
applicable possibilities. But even in the default Internet context some
possibilities are so obvious that dismissing them is irresponsible.
Sorry to disappoint you
but that isn't the way this works.
Isn't the way what works?
You wouldn't have enough time in your life to write full
critiques of every post that wasn't 100% the proper way
to do things.
No I would not, and neither would others so some criticisms or poor
responses are short general and glib.
This doesn't stop them from being very
helpful to others.
Full and detailed critiques can be very useful to others.
Imagine if every question resulted in a 1000 word essay
on the dos and don'ts.
Apart from the inevitable repletion, would that be such a bad thing.
There is little that promotes an understanding of a technical subject
better than detailed explanations, especially where there is a potential
for supplementary questions resulting in more clarification of the
details.
Nightmare!
So you don't like the idea of people providing informed explanations of
a very complex technical subject?

Richard.
Jul 6 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.