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

Is it possible to submit two forms at a time

P: n/a
Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>

Now is it possible to submit all the elements from the two form when I
click any one of the submit button.

Thanks & Regards
Moses

Feb 21 '07 #1
Share this Question
Share on Google+
23 Replies


P: n/a
Hello!

You can submit many forms at ones with javascript.
Use onsubmit action for create forms serialize array and send it.
On 21 ÆÅ×, 08:26, "mosesdinaka...@gmail.com"
<mosesdinaka...@gmail.comwrote:
Now is it possible to submit all the elements from the two form when I
click any one of the submit button.
Feb 21 '07 #2

P: n/a
mo************@gmail.com wrote:
Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>

Now is it possible to submit all the elements from the two form when I
click any one of the submit button.

Thanks & Regards
Moses
Hi,

Yes, but not with PHP.
PHP has NO KNOWLEDGE what is going on in the browser. It only sends the
html/javascript/images/whatever the browser displays.

So try Javascript, that language lives in a browser.
Note however that some people choose to have Javascript disabled in their
browser.

If you go Javascript, just add a bunch of hidden fields in both forms, and
fill them before submitting with the values from the other form.
If you need more help: comp.lang.javascript, an active group.

Regards,
Erwin Moller
Feb 21 '07 #3

P: n/a
mo************@gmail.com wrote:
Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>

Now is it possible to submit all the elements from the two form when I
click any one of the submit button.

Thanks & Regards
Moses
Moses,

As others have said, you can do it with javascript, but many users have
javascript disabled.

However, you have the same target on both forms - you don't need two
forms. You can do it with:

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" name="Submit" value="First Button" />

<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" name="Submit" value="Second Button" />
</form>

Notice you didn't have a name attribute for your submit button. I added
one so you can fetch the results. Now, in test.php, $_POST['Submit']
will contain "First Button" or "Second Button" and all fields will be
filled in. No javascript needed.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 21 '07 #4

P: n/a
Jerry Stuckle <js*******@attglobal.netwrote:
>
As others have said, you can do it with javascript, but many users have
javascript disabled.
Is that your opinion, or your experience? Seriously, I am curious to know
your basis for saying this, because my experience is quite the opposite:
the vast majority of users run with Javascript enabled, and the typical web
surfing experience is severly reduce without it.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Feb 22 '07 #5

P: n/a
Rik
On Thu, 22 Feb 2007 06:13:14 +0100, Tim Roberts <ti**@probo.comwrote:
Jerry Stuckle <js*******@attglobal.netwrote:
>>
As others have said, you can do it with javascript, but many users have
javascript disabled.

Is that your opinion, or your experience? Seriously, I am curious to
know
your basis for saying this, because my experience is quite the opposite:
the vast majority of users run with Javascript enabled, and the typical
web
surfing experience is severly reduce without it.
It all depends on you audience offcourse. A corporate for mainly business
to business communication will have a lot more users with javascript
turned off, no Flash etc, while a you typical community website for teens
or something will have the vast majority with the whole shebang enabled.
The question wether that 'the typical web surfing experience is severly
reduced without it' all depends on the surfer, there is no 'typical'
internet user. Usually, when it does break, it because of bad design, not
because it's impossible to get the functionality without it.

Fact is, that everything the users sees must work in one way or another.
The users can see the forms without javascript, so they should be able to
use them without javascript too. There's no problem in added functionality
for the people with javascript, often you can skip a few forms, procide
better feedback etc. It's all about a gracefull degrade.

Then again, for this particular example, maybe the OP should state _why_
the 2 forms are needed. It's hardly ever necessary to use 2 forms like
this that have to be submitted as one. Could be that's more a HTML/design
question though.
--
Rik Wasmus
Feb 22 '07 #6

P: n/a
mo************@gmail.com kirjoitti:
Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>

Now is it possible to submit all the elements from the two form when I
click any one of the submit button.
I see absolutely no reason for having two forms. You want to post all
values but possibly handle different actions based on which button was
clcikced, so a clean, non-javascript solution would be just put them all
in the same form and test at server-side which button was clicked if it
matters.

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" name="submit" value="Submit" />
<br />
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" name="submit1" value="Submit" />
</form>

test.php:

if(isset($_POST['submit'])){

// Handle the case where the first button was clicked

}

if(isset($_POST['submit1'])){

// Handle the case where the second button was clicked

}

if(sizeof($_POST)){

// Handle the case where it doesn't matter what was clicked.

}

If you do it like this, then it's accessible for them javascriptless
folk too. Ignorance is not a reason to create obstacles.

--
"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirviö
sp**@outolempi.net | Gedoon-S @ IRCnet | rot13(xv***@bhgbyrzcv.arg)
Feb 22 '07 #7

P: n/a
Tim Roberts wrote:
Jerry Stuckle <js*******@attglobal.netwrote:
>As others have said, you can do it with javascript, but many users have
javascript disabled.

Is that your opinion, or your experience? Seriously, I am curious to know
your basis for saying this, because my experience is quite the opposite:
the vast majority of users run with Javascript enabled, and the typical web
surfing experience is severly reduce without it.
Tim,

It's my experience.

As Rik indicated, it depends on the audience. But more and more people
are running with it turned off every day, mainly because a few
webmasters misuse it so much (i.e. creating popups).

Any website which uses javascript should have a non-javascript solution,
also. I admit it's not always possible - but then you should be using
the <NOSCRIPTtag - and in this case not show the form.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 22 '07 #8

P: n/a
Kimmo Laine kirjoitti:
mo************@gmail.com kirjoitti:
>Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>
Okay, now I noticed Jerry already replied the almost-same answer already
and here I'm repeating it. What a silly bunt. Well at least the correct
answer was already given. I just read the couple of first answers and
every time someone recommends a javascript "solution" I jump to the roof. :D

--
"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirviö
sp**@outolempi.net | Gedoon-S @ IRCnet | rot13(xv***@bhgbyrzcv.arg)
Feb 22 '07 #9

P: n/a
Kimmo Laine wrote:
Kimmo Laine kirjoitti:
>mo************@gmail.com kirjoitti:
>>Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>

Okay, now I noticed Jerry already replied the almost-same answer already
and here I'm repeating it. What a silly bunt. Well at least the correct
answer was already given. I just read the couple of first answers and
every time someone recommends a javascript "solution" I jump to the
roof. :D
Hey, Kimmo, you were a minute ahead of me in posting! :-)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 23 '07 #10

P: n/a
Hi Everybody,

Than you very much for all your replys,

In this project we have used javascript for lot of things, so I
am sure the user should enable javascript .

So I have decided to go with javascript.

But I have understood that we should not rely on javascript and
also trying to avoid having more than one form in the future.

Once again thank you every body.
Regards
Moses
Feb 23 '07 #11

P: n/a
Kimmo Laine wrote:
Kimmo Laine kirjoitti:
>mo************@gmail.com kirjoitti:
>>Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>

Okay, now I noticed Jerry already replied the almost-same answer already
and here I'm repeating it. What a silly bunt. Well at least the correct
answer was already given. I just read the couple of first answers and
every time someone recommends a javascript "solution" I jump to the roof.
:D
Hi Kimmo,

-- The Javascript 'solution' poster speaking. ;-)

Kimmo, I would really like to see your solution to the original problem (2
forms!) without using Javascript.
It is simply not possible.
Allthough I also wonder why th OP wants 2 forms. As far as I can judge 1
form will do just fine, but I don't know the problem at hand (and neither
do you!).

In defense for javascript: My *personal experience* is that a lot of my
customers prefer the sexy behaviour a site gets with javascript above
better compatibility (= JS disabled).
Also: It takes a lot more developmenttime in realworld situation to make a
'double site': one for JS enabled, one for disabled. And not all want to
pay for that, and settle for JS only site.
I simple say at the homepage/entrancepage that JS must be enabled to use the
site.
Of course, a website that handles both situations right is better than one
that demands JS.

An example (a thing I am working on right now):
I need a geograpical map of some area with lots of regions in it.
The user clicks on one region and I must select the neighbouring regions:
they light up.
Another selectbox defines how deep the neighbours are found (eg 0, 1, 2,
etc).
If I must deliver that piece without JS, I need a roundrobin to the server
for each click, rebuild the map with the right regions lighted up: quite
slow and it will result in a sluggish enduserexperience.
This is just an example of realworld situations I do want to program/deliver
without JS.

One a sidenote: What is so bad about demanding JS for your site? People
demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
I have no problems with it. :-/

just my 2 cent.

Regards,
Erwin Moller
Feb 23 '07 #12

