View Full Version : non-PHP files

12-20-2003, 07:10 PM
would it be a good idea to include (or link to) non-PHP files in this way:
src="http://<?php echo $_SERVER['HTTP_HOST']; ?>/images/banner.png"
src="http://<?php echo $_SERVER['HTTP_HOST']; ?>/snow.js"

any comment very appreciated

BTW, how about php files?

12-20-2003, 10:34 PM
i dont see what advantage that has over just typing in the host address, unless the site changes domains often... :confused:

12-21-2003, 12:12 AM
Yeah, that saves you no time whatsoever and is rather pointless.

12-21-2003, 09:38 AM
If you intend to reuse your code (which is a good thing) then your basic idea is far from pointless, as you can reuse that code on any site without worrying about changing it.

Personally I define a variable in a config file (the same place I keep database connections etc , e.g. a file that is always included and ..

define( 'ROOT' , 'http://www.domain.com/' ) ;
define( 'FILE_ROOT' , '/home/user/www/' ) ;
define( 'TEMPLATES' , FILE_ROOT . '/admin/tpl/' ) ;
/* etc.. */

& then e.g.


etc , so whenever I reuse a block of code I never ever have to worry about search & replacing code left right and centre.
OK your code above is simple , but you will find that most larger complex projects will be using very similar logic , even down to defining image and script and user paths & directories etc.

( <?=ROOT;?> is also ( 9/10 ) less typing ;) )

12-21-2003, 11:33 AM
whats wrong with src="/images/header.gif" as this reads from the root directory anyway.

12-21-2003, 12:00 PM
absolutely nothing , but then you may for example decide to use search engine friendly URL's eg

instead of
page.php?var1=var1&var2=var2 .... etc

now you have to recode all of your paths as the links now requires an extra '../' or two (or 3)

now thats just 1 example which happens to fit my preference ;)

however coding absolute paths and then abstracting those puts you in a position where you simply can not lose.

I would say that 50-60% of my day to day work now reuses existing code , especially for generic frameworks of sites/applications , at this point simple steps such as MeGa suggests can reap massive benefits , the more complex the applications get , the more sense it makes.

The ONLY downside to the above is the extra parsing that PHP has to do , and that would be a fair argument on its own , but firstly the overhead is minor , however if you are an efficiency freak (like me) then you negate that overhead with cacheing , be that administrative or at runtime.

The point I am trying to make is that the method noted is not useless , again , far from it and it should not be dismissed without thought.