NYCPHP Meetup

[inforequest]

Ajai Khattri ajai-at-bitblit.net |nyphp dev/internal group use| wrote:

>inforequest wrote:
>  
>
>>haha never execute a tactic without a defined objective... if it has 
>>side effects that will come back to bite you ;-)
>>(in other words, don't rock the boat doh!)
>>
>>What are the "added benefits" ?
>>
>>- you look more like a Web2.0 app
>>- you make it easier for people who use search engines to find PHP 
>>materials (instead of  .php files)
>>- you make management wonder if you really are using java for web 
>>development like they think you should
>>- you are more "search engine friendly" by the 2004 definition
>>
>>Seriously, how about:
>>
>>- you establish the potential for long-lived URLs that survive a change 
>>in technology (weak excuse, not likely, but theoretically ok)
>>- you are slightly more search engine friendly
>>- your URLs are slightly more user friendly, more likely to get 
>>remembered, bookmarked, etc.
>>- friendlier URLs are more likely to get backlinks, and deep backlinks 
>>are more desireable than root backlinks
>>- it leaves more room for innovation down the road (ties into the first 
>>reason on this list...long-lived URLs)
>>    
>>
>
>Noone wearing their sys admin hat today?
>
>OTOH, making your web server parse all files as PHP will likely increase 
>the load...
>  
>
hmm.. I didn't think he asked for reasons why *not* to do it, did he?

As for increased load, theoretically yes. Ever test it? It depends on 
how many non-php files your web server is serving up, right? How about 
none? How about when you separate display from code? With templates? 
Which templating system? Oh, that's right.. PHP *is* a templating 
system. So then they are all .php files again??

It all depends on how you use it, right?

-=john andrews
http://www.seo-fun.com