P: n/a
Erwin Moller wrote:
Kimmo Laine wrote:
>Kimmo Laine kirjoitti:
>>mo************@gmail.com kirjoitti:
Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>
Okay, now I noticed Jerry already replied the almost-same answer already
and here I'm repeating it. What a silly bunt. Well at least the correct
answer was already given. I just read the couple of first answers and
every time someone recommends a javascript "solution" I jump to the roof.
:D

Hi Kimmo,

-- The Javascript 'solution' poster speaking. ;-)

Kimmo, I would really like to see your solution to the original problem (2
forms!) without using Javascript.
It is simply not possible.
Allthough I also wonder why th OP wants 2 forms. As far as I can judge 1
form will do just fine, but I don't know the problem at hand (and neither
do you!).

In defense for javascript: My *personal experience* is that a lot of my
customers prefer the sexy behaviour a site gets with javascript above
better compatibility (= JS disabled).
Also: It takes a lot more developmenttime in realworld situation to make a
'double site': one for JS enabled, one for disabled. And not all want to
pay for that, and settle for JS only site.
You don't need to have two sites. JS should enhance a page - but not be
required to use it.
I simple say at the homepage/entrancepage that JS must be enabled to use the
site.
Of course, a website that handles both situations right is better than one
that demands JS.
And therein lies the problem. How many people leave after seeing your
home page without going any further? Every one of them who run with JS
turned off. So obviously, since you only see those who have javascript
disabled, your conclusion is that most people have JS enabled.
An example (a thing I am working on right now):
I need a geograpical map of some area with lots of regions in it.
The user clicks on one region and I must select the neighbouring regions:
they light up.
Another selectbox defines how deep the neighbours are found (eg 0, 1, 2,
etc).
If I must deliver that piece without JS, I need a roundrobin to the server
for each click, rebuild the map with the right regions lighted up: quite
slow and it will result in a sluggish enduserexperience.
This is just an example of realworld situations I do want to program/deliver
without JS.
Yes, it requires a request to the server. but it should not be "slow"
and should not result in a sluggish end user experience".
One a sidenote: What is so bad about demanding JS for your site? People
demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
I have no problems with it. :-/
Because you lose customers that way. Every one who surfs with
javascript turned off. And you never see them go.
just my 2 cent.

Regards,
Erwin Moller

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 23 '07 #13

P: n/a
Jerry Stuckle wrote:

<snip>
>Hi Kimmo,

-- The Javascript 'solution' poster speaking. ;-)

Kimmo, I would really like to see your solution to the original problem
(2 forms!) without using Javascript.
It is simply not possible.
Allthough I also wonder why th OP wants 2 forms. As far as I can judge 1
form will do just fine, but I don't know the problem at hand (and neither
do you!).

In defense for javascript: My *personal experience* is that a lot of my
customers prefer the sexy behaviour a site gets with javascript above
better compatibility (= JS disabled).
Also: It takes a lot more developmenttime in realworld situation to make
a 'double site': one for JS enabled, one for disabled. And not all want
to pay for that, and settle for JS only site.

You don't need to have two sites. JS should enhance a page - but not be
required to use it.
Hi Jerry,

Of course you don't need 2 seperate sites.
I know that. I I think you know I know. :-)
That is why I wrote 'double site' between the ''.
My point is simply that making sites work in both situations can take a lot
more effort in some situations.
And I am not refering to trivial checks like somebody filled in a certain
field in a form. That is a breeze of course, and should be checked
serverside anyway.

>
>I simple say at the homepage/entrancepage that JS must be enabled to use
the site.
Of course, a website that handles both situations right is better than
one that demands JS.

And therein lies the problem. How many people leave after seeing your
home page without going any further? Every one of them who run with JS
turned off. So obviously, since you only see those who have javascript
disabled, your conclusion is that most people have JS enabled.
???
Where did I say I concluded that most people have JS enabled based on my
visitors? You put words in my mouth/writing.

I DO think that by the way, I just didn't say it. Maybe you are confusing
posters. :-)
>
>An example (a thing I am working on right now):
I need a geograpical map of some area with lots of regions in it.
The user clicks on one region and I must select the neighbouring regions:
they light up.
Another selectbox defines how deep the neighbours are found (eg 0, 1, 2,
etc).
If I must deliver that piece without JS, I need a roundrobin to the
server for each click, rebuild the map with the right regions lighted up:
quite slow and it will result in a sluggish enduserexperience.
This is just an example of realworld situations I do want to
program/deliver without JS.

Yes, it requires a request to the server. but it should not be "slow"
and should not result in a sluggish end user experience".
Not?
Not if the map exists of 200+ images that the browser has to layout every
time after every click?
Of course that will be sluggish compared to Javascript switching a few
images, and you know that just as well as I do. Or I am misjudging your
competence completely.

>
>One a sidenote: What is so bad about demanding JS for your site? People
demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
I have no problems with it. :-/

Because you lose customers that way. Every one who surfs with
javascript turned off. And you never see them go.
Loose customers?
I loose MY customers if I present them bills for fully compatible sites
(JS/no JS, Java/No Java, Flash/no Flash, etc).

Well Jerry, as I said: I don't mind making apps 100% non-JS compatible. But
I must raise my bill because it results in more coding/thinking and in some
situations a lot of double work.
Of course I prefer a site that handles both situations....
And the situation flas/no flash.
And the situation Java/no Java.
Go on and do the math. My bills will grow.

I think you are describing some 'ideal world' solution, while I tried to
describe real world situations that run on tight budgets.
I do not know how you are employed, but I run my own business and simply do
not have the luxery to make perfect apps day-in-day-out, allthough I would
like that.

And for clearity's sake: I DO agree that sites that handle JS and no-JS are
better.

Regards,
Erwin Moller
>
>just my 2 cent.

Regards,
Erwin Moller

Feb 23 '07 #14

P: n/a
Erwin Moller wrote:
Jerry Stuckle wrote:

<snip>
>>>
In defense for javascript: My *personal experience* is that a lot of my
customers prefer the sexy behaviour a site gets with javascript above
better compatibility (= JS disabled).
Also: It takes a lot more developmenttime in realworld situation to make
a 'double site': one for JS enabled, one for disabled. And not all want
to pay for that, and settle for JS only site.
You don't need to have two sites. JS should enhance a page - but not be
required to use it.

Hi Jerry,

Of course you don't need 2 seperate sites.
I know that. I I think you know I know. :-)
That is why I wrote 'double site' between the ''.
My point is simply that making sites work in both situations can take a lot
more effort in some situations.
And I am not refering to trivial checks like somebody filled in a certain
field in a form. That is a breeze of course, and should be checked
serverside anyway.
But a lot of people would take "double site" to mean two separate copies
of each page - one with JS enabled and one without.
>
>>I simple say at the homepage/entrancepage that JS must be enabled to use
the site.
Of course, a website that handles both situations right is better than
one that demands JS.
And therein lies the problem. How many people leave after seeing your
home page without going any further? Every one of them who run with JS
turned off. So obviously, since you only see those who have javascript
disabled, your conclusion is that most people have JS enabled.

???
Where did I say I concluded that most people have JS enabled based on my
visitors? You put words in my mouth/writing.

I DO think that by the way, I just didn't say it. Maybe you are confusing
posters. :-)
No, you didn't state it here. But it's a logical conclusion from other
comments you've made and the fact you don't push it with your customers.
But it's also an obvious conclusion to make when you never see the
non-JS users.

There isn't anything wrong with this opinion, Erwin. And for your
customer base it may be 100% correct. But do you think it might also be
based on incomplete information?
>>An example (a thing I am working on right now):
I need a geograpical map of some area with lots of regions in it.
The user clicks on one region and I must select the neighbouring regions:
they light up.
Another selectbox defines how deep the neighbours are found (eg 0, 1, 2,
etc).
If I must deliver that piece without JS, I need a roundrobin to the
server for each click, rebuild the map with the right regions lighted up:
quite slow and it will result in a sluggish enduserexperience.
This is just an example of realworld situations I do want to
program/deliver without JS.
Yes, it requires a request to the server. but it should not be "slow"
and should not result in a sluggish end user experience".

Not?
Not if the map exists of 200+ images that the browser has to layout every
time after every click?
Of course that will be sluggish compared to Javascript switching a few
images, and you know that just as well as I do. Or I am misjudging your
competence completely.
First of all, most of those images would already be cached by the
browser and wouldn't need to be fetched from the server.

But it also means you need to send two copies of every image for the JS
version, whether or not you'll even need them (and chances are you won't
need all of them - maybe not even a large percentage of the copies).

So your first page is going to be twice as slow loading because it has
to load all of those images which probably won't be used.

So a good compromise in this case would be to have JS load the copies
and handle the image switches. And if JS isn't active, don't load the
extra copies and make the trip to the server.

