"^AndreA^" <> writes:
> On Jul 25, 2:48 pm, Sherman Pendley <spamt...@dot-app.org> wrote:
>> "^AndreA^" <andrea.b...@gmail.com> writes:
>> > With javascript I usually check if the fields are filled up correctly
>> > and then I let javascript send them to the server, so I don't use the
>> > form tag becuase I don't need it.
>>
>> > Is this method wrong?
>>
>> Yes. Your script should only stop the form submission if there's
>> something wrong with the input. Keep in mind that some users will
>> disable JS, so your server-side script should be prepared to handle a
>> plain form submission that hasn't been "approved" by the JS.
>>
>> > Are there any downside I don't know?
>>
>> Not everyone allows JavaScript, of course. And you *will* get input
>> from hacked pages and/or bots - count on it. "Never trust the client"
>> should be the mantra of *every* network programmer. So, checking input
>> in the client is a great way to add a convenience for users who allow
>> it - but then check the input again, on the server, in case the client
>> can't or won't do the job.
>>
>
> and then I tie a js event to the submit button.
>
> So, when the user presses the button the js function starts, but also
> the data is sent to the server... because pressing the button you
> active two things simultaneously.
>
> I'm sure there is a workaround...
>
> Basically the question is:
> how can I tie a js function to the form without breaking it?
> how can I prevent the form to send data if js "says" there is
> something wrong?
Tie an onsubmit handler to the form, instead of an onclick on a
button. If JS is allowed and the form handler returns false, the form
isn't sent. If the handler returns true, the form data is sent to the
action URL. If JS is disabled, the form behaves just like any other
non-JS form, and sends its data to the action URL.
sherm--
--
My blog:
http://shermspace.blogspot.com
Cocoa programming in Perl:
http://camelbones.sourceforge.net