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

"

Nor have I seen any qualification of why it's bad (aside from the fact that you, the one person in this thread, don't like it).

 

Because the files, when downloaded, are called .php and have absolutely no php in them :)

  I mean, the file doesn't contain php when the client gets it, so why should it be named .php?

Simple, because that was the filename that was requested to be fetched by the web server!

But the extension doesn't match the contents of the file.

The fact it's the extension of the file is no reason for the file to have that extension :)  Circular logic is rarely a good reason for anything :)

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.

Again, why? Who cares (besides you)?

Because the server is serving up HTML, not PHP.

So fucking what! (Man you are dense!)

Because the files contain html, not php.

That's pretty obvious.

You may not think that's anything big,

but presentation-wise it is big.

If you request a .jpg, you expect to get a jpeg.

If you request a .mpeg, you expect a movie.  If you request a ..mpeg and get a csv, that's not really cool.

Let's us know when you're done writing your great web server! :-(

I don't have to.  It's called apache, and it does the trick perfectly.

I guess you're not done yet...

 

What? :)

You're proposing to rename .php files to .html files. I guess we're gonna rename .asp and .jsp files to that too. Hmmm... Maybe .cfm files (Cold Fusion?) and .do (I've seen those too). Gee that web server's gonna have much more work to do sorting that out.

And you're forgetting - PHP files can also be just PHP script designed to run without a web server. So now PHP developers are gonna have to name some files .html and others .php - nice consistency there Mr. Consistency! 

If they're not on a webserver, then they can be called .php.

In fact, when I put my php files not on a webserver, say as scripts to be run from the windows command prompt, I call them .xphp,

as I have a handler set up to automatically pass those files to the php executable when they're run, much like a .bat file and cmd.exe.

We're talking about consistency in the web server here, from the client's perspective.  You seem to forget the website is there for the client ;)

If a web server has to parse through a file and look for different tokens to denote which type of file it might possibly be it will be more complex than the current typing system.

I didn't say that.

There are many ways to determine what's in a file, not just the contents, and not just the extension.  It's really not difficult, not complex, and not uncommon.

Which means we can ignore it as it's pretty much meaningless. Again, nobody cares about the damn URL extension here but you. Every other poster in this thread disagrees with you. You are the exception to the rule, the odd man out. By now you should be used to the fact that people just do not agree with your opinion here and do not value this foolish aesthetic distinction that you draw that really hold very little utility. By the very definition and example of this thread any reasonable person would deduce that in general most people don't care. But bang your head against the wall if you must and jump up and down stomping your feet if you want - it's actually quite comical. You configure your web servers for your URL consistency and pat yourself on the back. Whatever floats your boat. I have more important things to waste my time with! 

If you think aesthetics are meaningless, then your websites must look like ***.

Just because no-one else cares about the extensions here, doesn't mean that no-one does.

I can't help it if you aren't as exacting as some people.

  If you can't be bothered to address every aspect of your website, then why bother creating one?

So you don't put line breaks in your HTML or CSS, as that's extra complexity and processing for very little gain.

And as I demonstrated, the extra processing of parsing .html as php is absolutely minimal, to the point where tests can't even determine which one is quicker, as there are many, many other variables that have a much larger impact on performance than that.

you probably shouldn't be anywhere near a computer in case you look at it funny and choke yourself to death.

And you're the one getting bent out of shape because a file says .php instead of .html. Who's confused here? (Hint: You are!)

How is that being confused??  I just want files named to reflect what's in them.  You wouldn't want your html files called .jpg, would you?

And as I said earlier, it doesn't stop anyone from using multiple technologies at once,

Yes but it adds unnecessary complications and processing time based on a whim that only you have!

No complications what so ever.

What so ever? Are you sure? When's your web server gonna be complete there bud?

You keep banging on about that.  I don't need to write a webserver.

As I keep saying, Apache was designed to do just this.  The PHP module for apache was designed to do just this.  Just because you can't see how technology can be used doesn't automatically dismiss those who can.  There are no complications.  If you think it's complicated to have php code in files called .html, then you really do need help.

The extra processing time, as I have demonstrated is nothing.

You're demonstration is non conclusive. Sample size was too small.

150 documents at a time, repeated nearly 50 times?  Too small?

Then please - tell me what you want tested, and I'll test it, and give you the figures.

My tests showed that sometimes it's even quicker to do it this way, which means that there are other factors that play a much bigger part in performance, much more than parsing .html files.

Or perhaps your machine was busy servicing others.

It wasn't.  I conducted the test as accurately as humanly possible, which of course meant no other sites were busy handling requests.

and if a web server struggles because it has to check html files for php when there necessarily isn't any,

It's not a struggle - it's a waste of time! Do you understand the definition of the word efficient?!?

If you think presentation is a waste of time,

Presentation is in the page itself - not its address!