That way JS is enhancing the experience, but the experience doesn't
require JS.
>
>>One a sidenote: What is so bad about demanding JS for your site? People
demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
I have no problems with it. :-/
Because you lose customers that way. Every one who surfs with
javascript turned off. And you never see them go.

Loose customers?
I loose MY customers if I present them bills for fully compatible sites
(JS/no JS, Java/No Java, Flash/no Flash, etc).
I'm talking about THEIR customers. I don't lose customers because I can
show them how not being compatible would lose them money. Most are
quite happy to pay for non-JS versions when they understand requiring JS
can cost them more in lost sales than the cost of implementing the solution.
Well Jerry, as I said: I don't mind making apps 100% non-JS compatible. But
I must raise my bill because it results in more coding/thinking and in some
situations a lot of double work.
Of course I prefer a site that handles both situations....
And the situation flas/no flash.
And the situation Java/no Java.
Go on and do the math. My bills will grow.

I think you are describing some 'ideal world' solution, while I tried to
describe real world situations that run on tight budgets.
I do not know how you are employed, but I run my own business and simply do
not have the luxery to make perfect apps day-in-day-out, allthough I would
like that.
No, not "ideal world". The way I work. I run my own business, also
(have for over 16 years, now). I don't make 'perfect' apps. But at the
same time I show my customers the real world. And BTW - I don't do
flash at all - too "graphically challenged" :-). But I have someone who
can do the flash if I need it. And I don't do client-side Java unless
there is a very good reason for it. Most sites obviously don't need it.

In an "ideal world" you could require JS/Flash/Java and anything else
and not lose any potential customers. In the "real world", though,
doing any of these will lose you potential customers. The only question
is which will cost you more money in the long run - the loss of
customers by requiring these technologies, or the cost of implementing
non-JS/Java/Flash version.

It's a trade-off, and details will be different for each site. But for
my customers the extra up front cost would be recovered by just a few
sales.

And for clearity's sake: I DO agree that sites that handle JS and no-JS are
better.

Regards,
Erwin Moller
>>just my 2 cent.

Regards,
Erwin Moller
Another example here. I'm working on a site with dropdowns for country
and state/province. When the country changes, the state/province
contents change (or it is disabled).

Obviously this requires javascript and there's no way to do it with
javascript disabled. So I set it up such that all entries are placed in
the state/province block. When JS is enabled, it replaces the content
with an accurate list (or disables it completely). But if JS is
disabled, the state/province block shows all entries. Either way there
needs to be further validation server side. But again, JS "enhances the
experience".

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 23 '07 #15

P: n/a
Message-ID: <CM******************************@comcast.comfro m Jerry
Stuckle contained the following:
>But again, JS "enhances the
experience".
It's funny how threads pop up when you have just been working on
something.

I had an admin form with a list of records in text fields for editing.
My client wanted the choice of editing or deleting individual records so
I added a checkbox with name=' chosen[]' value='$id' and so on. Press
one button and the selected records would be updated, press another and
the chosen records get sent to a delete script.

Then I had the bright idea that the checkbox should be checked if the
text was edited to 'enhance the experience' using an onChange event.
Ok, to do that each check box would have to have a different name so I
did
name=' chosen[$id]' value='$id'

After much head scratching and cursing of JavaScript I discovered that
while php is happy with square brackets, Javascript isn't. I eventually
had to name it name=' chosen$id' value='$id'

But that meant I would no longer have my array of ids. :-(

So I did this:

foreach ($_POST as $key=>$value){
if(substr($key,0,6)=='chosen'){
$change[]=$value;
}
}

Hope this helps someone stop scratching their head as much as I did.

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/
Feb 23 '07 #16

P: n/a
Jerry Stuckle wrote:
Erwin Moller wrote:
>Jerry Stuckle wrote:

<snip>
>>>>
In defense for javascript: My *personal experience* is that a lot of my
customers prefer the sexy behaviour a site gets with javascript above
better compatibility (= JS disabled).
Also: It takes a lot more developmenttime in realworld situation to
make a 'double site': one for JS enabled, one for disabled. And not all
want to pay for that, and settle for JS only site.
You don't need to have two sites. JS should enhance a page - but not be
required to use it.

Hi Jerry,

Of course you don't need 2 seperate sites.
I know that. I I think you know I know. :-)
That is why I wrote 'double site' between the ''.
My point is simply that making sites work in both situations can take a
lot more effort in some situations.
And I am not refering to trivial checks like somebody filled in a certain
field in a form. That is a breeze of course, and should be checked
serverside anyway.

But a lot of people would take "double site" to mean two separate copies
of each page - one with JS enabled and one without.
My bad.
That happens when Dutch guys think they mastered english enough. ;-)

>
>>
>>>I simple say at the homepage/entrancepage that JS must be enabled to
use the site.
Of course, a website that handles both situations right is better than
one that demands JS.

And therein lies the problem. How many people leave after seeing your
home page without going any further? Every one of them who run with JS
turned off. So obviously, since you only see those who have javascript
disabled, your conclusion is that most people have JS enabled.

???
Where did I say I concluded that most people have JS enabled based on my
visitors? You put words in my mouth/writing.

I DO think that by the way, I just didn't say it. Maybe you are confusing
posters. :-)

No, you didn't state it here. But it's a logical conclusion from other
comments you've made and the fact you don't push it with your customers.
But it's also an obvious conclusion to make when you never see the
non-JS users.

There isn't anything wrong with this opinion, Erwin. And for your
customer base it may be 100% correct. But do you think it might also be
based on incomplete information?
To be honest, I am unsure.
Last numbers I saw (w3schools) says 6% is JS challenged.
But I admid I have no clue how reliable that numbers are.

By the way: I cannot reach www.thecounter.com anymore. They used to serve
good statistics if memory serves me well.
Does anybody know what happened with them? Paying clients only?

Still, from a (business) clients point of view 6% missed customers can or
cannot be acceptable (pricewise).
Very roughly speaking: I think the price for sites I build rises by 10-20%
on most projects I work on to make them work in both situations.
Mostly because of double work.

>
>>>An example (a thing I am working on right now):
I need a geograpical map of some area with lots of regions in it.
The user clicks on one region and I must select the neighbouring
regions: they light up.
Another selectbox defines how deep the neighbours are found (eg 0, 1,
2, etc).
If I must deliver that piece without JS, I need a roundrobin to the
server for each click, rebuild the map with the right regions lighted
up: quite slow and it will result in a sluggish enduserexperience.
This is just an example of realworld situations I do want to
program/deliver without JS.

Yes, it requires a request to the server. but it should not be "slow"
and should not result in a sluggish end user experience".

Not?
Not if the map exists of 200+ images that the browser has to layout every
time after every click?
Of course that will be sluggish compared to Javascript switching a few
images, and you know that just as well as I do. Or I am misjudging your
competence completely.

First of all, most of those images would already be cached by the
browser and wouldn't need to be fetched from the server.

But it also means you need to send two copies of every image for the JS
version, whether or not you'll even need them (and chances are you won't
need all of them - maybe not even a large percentage of the copies).

So your first page is going to be twice as slow loading because it has
to load all of those images which probably won't be used.
True.
But after one click JS wins performancewise.
Slower to build the first time, faster after one click.
>
So a good compromise in this case would be to have JS load the copies
and handle the image switches. And if JS isn't active, don't load the
extra copies and make the trip to the server.

That way JS is enhancing the experience, but the experience doesn't
require JS.
True.
I am merely trying to get the point across that I have to make the routines
in HTML/JS AND in PHP serverside.
More work, higher bill.
>
>>
>>>One a sidenote: What is so bad about demanding JS for your site? People
demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
I have no problems with it. :-/

Because you lose customers that way. Every one who surfs with
javascript turned off. And you never see them go.

Loose customers?
I loose MY customers if I present them bills for fully compatible sites
(JS/no JS, Java/No Java, Flash/no Flash, etc).

I'm talking about THEIR customers. I don't lose customers because I can
show them how not being compatible would lose them money. Most are
quite happy to pay for non-JS versions when they understand requiring JS
can cost them more in lost sales than the cost of implementing the
solution.
Just curious, roughly speaking, how much more work do you guess you need to
make your app work nicely with and without JS? (I estimated that in my case
around 10-20%)

>
>Well Jerry, as I said: I don't mind making apps 100% non-JS compatible.
But I must raise my bill because it results in more coding/thinking and
in some situations a lot of double work.
Of course I prefer a site that handles both situations....
And the situation flas/no flash.
And the situation Java/no Java.
Go on and do the math. My bills will grow.

I think you are describing some 'ideal world' solution, while I tried to
describe real world situations that run on tight budgets.
I do not know how you are employed, but I run my own business and simply
do not have the luxery to make perfect apps day-in-day-out, allthough I
would like that.

