470,849 Members | 1,137 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,849 developers. It's quick & easy.

Getting values into a form: PHP (Server) or Javascript (Client) Side?

Hi

This is sort of a weird question, perhaps a bit off-topic...

I am on the 'edit' screen of a web form, and I have a bunch of variables
coming from a database that need to be placed into the form. In the
past, I have been using PHP to pre-populate each field, something like

<input type="text" id="firstName" value="<?= $first_name ?>" />

But, since my "add" and "edit" screens are virtually the same, I'm
thinking about using PHP to dynamically create "onload" javascript
events that use a custom function... essentially something along the
lines of

onload = "setForm('firstName','<?= $first_name ?>');"

So, option one hard-codes the form-field value directly into the HTML.
Option two uses javascript to populate the fields.

This is a specific web application targeted to a finite audience who
will be using javascript-enabled browsers. At this point, I'm thinking
of going with the second option(javascript based), because I won't have
to scroll down to each form-field tag in my document and add the "value"
parameter (read: time saver).... the only drawback I can see is CPU Power
I guess... Or is that a ridiculous concern? What about using Javascript
to populate 100 fields?

Most importantly, do I need to worry about client-side interruptions that
can prevent the form from being populated (other than turning javascript
off)?

Thoughts appreciated!
Mar 3 '06 #1
9 3850
Good Man wrote:
I am on the 'edit' screen of a web form, and I have a bunch of variables
coming from a database that need to be placed into the form. In the
past, I have been using PHP to pre-populate each field, something like

<input type="text" id="firstName" value="<?= $first_name ?>" />

But, since my "add" and "edit" screens are virtually the same, I'm
thinking about using PHP to dynamically create "onload" javascript
events that use a custom function... essentially something along the
lines of

onload = "setForm('firstName','<?= $first_name ?>');"

So, option one hard-codes the form-field value directly into the HTML.
Option two uses javascript to populate the fields.
Hardcode would be to use

<input type="text" id="firstName" value="John" />

directly in the page.

This is a specific web application targeted to a finite audience who
will be using javascript-enabled browsers. At this point, I'm thinking
of going with the second option(javascript based), because I won't have
to scroll down to each form-field tag in my document and add the "value"
parameter (read: time saver).... the only drawback I can see is CPU Power
I guess... Or is that a ridiculous concern? What about using Javascript
to populate 100 fields?
You just moved the process time from the server to the client, what can slow
things down is the size of the javascript, the more the more lagish the page
will be.

Most importantly, do I need to worry about client-side interruptions that
can prevent the form from being populated (other than turning javascript
off)?


I don't really see the point in using javascript at all in this case, you get
a more difficulty to figure out bugs.

if you use

<input type="text" id="firstName" value="<?= $first_name ?>" />
<input type="text" id="secondtName" value="<?= $second_name ?>" />
<input type="text" id="lastName" value="<?= $last_name ?>" />

You either have a value set of the variables $first_name, $second_name,
$last_name and so on (I know, I added the two last ones).

If a value isn't set, then the box will be empty and it's just to add the
values manually.
//Aho
Mar 3 '06 #2
"J.O. Aho" <us**@example.net> wrote in
news:46************@individual.net:

I don't really see the point in using javascript at all in this case,
you get a more difficulty to figure out bugs.

if you use

<input type="text" id="firstName" value="<?= $first_name ?>" />
<input type="text" id="secondtName" value="<?= $second_name ?>" />
<input type="text" id="lastName" value="<?= $last_name ?>" />

You either have a value set of the variables $first_name,
$second_name, $last_name and so on (I know, I added the two last
ones).

If a value isn't set, then the box will be empty and it's just to add
the values manually.


The only point would be saving me programming time. On a page with 50+
form-fields, I can save lot of time by writing a PHP loop that writes an
HTML call to a javscript function instead of going to each form field and
entering the value="<?= $first_name ?>" stuff...
Mar 3 '06 #3
d
"Good Man" <he***@letsgo.com> wrote in message
news:Xn************************@216.196.97.131...
"J.O. Aho" <us**@example.net> wrote in
news:46************@individual.net:

I don't really see the point in using javascript at all in this case,
you get a more difficulty to figure out bugs.

if you use

<input type="text" id="firstName" value="<?= $first_name ?>" />
<input type="text" id="secondtName" value="<?= $second_name ?>" />
<input type="text" id="lastName" value="<?= $last_name ?>" />

You either have a value set of the variables $first_name,
$second_name, $last_name and so on (I know, I added the two last
ones).

If a value isn't set, then the box will be empty and it's just to add
the values manually.


The only point would be saving me programming time. On a page with 50+
form-fields, I can save lot of time by writing a PHP loop that writes an
HTML call to a javscript function instead of going to each form field and
entering the value="<?= $first_name ?>" stuff...


May I suggest learning templates? They exist for just this sort of thing.
They take the edge off writing repetative pages. Either write your own
templating toolkit (better) or get one off the shelf.

Personally, I use javascript when it's a good idea to, and not when it isn't
:) For instance: a registration page. I'll use php to write the values
into the text fields (name, address, email, etc.), and a tiny line of
javascript to set the country in the drop-down (of 200+ entries). Storing
the list dynamically, and looping through it to set the right one to
"selected", is a lot more work than just getting the browser to do it.
Remember the browser has native code for manipulating HTML objects, whereas
PHP has native code for outputting HTML, and that's about it ;)

