|
|
Posted by Chris on 08/16/06 17:48
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:6LWdnftQxpp1xn_ZnZ2dnUVZ_umdnZ2d@comcast.com...
>
> Chris,
>
> As Rik is trying to tell you, there is no interaction between javascript
> and PHP (unless you're using Ajax - but that's another story). PHP can
> create the JS - just like you can type it out. But JS doesn't call PHP
> functions.
Yes, I understood that, perhaps I wasn't very clear in how I presented it.
I was referring to information I've seen regarding passing PHP and JS values
back and forth.
Here are some examples:
http://www.netadmintools.com/art469.html
http://aspn.activestate.com/ASPN/Cookbook/PHP/Recipe/414334
http://www.activewidgets.com/javascript.forum.4257.6/javascript-and-php-variables.html
>
> I don't rely on js for form validation. The user can turn it off too
> easily. I validate everything server side. Even when I validate with JS,
> I revalidate on the server.
>
Thank you so much Jerry. This is the advice I was looking for. Much of
what you have said is similar to what I have seen around the web, but what's
out there varies so much, and some is old, so I rely on the newsgroups to
give me a current (therefore hopefully well-tested) approach.
I like this approach and have seen some reference to it online.
This page looks like a good start:
http://www.php-mysql-tutorial.com/form-validation-with-php.php
Most places simply go with js validation using onSubmit event handler,
however I have seen those that use only PHP, and some that use both. The
code that I posted appeared to not find the js function before the form was
submitted It wasn't the only js function I tried, but they all were very
similar - none of them worked - and most were c&p with only a change to the
name of the form and form element - I'm figuring it's because of where I
located the function(s). In my response to Randy Webb, I stated, "Our site
has a header automatically prepended, therefore, it's very likely didn't
have the js in the correct spot so that it can be called from the very top
of the page (within the initial head tags) - perhaps as an external js
file."
> There are two ways to validate on the server - on the current page or on
> the next page. Both are done in PHO.
>
> Validating on the current page means you submit the form to the same page.
> At the beginning of your page, check to see if the page has been
> submitted. If not, go display your form. If it has, validate the data.
> If it validates, redirect to the next page. If not, display the errors.
> The advantage here is the validation code is on the same page as the form
> it's validating - nice and compact. The downside is you can't post the
> data to the next page, so you either need to use GET or store the data in
> a session object.
>
I think I would like to validate in the same page as the form. Since this
is an intranet and security is handled at the server level (vs. site level)
it is possible that a session is already created as soon as the user logs
on. I say this because I have seen values continue to be displayed even
when refreshing a form (like a sticky form, but I didn't intentionally code
it to be one). They only seem to clear when the page is accessed through a
link as a totally new page. Oddly, this doesn't always occur, and Firefox
does this differently than IE, and I haven't had time to study and evaluate
what is happening.
Is the header() command what you are referring to when you say use GET? I
saw this on a tutorial. The tutorial used this for sending the processing to
a new page, but the validation was PHP and in the same page as the form.
header("location: formpage.php?firstname=$firstname&lastname=$lastname");
> Validating on the next page means you do the actual validation in the page
> receiving the form. You can post the data from the first form to the
> second one, but if you detect an error it's more difficult to go back to
> the first page.
>
Perhaps the header("location:
formpage.php?firstname=$firstname&lastname=$lastname"); would also work to
get back to the original form? I'm thinking in terms of passing the already
set values back to the form so it doesn't need to be completely refilled.
> I use both, depending on the circumstances.
>
> But the bottom line is - always validate server side, even if you fist
> validate client side.
>
Thanks again,
Chris
Navigation:
[Reply to this message]
|