No, not "ideal world". The way I work. I run my own business, also
(have for over 16 years, now). I don't make 'perfect' apps. But at the
same time I show my customers the real world. And BTW - I don't do
flash at all - too "graphically challenged" :-). But I have someone who
can do the flash if I need it. And I don't do client-side Java unless
there is a very good reason for it. Most sites obviously don't need it.
True.
I also seldom use Java clientside these days. (I used to love it, but since
Javascript became more powerfull, and I could develop a lot fatser in
JS...)

>
In an "ideal world" you could require JS/Flash/Java and anything else
and not lose any potential customers. In the "real world", though,
doing any of these will lose you potential customers. The only question
is which will cost you more money in the long run - the loss of
customers by requiring these technologies, or the cost of implementing
non-JS/Java/Flash version.
Yes, that is the question.
And the answer depends on the type of customer indeed.
I do a lot of start-ups (people who just start their business and need
online help), and lots of them are very pennywise, but poundfoolish.
In case their business runs smoothly, they DO have the money to upgrade/fix
annoying stuff on their site. :-)

>
It's a trade-off, and details will be different for each site. But for
my customers the extra up front cost would be recovered by just a few
sales.
You don't charge them enough Jerry! ;-)
>
Another example here. I'm working on a site with dropdowns for country
and state/province. When the country changes, the state/province
contents change (or it is disabled).

Obviously this requires javascript and there's no way to do it with
javascript disabled. So I set it up such that all entries are placed in
the state/province block. When JS is enabled, it replaces the content
with an accurate list (or disables it completely). But if JS is
disabled, the state/province block shows all entries. Either way there
needs to be further validation server side. But again, JS "enhances the
experience".
Yes, that's the right way to do it: replace the content of some div or
something like that.
No discussion there. :-)

Happy coding.

Regards,
Erwin Moller
Feb 23 '07 #17

P: n/a
Geoff Berrow wrote:
Message-ID: <CM******************************@comcast.comfro m Jerry
Stuckle contained the following:
>But again, JS "enhances the
experience".

It's funny how threads pop up when you have just been working on
something.

I had an admin form with a list of records in text fields for editing.
My client wanted the choice of editing or deleting individual records so
I added a checkbox with name=' chosen[]' value='$id' and so on. Press
one button and the selected records would be updated, press another and
the chosen records get sent to a delete script.

Then I had the bright idea that the checkbox should be checked if the
text was edited to 'enhance the experience' using an onChange event.
Ok, to do that each check box would have to have a different name so I
did
name=' chosen[$id]' value='$id'

After much head scratching and cursing of JavaScript I discovered that
while php is happy with square brackets, Javascript isn't. I eventually
had to name it name=' chosen$id' value='$id'

But that meant I would no longer have my array of ids. :-(

So I did this:

foreach ($_POST as $key=>$value){
if(substr($key,0,6)=='chosen'){
$change[]=$value;
}
}

Hope this helps someone stop scratching their head as much as I did.
Hi, Geoff,

An even easier way:

name=' chosen[$id]' value='$id' id='chosen{$id}

And in your Javascript use:

document.getElementById(chosen{$id})

That way both Javascript and PHP are happy.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 23 '07 #18

P: n/a
Erwin Moller wrote:
Jerry Stuckle wrote:
>Erwin Moller wrote:
>>Jerry Stuckle wrote:

<snip>
In defense for javascript: My *personal experience* is that a lot of my
customers prefer the sexy behaviour a site gets with javascript above
better compatibility (= JS disabled).
Also: It takes a lot more developmenttime in realworld situation to
make a 'double site': one for JS enabled, one for disabled. And not all
want to pay for that, and settle for JS only site.
You don't need to have two sites. JS should enhance a page - but not be
required to use it.
Hi Jerry,

Of course you don't need 2 seperate sites.
I know that. I I think you know I know. :-)
That is why I wrote 'double site' between the ''.
My point is simply that making sites work in both situations can take a
lot more effort in some situations.
And I am not refering to trivial checks like somebody filled in a certain
field in a form. That is a breeze of course, and should be checked
serverside anyway.
But a lot of people would take "double site" to mean two separate copies
of each page - one with JS enabled and one without.

My bad.
That happens when Dutch guys think they mastered english enough. ;-)
Understandable. But you wouldn't want to hear my try at Dutch! :-)
>
>>>>I simple say at the homepage/entrancepage that JS must be enabled to
use the site.
Of course, a website that handles both situations right is better than
one that demands JS.
>
And therein lies the problem. How many people leave after seeing your
home page without going any further? Every one of them who run with JS
turned off. So obviously, since you only see those who have javascript
disabled, your conclusion is that most people have JS enabled.
???
Where did I say I concluded that most people have JS enabled based on my
visitors? You put words in my mouth/writing.

I DO think that by the way, I just didn't say it. Maybe you are confusing
posters. :-)
No, you didn't state it here. But it's a logical conclusion from other
comments you've made and the fact you don't push it with your customers.
But it's also an obvious conclusion to make when you never see the
non-JS users.

There isn't anything wrong with this opinion, Erwin. And for your
customer base it may be 100% correct. But do you think it might also be
based on incomplete information?

To be honest, I am unsure.
Last numbers I saw (w3schools) says 6% is JS challenged.
But I admid I have no clue how reliable that numbers are.
Me, neither. And it depends a lot on the target audience.
By the way: I cannot reach www.thecounter.com anymore. They used to serve
good statistics if memory serves me well.
Does anybody know what happened with them? Paying clients only?
I can still get it here.

Still, from a (business) clients point of view 6% missed customers can or
cannot be acceptable (pricewise).
Very roughly speaking: I think the price for sites I build rises by 10-20%
on most projects I work on to make them work in both situations.
Mostly because of double work.
Yes, it is more work. But things like validation (as you pointed out
earlier) can be done on the client side - but must be done on the server
end, also. And yes, 10-20% is about right, in my experience.
>
>>>>An example (a thing I am working on right now):
I need a geograpical map of some area with lots of regions in it.
The user clicks on one region and I must select the neighbouring
regions: they light up.
Another selectbox defines how deep the neighbours are found (eg 0, 1,
2, etc).
If I must deliver that piece without JS, I need a roundrobin to the
server for each click, rebuild the map with the right regions lighted
up: quite slow and it will result in a sluggish enduserexperience.
This is just an example of realworld situations I do want to
program/deliver without JS.
>
Yes, it requires a request to the server. but it should not be "slow"
and should not result in a sluggish end user experience".
Not?
Not if the map exists of 200+ images that the browser has to layout every
time after every click?
Of course that will be sluggish compared to Javascript switching a few
images, and you know that just as well as I do. Or I am misjudging your
competence completely.
First of all, most of those images would already be cached by the
browser and wouldn't need to be fetched from the server.

But it also means you need to send two copies of every image for the JS
version, whether or not you'll even need them (and chances are you won't
need all of them - maybe not even a large percentage of the copies).

So your first page is going to be twice as slow loading because it has
to load all of those images which probably won't be used.

True.
But after one click JS wins performancewise.
Slower to build the first time, faster after one click.
>So a good compromise in this case would be to have JS load the copies
and handle the image switches. And if JS isn't active, don't load the
extra copies and make the trip to the server.

That way JS is enhancing the experience, but the experience doesn't
require JS.

True.
I am merely trying to get the point across that I have to make the routines
in HTML/JS AND in PHP serverside.
More work, higher bill.
Yep, and fewer lost potential customers.
>>>>One a sidenote: What is so bad about demanding JS for your site? People
demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
I have no problems with it. :-/
>
Because you lose customers that way. Every one who surfs with
javascript turned off. And you never see them go.
Loose customers?
I loose MY customers if I present them bills for fully compatible sites
(JS/no JS, Java/No Java, Flash/no Flash, etc).
I'm talking about THEIR customers. I don't lose customers because I can
show them how not being compatible would lose them money. Most are
quite happy to pay for non-JS versions when they understand requiring JS
can cost them more in lost sales than the cost of implementing the
solution.

Just curious, roughly speaking, how much more work do you guess you need to
make your app work nicely with and without JS? (I estimated that in my case
around 10-20%)
About the same here. It depends a lot on the site.
>
>>Well Jerry, as I said: I don't mind making apps 100% non-JS compatible.
But I must raise my bill because it results in more coding/thinking and
in some situations a lot of double work.
Of course I prefer a site that handles both situations....
And the situation flas/no flash.
And the situation Java/no Java.
Go on and do the math. My bills will grow.

