PHP v ASP?

Wraith2700

PHP includes any version of PHP out there, Same for ASP

Ok, which do you think is better? (Probably not a good idea to post this on a PHP forum 😃) ASP or PHP? Also, is there a client side version of ASP? I am really getting mad at javascript because when I write scripts in it it either wont work in IE or Netscape 🙁.

Also (if there is not a client side version of ASP), is there anything else besides javascript?

TheDefender

ASP is server-side, just as PHP is, so to answer your question, no there is no "client-side" version of ASP, just as there is no "client-side" version of PHP.

The trick to JavaScript, is in writing it to be cross-platform capable. (You can get ideas of how to do this at Dynamicdrive.com) Of course, that is all thrown away when people like me hit your site, because our JS is turned off anyhow. Don't you just hate JS?

If you are doing verification for example, then it is always better to integrate server side verification as a backup to the JS verification anyhow. That just ensures people can't add unverified data to your DB...

PS. I can't say either is "better", because they both have their weak points and strong points. For integrating with Active Directory, Access DBs, or SQL Server, I prefer ASP. But I personally make it a point to exhaust every effort to write it in PHP before resorting to ASP, because I prefer PHP's language construct to ASP. (Plus PHP has a wider community of users, so finding help is MUCH easier!) I prefer PHP over ASP.

AstroTeg

Originally posted by Wraith2700

...
I am really getting mad at javascript because when I write scripts in it it either wont work in IE or Netscape 🙁.

Every JavaScript writer goes through this. Its normal. You can: disable the JavaScript and use server-side or keep working with your code so you can make it work in both browsers (troubleshooting + research + experimenting = working in both browsers).

You'll find JavaScript is the way to go for client-side scripting. PHP and ASP will not work on the client. Period. Your other options are: Java applet, Flash, ActiveX (IE on PC only), or a plugin of some sort (in theory, you could make your own browser plugin).

drawmack

write your javascript so it works in opera and it will almost always work in both IE and NS.

dalecosp

My mitigating factor is almost always cost.

So take a wild guess what I vote for ...

Stinger51

If you are doing verification for example, then it is always better to integrate server side verification as a backup to the JS verification anyhow. That just ensures people can't add unverified data to your DB... <<

I've tried doing that, but have mostly given up. This two-tiered approach got so time consuming that I went back to letting the server (and PHP) do my validations. Mixing JS with PHP can be a real pain in the ass, as most developers who have tried this know.

I know that is not the most efficient way to do data validation. But it is the easiest (for me) and the most secure. And one thing's for sure -- the user can't turn it off. 😉

TheDefender

I personally only do server side verification (Not a fan of JavaScript), The best part is that i have a function I wrote, and it is easily changable for its use in various scripts.

dalecosp

I suppose the reason for doing dual validation is at least two fold:

Consider the user. Telling him he screwed up prior to POSTing the form may save a page load. If he's still using dial up, and many are, perhaps you're not wasting so much of his time.
If the server has to serve an error page, it's more load on the server. For most sites, this isn't a consideration, I guess.

Now, that argument is rather full of holes, but there 'tis.

re 1: It takes a good bit of his time/bw to download all that JS to his browser in the first place, so you're probably not saving much of his time anyway.

re 2: Serving the javascript in the first place is "more load on the server". So there.

I suppose, like most things, it all comes down to what makes the most sense. If you're doing some 3rd party validation type stuff (say, validating a credit card via PHP and then connecting to a secure validation server, for example), it might do well to tell Johnny Q. Idgit that he didn't enter enough numbers before you go to all that work on the server side(s)....

Stinger51

I hear you both. The points I'd like to make in favor of server side validation, which I think you will agree with me, are :

The time factor is not nearly important as it used to be, e.g., worrying about the turn around time during a server side validation. (At least I don't think so.)
Since the user cannot "turn off" server side validation (like he can with JavaScript) you are guaranteed the validation process (assuming your scripts work properly). 🙂
Server hits, while still important, are not as important as they used to be with the increased bandwidth we have all over the place.
You can build an especially nice set of validation functions that will work for just about any data, zip codes, dates, sosh numbers, etc. And I find these functions much easier to build with PHP than I do with JS, for sure.

The only disadvantage I find with all this is that, unless you take the time to repopulate the page the user submits with the validation errors on it, you will piss them off by making them reenter all that data! I know there are various methods to do this, and I have a mixed bag of them. But it is a chore not to be undertaken lightly.

drawmack

Originally posted by TheDefender
I personally only do server side verification (Not a fan of JavaScript), The best part is that i have a function I wrote, and it is easily changable for its use in various scripts.

I do as much validation as possible in JS and then redo all that work, plus some more in PHP.

Why?

Well for a number of reasons.
1) It takes 0 more programming time. I have already written a library of php and a library of javascript functions and written a php page that interfaces with a db table which contains my validation information for my fields so all the js & php calls are handled by this script and it only takes me a couple seconds to configure this table. BTW: the php validation script also draws my html form. It can even handle referential integrity for foreign keys.

2) Most user's don't even know what javascript is let alone that they can turn it off. Therefor most users will benefit from the javascript validation of not having to perform a page load, matter of fact if I choose to they can't even leave the field until the validation is completed.

3) If they have javascript off then they have to wait for a page load, big deal - it's not worth making everyone wait.

4) Personally when I use an online form I prefer ones that use javascript validation because then I don't have to wait for a page load - which even on my cable connection can take time.

5) Only doing frontend (JS) validation is risky because the user can turn JS off. Only doing backend (PHP) validation is risky cause if someone has to wait for a page load to find they have an error they are more likely to abandon the process. However, if I do it in both places I am not taking any risks.

6) My JS library is less then 5k, so almost no load time involved with it. Every site that uses it loads it from a common location on my server, whcih means that if I fix a bug in my JS or PHP libraries I only have to fix it in one place and it is fixed everywhere I use them. Also, this allows for optimal use of browser caching of my JS since it can use the same chached file for a bunch of different forms.