Posted by Jerry Stuckle on 08/17/06 03:48

Chris wrote:
> "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."
>

That's hard to say. You can see the JS - but you won't generally see
the server-side validation unless you turn off JS.

And JS normally goes in the header - but AFAIK, there's no requirement
that it be in the header. I've placed it in the body before and it woks
just fine. I doubt that's your problem.

>
>>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");
>

header() can be used for either GET or POST. No difference. The only
thing you have to insure is that you send *NO* output (even whitespace)
before the header(). Otherwise, the webserver will have already sent
the headers and you'll get an error on the header() call.

>
>>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.
>
Yes, you can pass them as GET parameters. But then it shows up in the
browser's URL bar. Personally, I prefer saving this info in the
$_SESSION. variable (with start_session at the top of each page using
sessions).

>
>>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
>
>
>
>

C

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]