I think you are describing some 'ideal world' solution, while I tried to
describe real world situations that run on tight budgets.
I do not know how you are employed, but I run my own business and simply
do not have the luxery to make perfect apps day-in-day-out, allthough I
would like that.
No, not "ideal world". The way I work. I run my own business, also
(have for over 16 years, now). I don't make 'perfect' apps. But at the
same time I show my customers the real world. And BTW - I don't do
flash at all - too "graphically challenged" :-). But I have someone who
can do the flash if I need it. And I don't do client-side Java unless
there is a very good reason for it. Most sites obviously don't need it.

True.
I also seldom use Java clientside these days. (I used to love it, but since
Javascript became more powerfull, and I could develop a lot fatser in
JS...)
I still do some server side Java - it's nice if you get it on a fast
server. But Java can be a resource hog, and many clients it would run
unacceptably slow, especially when you're targeting consumers (who are
more likely to be speed and/or memory constrained).
>
>In an "ideal world" you could require JS/Flash/Java and anything else
and not lose any potential customers. In the "real world", though,
doing any of these will lose you potential customers. The only question
is which will cost you more money in the long run - the loss of
customers by requiring these technologies, or the cost of implementing
non-JS/Java/Flash version.

Yes, that is the question.
And the answer depends on the type of customer indeed.
I do a lot of start-ups (people who just start their business and need
online help), and lots of them are very pennywise, but poundfoolish.
In case their business runs smoothly, they DO have the money to upgrade/fix
annoying stuff on their site. :-)
Yes, I see that, also. But that's where I explain to them how they can
lose customers because of it. If the have any brains at all, they think
about that.
>
>It's a trade-off, and details will be different for each site. But for
my customers the extra up front cost would be recovered by just a few
sales.

You don't charge them enough Jerry! ;-)
Sure I do :-)

But most of them aren't selling $5 Rolex Replicas, either. :-) They're
doing something a little higher end, where their markup could be from
$10-100 per order. Even at $10 it doesn't take long to recoup a couple
of hundred dollars.
>Another example here. I'm working on a site with dropdowns for country
and state/province. When the country changes, the state/province
contents change (or it is disabled).

Obviously this requires javascript and there's no way to do it with
javascript disabled. So I set it up such that all entries are placed in
the state/province block. When JS is enabled, it replaces the content
with an accurate list (or disables it completely). But if JS is
disabled, the state/province block shows all entries. Either way there
needs to be further validation server side. But again, JS "enhances the
experience".

Yes, that's the right way to do it: replace the content of some div or
something like that.
No discussion there. :-)

Happy coding.

Regards,
Erwin Moller

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 23 '07 #19

P: n/a
Message-ID: <De******************************@comcast.comfro m Jerry
Stuckle contained the following:
>An even easier way:

name=' chosen[$id]' value='$id' id='chosen{$id}

And in your Javascript use:

document.getElementById(chosen{$id})

That way both Javascript and PHP are happy.
Cool. Not really done much in JS so I struggle somewhat.

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/
Feb 24 '07 #20

P: n/a
Erwin Moller kirjoitti:
Kimmo Laine wrote:
>Kimmo Laine kirjoitti:
>>mo************@gmail.com kirjoitti:
Hi All,

I need a small clarification in submitting the forms, Ur
suggestions please.

In a page I have two form and also two submit butons.
(ie)

<form name="myform" action="test.php" method="post" >
<input type="text" name="myform_name" >
<input type="text" name="myform_id" >
<input type="text" name="myform_no" >
<input type="submit" value="Submit" />
</form>

<form name="myform1" action="test.php" >
<input type="text" name="myform1_name" >
<input type="text" name="myform1_id" >
<input type="text" name="myform1_no" >
<input type="submit" value="Submit" />
</form>
Okay, now I noticed Jerry already replied the almost-same answer already
and here I'm repeating it. What a silly bunt. Well at least the correct
answer was already given. I just read the couple of first answers and
every time someone recommends a javascript "solution" I jump to the roof.
:D

Hi Kimmo,

-- The Javascript 'solution' poster speaking. ;-)

Kimmo, I would really like to see your solution to the original problem (2
forms!) without using Javascript.
It is simply not possible.
Allthough I also wonder why th OP wants 2 forms. As far as I can judge 1
form will do just fine, but I don't know the problem at hand (and neither
do you!).
This was my point. I fail to recognize the need for two separate forms.
Of course it's not possible to submit two forms without javascript, all
I'm saying that I do not see the need for having two forms. I see
JavaScript as a possibility make things easier, but bottom line is
always that things have to use without it if you're making a public
application. In intranet it's a different story. I write applications
for both intranet and internet and in the safety of the defined
environment where I can tell our people to use javascripts I do take
advantage of it to the maximum. When writing the pages for public use I
don't have the luxury of knowing the configuration of the client. In
that case everything has got to be robust and failsafe and that means
nothing can rely on javascript.

I think we are on the same page and agree, even though we see things
maybe a little bit differently.
One a sidenote: What is so bad about demanding JS for your site? People
demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
I have no problems with it. :-/
Those are on my naughty-list as well. Being a Linux user I suffer a
great deal of not having a proper Flash support or IE. Some pages just
aren't accessible at all. Then there's usually the friendly link which
tells me where I can download and install IE and/or Flash to my
Microsoft Windows XP which is just damn hilarious. :)

Once I complained to the Coca-cola company of Finland about their
websites being all Flashy and completely unreachble for me, they just
said they're sorry that my computer doesn't meet the requirements
they've set. It's fighting windmills, I suppose, but over the years I've
gotten used to it. It has taught me to try to avoid gizmos and glitter
that require a particular browser/os/plugin/whatever on the site I'm
administrating for a living. Just trying to build a better world, that's
all. :)

--
"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirviö
sp**@outolempi.net | Gedoon-S @ IRCnet | rot13(xv***@bhgbyrzcv.arg)
Feb 24 '07 #21

P: n/a
Jerry Stuckle wrote:
Erwin Moller wrote:
>Jerry Stuckle wrote:
>>Erwin Moller wrote:
Jerry Stuckle wrote:

<snip>
>In defense for javascript: My *personal experience* is that a lot
>of my
>customers prefer the sexy behaviour a site gets with javascript above
>better compatibility (= JS disabled).
>Also: It takes a lot more developmenttime in realworld situation to
>make a 'double site': one for JS enabled, one for disabled. And
>not all
>want to pay for that, and settle for JS only site.
You don't need to have two sites. JS should enhance a page - but
not be
required to use it.
Hi Jerry,

Of course you don't need 2 seperate sites.
I know that. I I think you know I know. :-)
That is why I wrote 'double site' between the ''.
My point is simply that making sites work in both situations can take a
lot more effort in some situations.
And I am not refering to trivial checks like somebody filled in a
certain
field in a form. That is a breeze of course, and should be checked
serverside anyway.

But a lot of people would take "double site" to mean two separate copies
of each page - one with JS enabled and one without.

My bad.
That happens when Dutch guys think they mastered english enough. ;-)

Understandable. But you wouldn't want to hear my try at Dutch! :-)
>>
>>>>>I simple say at the homepage/entrancepage that JS must be enabled to
>use the site.
>Of course, a website that handles both situations right is better
>than
>one that demands JS.
>>
And therein lies the problem. How many people leave after seeing your
home page without going any further? Every one of them who run
with JS
turned off. So obviously, since you only see those who have
javascript
disabled, your conclusion is that most people have JS enabled.
???
Where did I say I concluded that most people have JS enabled based
on my
visitors? You put words in my mouth/writing.

I DO think that by the way, I just didn't say it. Maybe you are
confusing
posters. :-)

No, you didn't state it here. But it's a logical conclusion from other
comments you've made and the fact you don't push it with your customers.
But it's also an obvious conclusion to make when you never see the
non-JS users.

There isn't anything wrong with this opinion, Erwin. And for your
customer base it may be 100% correct. But do you think it might also be
based on incomplete information?

To be honest, I am unsure.
Last numbers I saw (w3schools) says 6% is JS challenged.
But I admid I have no clue how reliable that numbers are.

Me, neither. And it depends a lot on the target audience.
>By the way: I cannot reach www.thecounter.com anymore. They used to
serve good statistics if memory serves me well. Does anybody know what
happened with them? Paying clients only?

I can still get it here.

>Still, from a (business) clients point of view 6% missed customers can
or cannot be acceptable (pricewise).
Very roughly speaking: I think the price for sites I build rises by
10-20% on most projects I work on to make them work in both situations.
Mostly because of double work.