dave
Mar 3 '06 #4
"d" <d@example.com> wrote in
news:zm******************@text.news.blueyonder.co. uk:
The only point would be saving me programming time. On a page with
50+ form-fields, I can save lot of time by writing a PHP loop that
writes an HTML call to a javscript function instead of going to each
form field and entering the value="<?= $first_name ?>" stuff...


May I suggest learning templates? They exist for just this sort of
thing. They take the edge off writing repetative pages. Either write
your own templating toolkit (better) or get one off the shelf.


is this where the SMARTY thing comes into play? I've heard of it for a
long time but have never used it, as I generally prefer to code my
applications personally...

i think i'm still looking for a good reason NOT to use javascript to
populate my form fields, since I know that my audience is finite and
restricted to javascript-enabled browsers.... especially when my form has
50+ fields. it's too late to look at templating (ie: learning something
new) at this point in the project, but i will do it in the future.
thanks
Mar 3 '06 #5
d
"Good Man" <he***@letsgo.com> wrote in message
news:Xn************************@216.196.97.131...
"d" <d@example.com> wrote in
news:zm******************@text.news.blueyonder.co. uk:
The only point would be saving me programming time. On a page with
50+ form-fields, I can save lot of time by writing a PHP loop that
writes an HTML call to a javscript function instead of going to each
form field and entering the value="<?= $first_name ?>" stuff...
May I suggest learning templates? They exist for just this sort of
thing. They take the edge off writing repetative pages. Either write
your own templating toolkit (better) or get one off the shelf.


is this where the SMARTY thing comes into play? I've heard of it for a
long time but have never used it, as I generally prefer to code my
applications personally...


then write your own template toolkit :) It's not as hard as you'd imagine.
Mine is well under 200 lines, and that's got a lot of comments and
white-space. I prefer to write my own code as well ;)
i think i'm still looking for a good reason NOT to use javascript to
populate my form fields, since I know that my audience is finite and
restricted to javascript-enabled browsers.... especially when my form has
50+ fields. it's too late to look at templating (ie: learning something
new) at this point in the project, but i will do it in the future.
Of course - if you think it'll work, and if you're happy that your audience
can run it, then go for it :) just be aware that any errors in javascript
on the page will most likely result in the fields not being populated, and a
wee bit more processing power is required for each page (but nothing
drastic - barely noticeable).

use the javascript, and learn templating when you get a chance :)

thanks


cheers!

dave
Mar 3 '06 #6
Gazing into my crystal ball I observed Good Man <he***@letsgo.com>
writing in news:Xn************************@216.196.97.131:
The only point would be saving me programming time. On a page with 50+
form-fields, I can save lot of time by writing a PHP loop that writes
an HTML call to a javscript function instead of going to each form
field and entering the value="<?= $first_name ?>" stuff...


I do it a little differently. I have two arrays, one for the names/ids of
the fields, and one for the default values. If the request method is get,
then the array with the default values is used for the field values,
otherwise, the form array is used for the field values. I also use a
little javascript which sets the value to blank on focus of the field, but
it gives the user a default value. When I check for required fields, I can
loop through the default values array to be sure they are NOT using a
default, eg. name=Your Name.

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
Mar 3 '06 #7
Good Man wrote:
"J.O. Aho" <us**@example.net> wrote in
news:46************@individual.net:

I don't really see the point in using javascript at all in this case,
you get a more difficulty to figure out bugs.

if you use

<input type="text" id="firstName" value="<?= $first_name ?>" />
<input type="text" id="secondtName" value="<?= $second_name ?>" />
<input type="text" id="lastName" value="<?= $last_name ?>" />

You either have a value set of the variables $first_name,
$second_name, $last_name and so on (I know, I added the two last
ones).

If a value isn't set, then the box will be empty and it's just to add
the values manually.


The only point would be saving me programming time. On a page with 50+
form-fields, I can save lot of time by writing a PHP loop that writes an
HTML call to a javscript function instead of going to each form field and
entering the value="<?= $first_name ?>" stuff...


You have to add the input tag, so adding a little bit extra code don't make a
difference. You could even make a loop that does generate all the input tags
(makes your page even more dynamical), all you would need is id's in a array
(if you use the same name for the variables and the id's).
//Aho
Mar 3 '06 #8
Good Man wrote:
The only point would be saving me programming time. On a page with 50+
form-fields, I can save lot of time by writing a PHP loop that writes an
HTML call to a javscript function instead of going to each form field and
entering the value="<?= $first_name ?>" stuff...


I'd just paste the value="<?=$first_name?>" stuff in.

Personally, I never create an "Add" form -- only ever an "Edit" form.

When I need to create some "Add" functionality, I simply make a button
that adds a new blank record, then forwards the visitor to the "Edit" form
to edit the new blank record.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Mar 4 '06 #9
JDS
On Fri, 03 Mar 2006 10:13:04 -0600, Good Man wrote:
The only point would be saving me programming time.


That's what a good text editor is for.

You will just be adding programming time, in the long run, debugging what
amounts to TWO scripts in TWO different languages instead of just one
script in one language.

--
JDS | je*****@go.away.com
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

Mar 4 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Ken | last post: by
5 posts views Thread by Noorul Ameen | last post: by
6 posts views Thread by Janaka | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.