Re: PHP-Yes, HTML-No --- Why?

It may be by design, but that doesn't mean it's necessarily good.  Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called ..html.  If you want them called any number of things, then be my guest.  I just happen to think presentation matters.
 
As for performance, the numbers are easy to compute.  If you know how, say, the PHP apache module works, you'll see that the hit is absolutely, positively minimal.  If it was otherwise, the inherent overhead of processing dynamic PHP files would stop people from using PHP on any old webserver.
 
My scheme doesn't prevent anyone from using more than one technology.  It's not as if extensions are the only way of determining what's in a file.
 
Your points aren't exactly showstoppers.  If you're confused by having php in html files, you probably shouldn't be anywhere near a computer in case you look at it funny and choke yourself to death.  And as I said earlier, it doesn't stop anyone from using multiple technologies at once, and if a web server struggles because it has to check html files for php when there necessarily isn't any, then it's not going to be very good at running any complex php, as that requires a LOT more work then just checking for "<?php" in a file.
 
Just because it's the "done thing" doesn't automatically make it the best thing.
 
If you don't want to take pride in your work and have messy URLs with weird extensions that don't match the content and query strings unreadable to humans stretching from here to the moon, then be my guest.
 
I'll get back to you with some statistics.
d wrote:
That's also exactly why php files should have php as their extensions -  because that's the way that web servers determine which pages not only  need parsing, but which parsing (actually interpretation not just parsing - hell strict HTML files need parsing!) it needs.
Which was my point. It's a side-effect of the limitations of the web server.
It's not a limitation, it's the design itself. And it's a good design. Your wanting it to be different (just because you don't like it) shows a lack of knowledge and perception and thought.
To tax a web server with the task of parsing everything that has a .html extension, when many, perhaps most of them have no PHP in them whatsoever is just plain stupid.
See how much extra work it gives apache - very little indeed.
I don't agree with that statement at all. Any server serving a lot of pages is going to be slowed down considerably by parsing pages that need no parsing.
So little, in fact, that you don't even notice it.
I beg to differ. I'm sure there are measurements somewhere. Tell ya what, since you are making the claim then it is incumbent on you to provide the data to prove your assumption. I'll be waiting here but definitely not holding my breath.
Thanks for calling it stupid, though :)
You're welcome!
And besides, some web sites have PHP, Perl, jsp, asp and just regular old cgi stuff. How you gonna mash all of that into just .html files?
Not everyone does that. Of course some websites do that, but not all. In fact, not even most. Very few will mix all those technologies, or even subsets of them, on the same server.
Nobody said that one must mix all the technologies. In your scheme one is prevented from even using any two technologies!

BTW: If your ideas here is so intelligent and smart then surely everybody will want one. Let's us know when you're done coding it! ;-)
I don't like that, as the files, when downloaded, are straight HTML.
Well then don't like it all you want however there are good technical reasons for the way it works and to buck such reasons and configure your web server in such a way just because you don't like the way it's done is foolishness.
There are no good technical reasons for it.
Sure there are. Here are two: Speed and Complexity. Also, support of multiple scripting technologies. There are others. Your sole reason for wanting it your way: Think having .html makes it look better! Geeze!
It's done as a short-cut to allow the server to figure out what is what.
Using certain things to identify file types or even say variable types in a language itself is exactly how you do things! Next thing you'll be complaining that having to type <?php ?> is ugly, a short cut and a limitation! Geeze!
I'm saying that figuring out what is what is not always necessary, and I certainly don't want the presentation of my site to be deteriorated due to a perceived problem that isn't even a problem :)
Who the hell do you think goes to a web site and sees say .php in the URL (or .asp, .jsp, .ccf or whatever file extension) and says "Geeze how unprofessional! The presentation of this site is too deteriorated for me to look anymore!" (except for deranged people such as yourself)?
--
Ultimate office automation: networked coffee.

Relevant Pages

  • Re: How do we get there from here?
    ... server-side-scripted html. ... This is a simple example with very little php scripting. ... means that the version of the php pre-processor on your web server must ... >>> The browser never sees anything not sent to it by the script. ...
    (comp.databases.pick)
  • Re: standard coding...
    ... >> So the file, once spat out, should be called .html. ... >> still call php files .php even after they've been passed. ... The web server or the maintainer? ... Making sure your extensions match your content is ...
    (comp.lang.php)
  • Re: PHP-Yes, HTML-No --- Why?
    ... Because the files, when downloaded, are called .php and have absolutely no php in them:) ... But the extension doesn't match the contents of the file. ... Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called .html. ...
    (comp.lang.php)
  • Re: PHP-Yes, HTML-No --- Why?
    ... I mean, the file doesn't contain php when the client gets it, so why should it be named .php? ... Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called .html. ... There extension is not the only way to determine what's in a file. ...
    (comp.lang.php)
  • Re: PHP-Yes, HTML-No --- Why?
    ... So, it's pretty fair to say, that Apache and PHP don't give a damn if they're parsing HTML files for PHP, as as I said, the performance hit is minimal. ...
    (comp.lang.php)