Yes, it is more work. But things like validation (as you pointed out
earlier) can be done on the client side - but must be done on the server
end, also. And yes, 10-20% is about right, in my experience.
>>
>>>>>An example (a thing I am working on right now):
>I need a geograpical map of some area with lots of regions in it.
>The user clicks on one region and I must select the neighbouring
>regions: they light up.
>Another selectbox defines how deep the neighbours are found (eg 0, 1,
>2, etc).
>If I must deliver that piece without JS, I need a roundrobin to the
>server for each click, rebuild the map with the right regions lighted
>up: quite slow and it will result in a sluggish enduserexperience.
>This is just an example of realworld situations I do want to
>program/deliver without JS.
>>
Yes, it requires a request to the server. but it should not be "slow"
and should not result in a sluggish end user experience".
Not?
Not if the map exists of 200+ images that the browser has to layout
every
time after every click?
Of course that will be sluggish compared to Javascript switching a few
images, and you know that just as well as I do. Or I am misjudging your
competence completely.

First of all, most of those images would already be cached by the
browser and wouldn't need to be fetched from the server.

But it also means you need to send two copies of every image for the JS
version, whether or not you'll even need them (and chances are you won't
need all of them - maybe not even a large percentage of the copies).

So your first page is going to be twice as slow loading because it has
to load all of those images which probably won't be used.

True.
But after one click JS wins performancewise.
Slower to build the first time, faster after one click.
>>So a good compromise in this case would be to have JS load the copies
and handle the image switches. And if JS isn't active, don't load the
extra copies and make the trip to the server.

That way JS is enhancing the experience, but the experience doesn't
require JS.

True.
I am merely trying to get the point across that I have to make the
routines in HTML/JS AND in PHP serverside.
More work, higher bill.

Yep, and fewer lost potential customers.
>>>>>One a sidenote: What is so bad about demanding JS for your site?
>People
>demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
>I have no problems with it. :-/
>>
Because you lose customers that way. Every one who surfs with
javascript turned off. And you never see them go.
Loose customers?
I loose MY customers if I present them bills for fully compatible sites
(JS/no JS, Java/No Java, Flash/no Flash, etc).

I'm talking about THEIR customers. I don't lose customers because I can
show them how not being compatible would lose them money. Most are
quite happy to pay for non-JS versions when they understand requiring JS
can cost them more in lost sales than the cost of implementing the
solution.

Just curious, roughly speaking, how much more work do you guess you
need to make your app work nicely with and without JS? (I estimated
that in my case around 10-20%)

About the same here. It depends a lot on the site.
>>
>>>Well Jerry, as I said: I don't mind making apps 100% non-JS compatible.
But I must raise my bill because it results in more coding/thinking and
in some situations a lot of double work.
Of course I prefer a site that handles both situations....
And the situation flas/no flash.
And the situation Java/no Java.
Go on and do the math. My bills will grow.

I think you are describing some 'ideal world' solution, while I
tried to
describe real world situations that run on tight budgets.
I do not know how you are employed, but I run my own business and
simply
do not have the luxery to make perfect apps day-in-day-out, allthough I
would like that.

No, not "ideal world". The way I work. I run my own business, also
(have for over 16 years, now). I don't make 'perfect' apps. But at the
same time I show my customers the real world. And BTW - I don't do
flash at all - too "graphically challenged" :-). But I have someone who
can do the flash if I need it. And I don't do client-side Java unless
there is a very good reason for it. Most sites obviously don't need it.

True.
I also seldom use Java clientside these days. (I used to love it, but
since Javascript became more powerfull, and I could develop a lot
fatser in JS...)

I still do some server side Java - it's nice if you get it on a fast
server. But Java can be a resource hog, and many clients it would run
unacceptably slow, especially when you're targeting consumers (who are
more likely to be speed and/or memory constrained).
>>
>>In an "ideal world" you could require JS/Flash/Java and anything else
and not lose any potential customers. In the "real world", though,
doing any of these will lose you potential customers. The only question
is which will cost you more money in the long run - the loss of
customers by requiring these technologies, or the cost of implementing
non-JS/Java/Flash version.

Yes, that is the question.
And the answer depends on the type of customer indeed.
I do a lot of start-ups (people who just start their business and need
online help), and lots of them are very pennywise, but poundfoolish.
In case their business runs smoothly, they DO have the money to
upgrade/fix annoying stuff on their site. :-)

Yes, I see that, also. But that's where I explain to them how they can
lose customers because of it. If the have any brains at all, they think
about that.
>>
>>It's a trade-off, and details will be different for each site. But for
my customers the extra up front cost would be recovered by just a few
sales.

You don't charge them enough Jerry! ;-)

Sure I do :-)

But most of them aren't selling $5 Rolex Replicas, either. :-) They're
doing something a little higher end, where their markup could be from
$10-100 per order. Even at $10 it doesn't take long to recoup a couple
of hundred dollars.
>>Another example here. I'm working on a site with dropdowns for country
and state/province. When the country changes, the state/province
contents change (or it is disabled).

Obviously this requires javascript and there's no way to do it with
javascript disabled. So I set it up such that all entries are placed in
the state/province block. When JS is enabled, it replaces the content
with an accurate list (or disables it completely). But if JS is
disabled, the state/province block shows all entries. Either way there
needs to be further validation server side. But again, JS "enhances the
experience".

Yes, that's the right way to do it: replace the content of some div or
something like that. No discussion there. :-)

Happy coding.

Regards,
Erwin Moller

I don't run my own business, and have been coding mainly for the sake
of learning/enjoyment. So, there are probably perspectives I just
can't conceive of right now.

I was just curious why one couldn't eliminate the extra work of making
a more accessible site through the practice of organizing code and
making it as modular as possible. It would seem like you could reduce
the overhead of a lot of tasks this way. I have become fluent in
JavaScript over the years, and I find it works best when you start the
app design without any JS, and build up from there, each layer
gracefully degrading to the previous, when necessary. This is what I
think of when Jerry mentioned using JS to "enhance" apps, not make
apps dependent upon it. JS, I feel is a great way to reduce server
load for things like validating data on the client side (of course,
always ensuring that data is validated server side). But all this can
be organized so reusing and building new things is relatively painless.

Like I said though, I haven't been in a position like Erwin's, so I
couldn't speak of that situation. I would imagine though, as long as
your clients are happy, referring others, and/or returning, then you
must be doing something right. :)

--
Curtis, http://dyersweb.com
Feb 25 '07 #22

P: n/a
Curtis wrote:
Jerry Stuckle wrote:
>Erwin Moller wrote:
>>Jerry Stuckle wrote:

Erwin Moller wrote:
Jerry Stuckle wrote:
>
<snip>
>>In defense for javascript: My *personal experience* is that a lot
>>of my
>>customers prefer the sexy behaviour a site gets with javascript
>>above
>>better compatibility (= JS disabled).
>>Also: It takes a lot more developmenttime in realworld situation to
>>make a 'double site': one for JS enabled, one for disabled. And
>>not all
>>want to pay for that, and settle for JS only site.
>You don't need to have two sites. JS should enhance a page - but
>not be
>required to use it.
Hi Jerry,
>
Of course you don't need 2 seperate sites.
I know that. I I think you know I know. :-)
That is why I wrote 'double site' between the ''.
My point is simply that making sites work in both situations can
take a
lot more effort in some situations.
And I am not refering to trivial checks like somebody filled in a
certain
field in a form. That is a breeze of course, and should be checked
serverside anyway.
>
But a lot of people would take "double site" to mean two separate
copies
of each page - one with JS enabled and one without.

My bad.
That happens when Dutch guys think they mastered english enough. ;-)

Understandable. But you wouldn't want to hear my try at Dutch! :-)
>>>
>>I simple say at the homepage/entrancepage that JS must be enabled to
>>use the site.
>>Of course, a website that handles both situations right is better
>>than
>>one that demands JS.
>>>
>And therein lies the problem. How many people leave after seeing
>your
>home page without going any further? Every one of them who run
>with JS
>turned off. So obviously, since you only see those who have
>javascript
>disabled, your conclusion is that most people have JS enabled.
???
Where did I say I concluded that most people have JS enabled based
on my
visitors? You put words in my mouth/writing.
>
I DO think that by the way, I just didn't say it. Maybe you are
confusing
posters. :-)
>
No, you didn't state it here. But it's a logical conclusion from other
comments you've made and the fact you don't push it with your
customers.
But it's also an obvious conclusion to make when you never see the
non-JS users.

There isn't anything wrong with this opinion, Erwin. And for your
customer base it may be 100% correct. But do you think it might
also be
based on incomplete information?

To be honest, I am unsure.
Last numbers I saw (w3schools) says 6% is JS challenged.
But I admid I have no clue how reliable that numbers are.

Me, neither. And it depends a lot on the target audience.
>>By the way: I cannot reach www.thecounter.com anymore. They used to
serve good statistics if memory serves me well. Does anybody know
what happened with them? Paying clients only?

I can still get it here.