So a great house on a shitty street is just as good as a great house on a great street?

then fine - I can't convince you otherwise.

Nor the other 3 people here. You're batting 1000% - -1000%!

Now who's talking about small sample sizes :)

  Efficiency doesn't necessarily mean you end up with the best product.

Who's talking about products. We're talking about Apache. That ain't even sold!

The website is a product.  You sure don't sound like you know much about commercial web development.

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.

Again, it's unnecessary work. You can't seem to understand that simple concept.

I've demonstrated the "unnecessary work" is absolutely, positively nothing.

No you haven't.

I have.

Just because it's the "done thing" doesn't automatically make it the best thing.

Again, in this case it does. If not then make your own web server and see who else in the planet is interested in such "technology". But don't quite your day gig!

Can you qualify these assertions.

I don't need too. You are the one making the claim. And you are attempting to make it with a very unscientific nor statistically significant sample. Look at it this way. I would venture to get that the guys over at Apache know a hell of a lot more about writing web server software than you. When you are writing such software you make trade offs and decisions. They decided to make this trade off for the sake of efficiency. Now why do you think they did that? Because it's true. Or would you have us believe your tiny test of 150 files, even done 50 times, overrides the experience of these experts? IOW why do you think they set it up this way?

Of course you need to.  You can't just make an assertion then expect others to believe you without proving anything.

Who do you think you are?  The church? :)

Apache didn't decide to make the trade-off.

It's not hard-wired in apache.

You just put ".html" after ".php" on the addhandler line.  You really don't understand this, do you?

I've done tests, and I've seen that the performance hit is nothing.

Tell ya what, package up your "test" and ship them over to the folks at Apache along with a note saying "Why did you guys separate ..html files and .php files. Surely not for efficiency or complexity's sake. Look at these numbers I have here...". After they get off the floor from rolling around in laughter I'm sure they'll getting back to you! ;-)

 

APACHE DON'T SEPERATE THE FILES!  Jesus, man.  Apache provide the mechanism for electing which extensions are parsed by which handlers.  They don't write PHP, or even bundle it with their servers, so why on earth is it their decision to seperate the two?  The two aren't even seperated, for crying out loud.  Just because it shows in the example in the php manual that they only put .php doesn't mean that's how they only intended it to be used.  If you only stick to the examples on the php website, your site will be incredibly basic, poorly coded, and slow as all hell.

I don't have to make my own web server.

You probably couldn't if you tried, which was my point - you don't know the half of the story as to why this technical trade off was implemented. Sure Apache allows you to configure it in the way you want it but they warn direly not to do that because things will be slow. You think they say that on a whim? Hey, perhaps they have a 151 file test! LOL! 

Can you show me where they warn to not do that?

Apache was built to do just these things.  The reason PHP moved from CGI to a native apache module was for exactly this kind of thing.  If you don't understand the technology, then perhaps you shouldn't quit your day job :)

I understand it far better than you as  you continually see fit to show the world. PHP was moved into CGI because PHP was designed to be part of an otherwise HTML file with the PHP intermixed. As such the web server had to handle the reading and rendering of that HTML. It was also moved in there for efficiency reasons instead of having to start a separate PHP process, much like mod_perl.

I'm not talking about CGI.  I've never been talking about CGI here.  I'm talking about the php apache module.

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 measure my work by the quality of the content of the page itself - not it's URL. To me, and everybody else in the world except apparently you, I don't find .php as a weird extension (perhaps because I understand it) nor as any more messier than .html. It's  you that have a fetish with that - not I.

I measure my work by the user experience.

I measure my work by user satisfaction. 

Which is directly proportional to user experience.

I don't want any dirty laundry out in the open.

What they hell is so dirty about having a URL with a .php in it?!?

 

Because the returned file never has any php in it.

I want complete control over every aesthetic, from the quality of the HTML to the quality of the addressing.

i.e. control freak and neurotic personally.

 

No, more like a perfectionist,

or at least someone with pride in their work who doesn't just accept "the done thing" but seeks to find better ways of doing things.

I find .php a weird extension because the files don't contain a single shred of php when the user gets them.

Again, you might not like it but 99.9% of the rest of use don't care.

Clearly you do, as you're still banging on about how supposedly ridiculous it is.

  And, after all, websites are about the user, not the sysadmin or the developer.

Exactly, and if 99.9% of the users don't care and 80% of them have no real idea of what a URL even is, then worrying about whether a file has a .php or a .html extension is a true sign of neurotic behavior. Seek good counsel... 

It all depends on who your audience is for your website.  If you're just writing some blog site or some tiny shop selling CDs, then sure - but if you're writing tools and sites for big clients (read: international banks, financial institutions, car manufacturers, universities, etc.), putting in bids against competing companies, and the contract is worth £100,000, then these things do matter.