>>Still, from a (business) clients point of view 6% missed customers
can or cannot be acceptable (pricewise).
Very roughly speaking: I think the price for sites I build rises by
10-20% on most projects I work on to make them work in both situations.
Mostly because of double work.

Yes, it is more work. But things like validation (as you pointed out
earlier) can be done on the client side - but must be done on the
server end, also. And yes, 10-20% is about right, in my experience.
>>>
>>An example (a thing I am working on right now):
>>I need a geograpical map of some area with lots of regions in it.
>>The user clicks on one region and I must select the neighbouring
>>regions: they light up.
>>Another selectbox defines how deep the neighbours are found (eg
>>0, 1,
>>2, etc).
>>If I must deliver that piece without JS, I need a roundrobin to the
>>server for each click, rebuild the map with the right regions
>>lighted
>>up: quite slow and it will result in a sluggish enduserexperience.
>>This is just an example of realworld situations I do want to
>>program/deliver without JS.
>>>
>Yes, it requires a request to the server. but it should not be
>"slow"
>and should not result in a sluggish end user experience".
Not?
Not if the map exists of 200+ images that the browser has to layout
every
time after every click?
Of course that will be sluggish compared to Javascript switching a few
images, and you know that just as well as I do. Or I am misjudging
your
competence completely.
>
First of all, most of those images would already be cached by the
browser and wouldn't need to be fetched from the server.

But it also means you need to send two copies of every image for the JS
version, whether or not you'll even need them (and chances are you
won't
need all of them - maybe not even a large percentage of the copies).

So your first page is going to be twice as slow loading because it has
to load all of those images which probably won't be used.

True.
But after one click JS wins performancewise.
Slower to build the first time, faster after one click.

So a good compromise in this case would be to have JS load the copies
and handle the image switches. And if JS isn't active, don't load the
extra copies and make the trip to the server.

That way JS is enhancing the experience, but the experience doesn't
require JS.

True.
I am merely trying to get the point across that I have to make the
routines in HTML/JS AND in PHP serverside.
More work, higher bill.

Yep, and fewer lost potential customers.
>>>>>>One a sidenote: What is so bad about demanding JS for your site?
>>People
>>demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
>>I have no problems with it. :-/
>>>
>Because you lose customers that way. Every one who surfs with
>javascript turned off. And you never see them go.
Loose customers?
I loose MY customers if I present them bills for fully compatible
sites
(JS/no JS, Java/No Java, Flash/no Flash, etc).
>
I'm talking about THEIR customers. I don't lose customers because I
can
show them how not being compatible would lose them money. Most are
quite happy to pay for non-JS versions when they understand
requiring JS
can cost them more in lost sales than the cost of implementing the
solution.

Just curious, roughly speaking, how much more work do you guess you
need to make your app work nicely with and without JS? (I estimated
that in my case around 10-20%)

About the same here. It depends a lot on the site.
>>>
Well Jerry, as I said: I don't mind making apps 100% non-JS
compatible.
But I must raise my bill because it results in more coding/thinking
and
in some situations a lot of double work.
Of course I prefer a site that handles both situations....
And the situation flas/no flash.
And the situation Java/no Java.
Go on and do the math. My bills will grow.
>
I think you are describing some 'ideal world' solution, while I
tried to
describe real world situations that run on tight budgets.
I do not know how you are employed, but I run my own business and
simply
do not have the luxery to make perfect apps day-in-day-out,
allthough I
would like that.
>
No, not "ideal world". The way I work. I run my own business, also
(have for over 16 years, now). I don't make 'perfect' apps. But at
the
same time I show my customers the real world. And BTW - I don't do
flash at all - too "graphically challenged" :-). But I have someone
who
can do the flash if I need it. And I don't do client-side Java unless
there is a very good reason for it. Most sites obviously don't need
it.

True.
I also seldom use Java clientside these days. (I used to love it, but
since Javascript became more powerfull, and I could develop a lot
fatser in JS...)

I still do some server side Java - it's nice if you get it on a fast
server. But Java can be a resource hog, and many clients it would run
unacceptably slow, especially when you're targeting consumers (who are
more likely to be speed and/or memory constrained).
>>>
In an "ideal world" you could require JS/Flash/Java and anything else
and not lose any potential customers. In the "real world", though,
doing any of these will lose you potential customers. The only
question
is which will cost you more money in the long run - the loss of
customers by requiring these technologies, or the cost of implementing
non-JS/Java/Flash version.

Yes, that is the question.
And the answer depends on the type of customer indeed.
I do a lot of start-ups (people who just start their business and
need online help), and lots of them are very pennywise, but
poundfoolish. In case their business runs smoothly, they DO have the
money to upgrade/fix annoying stuff on their site. :-)

Yes, I see that, also. But that's where I explain to them how they
can lose customers because of it. If the have any brains at all, they
think about that.
>>>
It's a trade-off, and details will be different for each site. But for
my customers the extra up front cost would be recovered by just a few
sales.
You don't charge them enough Jerry! ;-)

Sure I do :-)

But most of them aren't selling $5 Rolex Replicas, either. :-)
They're doing something a little higher end, where their markup could
be from $10-100 per order. Even at $10 it doesn't take long to recoup
a couple of hundred dollars.
>>>Another example here. I'm working on a site with dropdowns for country
and state/province. When the country changes, the state/province
contents change (or it is disabled).

Obviously this requires javascript and there's no way to do it with
javascript disabled. So I set it up such that all entries are
placed in
the state/province block. When JS is enabled, it replaces the content
with an accurate list (or disables it completely). But if JS is
disabled, the state/province block shows all entries. Either way there
needs to be further validation server side. But again, JS "enhances
the
experience".

Yes, that's the right way to do it: replace the content of some div
or something like that. No discussion there. :-)

Happy coding.

Regards,
Erwin Moller


I don't run my own business, and have been coding mainly for the sake of
learning/enjoyment. So, there are probably perspectives I just can't
conceive of right now.

I was just curious why one couldn't eliminate the extra work of making a
more accessible site through the practice of organizing code and making
it as modular as possible. It would seem like you could reduce the
overhead of a lot of tasks this way. I have become fluent in JavaScript
over the years, and I find it works best when you start the app design
without any JS, and build up from there, each layer gracefully degrading
to the previous, when necessary. This is what I think of when Jerry
mentioned using JS to "enhance" apps, not make apps dependent upon it.
JS, I feel is a great way to reduce server load for things like
validating data on the client side (of course, always ensuring that data
is validated server side). But all this can be organized so reusing and
building new things is relatively painless.

Like I said though, I haven't been in a position like Erwin's, so I
couldn't speak of that situation. I would imagine though, as long as
your clients are happy, referring others, and/or returning, then you
must be doing something right. :)

--
Curtis, http://dyersweb.com
Curtis,

Yes, you can do that - but it still requires additional effort, which
adds time and cost to the project - Just like doing a database-driven
PHP page takes more time and effort than a static HTML page.

Every time you add a new bell/whistle you're talking about more work,
and there are only so many billable hours. Now, if you want to give
your time away...

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 25 '07 #23

P: n/a
On Sun, 25 Feb 2007 05:49:49 -0800, Jerry Stuckle
<js*******@attglobal.netwrote:
Curtis wrote:
>Jerry Stuckle wrote:
>>Erwin Moller wrote:
Jerry Stuckle wrote:

Erwin Moller wrote:
>Jerry Stuckle wrote:
>>
><snip>
>>>In defense for javascript: My *personal experience* is that a lot
>>>of my
>>>customers prefer the sexy behaviour a site gets with javascript
>>>above
>>>better compatibility (= JS disabled).
>>>Also: It takes a lot more developmenttime in realworld situation
>>>to
>>>make a 'double site': one for JS enabled, one for disabled. And
>>>not all
>>>want to pay for that, and settle for JS only site.
>>You don't need to have two sites. JS should enhance a page - but
>>not be
>>required to use it.
>Hi Jerry,
>>
>Of course you don't need 2 seperate sites.
>I know that. I I think you know I know. :-)
>That is why I wrote 'double site' between the ''.
>My point is simply that making sites work in both situations can
>take a
>lot more effort in some situations.
>And I am not refering to trivial checks like somebody filled in a
>certain
>field in a form. That is a breeze of course, and should be checked
>serverside anyway.
>>
But a lot of people would take "double site" to mean two separate
copies
of each page - one with JS enabled and one without.

My bad.
That happens when Dutch guys think they mastered english enough. ;-)
Understandable. But you wouldn't want to hear my try at Dutch! :-)
>>>I simple say at the homepage/entrancepage that JS must be enabled
>>>to
>>>use the site.
>>>Of course, a website that handles both situations right is better
>>>than
>>>one that demands JS.
>>>>
>>And therein lies the problem. How many people leave after seeing
>>your
>>home page without going any further? Every one of them who run
>>with JS
>>turned off. So obviously, since you only see those who have
>>javascript
>>disabled, your conclusion is that most people have JS enabled.
>???
>Where did I say I concluded that most people have JS enabled based
>on my
>visitors? You put words in my mouth/writing.
>>
>I DO think that by the way, I just didn't say it. Maybe you are
>confusing
>posters. :-)
>>
No, you didn't state it here. But it's a logical conclusion from
other
comments you've made and the fact you don't push it with your
customers.
But it's also an obvious conclusion to make when you never see
the
non-JS users.
>
There isn't anything wrong with this opinion, Erwin. And for your
customer base it may be 100% correct. But do you think it might
also be
based on incomplete information?

To be honest, I am unsure.
Last numbers I saw (w3schools) says 6% is JS challenged.
But I admid I have no clue how reliable that numbers are.
Me, neither. And it depends a lot on the target audience.

By the way: I cannot reach www.thecounter.com anymore. They used to
serve good statistics if memory serves me well. Does anybody know
what happened with them? Paying clients only?
I can still get it here.
Still, from a (business) clients point of view 6% missed customers
can or cannot be acceptable (pricewise).
Very roughly speaking: I think the price for sites I build rises by
10-20% on most projects I work on to make them work in both
situations.
Mostly because of double work.
Yes, it is more work. But things like validation (as you pointed out
earlier) can be done on the client side - but must be done on the
server end, also. And yes, 10-20% is about right, in my experience.
>>>An example (a thing I am working on right now):
>>>I need a geograpical map of some area with lots of regions in it.
>>>The user clicks on one region and I must select the neighbouring
>>>regions: they light up.
>>>Another selectbox defines how deep the neighbours are found (eg
>>>0, 1,
>>>2, etc).
>>>If I must deliver that piece without JS, I need a roundrobin to
>>>the
>>>server for each click, rebuild the map with the right regions
>>>lighted
>>>up: quite slow and it will result in a sluggish enduserexperience.
>>>This is just an example of realworld situations I do want to
>>>program/deliver without JS.
>>>>
>>Yes, it requires a request to the server. but it should not be
>>"slow"
>>and should not result in a sluggish end user experience".
>Not?
>Not if the map exists of 200+ images that the browser has to layout
>every
>time after every click?
>Of course that will be sluggish compared to Javascript switching a
>few
>images, and you know that just as well as I do. Or I am misjudging
>your
>competence completely.
>>
First of all, most of those images would already be cached by the
browser and wouldn't need to be fetched from the server.
>
But it also means you need to send two copies of every image for the
JS
version, whether or not you'll even need them (and chances are you
won't
need all of them - maybe not even a large percentage of the copies).
>
So your first page is going to be twice as slow loading because it
has
to load all of those images which probably won't be used.

True.
But after one click JS wins performancewise.
Slower to build the first time, faster after one click.

So a good compromise in this case would be to have JS load the copies
and handle the image switches. And if JS isn't active, don't load
the
extra copies and make the trip to the server.
>
That way JS is enhancing the experience, but the experience doesn't
require JS.

True.
I am merely trying to get the point across that I have to make the
routines in HTML/JS AND in PHP serverside.
More work, higher bill.
Yep, and fewer lost potential customers.

>>>One a sidenote: What is so bad about demanding JS for your site?
>>>People
>>>demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
>>>I have no problems with it. :-/
>>>>
>>Because you lose customers that way. Every one who surfs with
>>javascript turned off. And you never see them go.
>Loose customers?
>I loose MY customers if I present them bills for fully compatible
>sites
>(JS/no JS, Java/No Java, Flash/no Flash, etc).
>>
I'm talking about THEIR customers. I don't lose customers becauseI
can
show them how not being compatible would lose them money. Most are
quite happy to pay for non-JS versions when they understand
requiring JS
can cost them more in lost sales than the cost of implementing the
solution.

Just curious, roughly speaking, how much more work do you guess you
need to make your app work nicely with and without JS? (I estimated
that in my case around 10-20%)
About the same here. It depends a lot on the site.
>Well Jerry, as I said: I don't mind making apps 100% non-JS
>compatible.
>But I must raise my bill because it results in more coding/thinking
>and
>in some situations a lot of double work.
>Of course I prefer a site that handles both situations....
>And the situation flas/no flash.
>And the situation Java/no Java.
>Go on and do the math. My bills will grow.
>>
>I think you are describing some 'ideal world' solution, while I
>tried to
>describe real world situations that run on tight budgets.
>I do not know how you are employed, but I run my own business and
>simply
>do not have the luxery to make perfect apps day-in-day-out,
>allthough I
>would like that.
>>
No, not "ideal world". The way I work. I run my own business, also
(have for over 16 years, now). I don't make 'perfect' apps. But at
the
same time I show my customers the real world. And BTW - I don't do
flash at all - too "graphically challenged" :-). But I have someone
who
can do the flash if I need it. And I don't do client-side Java
unless
there is a very good reason for it. Most sites obviously don't need
it.

True.
I also seldom use Java clientside these days. (I used to love it, but
since Javascript became more powerfull, and I could develop a lot
fatser in JS...)
I still do some server side Java - it's nice if you get it on a fast
server. But Java can be a resource hog, and many clients it would run
unacceptably slow, especially when you're targeting consumers (who are
more likely to be speed and/or memory constrained).
In an "ideal world" you could require JS/Flash/Java and anything else
and not lose any potential customers. In the "real world", though,
doing any of these will lose you potential customers. The only
question
is which will cost you more money in the long run - the loss of
customers by requiring these technologies, or the cost of
implementing
non-JS/Java/Flash version.

Yes, that is the question.
And the answer depends on the type of customer indeed.
I do a lot of start-ups (people who just start their business and
need online help), and lots of them are very pennywise, but
poundfoolish. In case their business runs smoothly, they DO have the
money to upgrade/fix annoying stuff on their site. :-)
Yes, I see that, also. But that's where I explain to them how they
can lose customers because of it. If the have any brains at all, they
think about that.
It's a trade-off, and details will be different for each site. But
for
my customers the extra up front cost would be recovered by just a few
sales.
>

You don't charge them enough Jerry! ;-)
Sure I do :-)

But most of them aren't selling $5 Rolex Replicas, either. :-)
They're doing something a little higher end, where their markup could
be from $10-100 per order. Even at $10 it doesn't take long to recoup
a couple of hundred dollars.

Another example here. I'm working on a site with dropdowns for
country
and state/province. When the country changes, the state/province
contents change (or it is disabled).
>
Obviously this requires javascript and there's no way to do it with
javascript disabled. So I set it up such that all entries are
placed in
the state/province block. When JS is enabled, it replaces the
content
with an accurate list (or disables it completely). But if JS is
disabled, the state/province block shows all entries. Either way
there
needs to be further validation server side. But again, JS "enhances
the
experience".

Yes, that's the right way to do it: replace the content of some div
or something like that. No discussion there. :-)

Happy coding.

Regards,
Erwin Moller

I don't run my own business, and have been coding mainly for the sake
of learning/enjoyment. So, there are probably perspectives I just can't
conceive of right now.
I was just curious why one couldn't eliminate the extra work of making
a more accessible site through the practice of organizing code and
making it as modular as possible. It would seem like you could reduce
the overhead of a lot of tasks this way. I have become fluent in
JavaScript over the years, and I find it works best when you start the
app design without any JS, and build up from there, each layer
gracefully degrading to the previous, when necessary. This is what I
think of when Jerry mentioned using JS to "enhance" apps, not make apps
dependent upon it. JS, I feel is a great way to reduce server load for
things like validating data on the client side (of course, always
ensuring that data is validated server side). But all this can be
organized so reusing and building new things is relatively painless.
Like I said though, I haven't been in a position like Erwin's, so I
couldn't speak of that situation. I would imagine though, as long as
your clients are happy, referring others, and/or returning, then you
must be doing something right. :)
-- Curtis, http://dyersweb.com

Curtis,

Yes, you can do that - but it still requires additional effort, which
adds time and cost to the project - Just like doing a database-driven
PHP page takes more time and effort than a static HTML page.

Every time you add a new bell/whistle you're talking about more work,
and there are only so many billable hours. Now, if you want to give
your time away...
Wow, I dropped off the radar for quite a while.

Well, on my free time, I still enjoy coding, and have made my own web dev
"standard library," if you will. It's not perfect, but it does help me
reduce the time in making sure JS degrades gracefully, as well as
simplifying many things server side.

--
Curtis, http://dyersweb.com
Mar 11 '07 #24

This discussion thread is closed

Replies have been disabled for this discussion.