2015-12-21 27 views
0

我大量生產非常類似的網站,這意味着它們都使用相同的基本組件,頁面,並且都是單一行業特定的。這些是我的低端深度折扣網站設計。這些網站每天都沒有超過20-30位訪問者,所以服務器上的任何額外負載都不是問題。使用define()進行大規模建設時,優點?缺點?

爲了時間的利益,他們都使用相同的組件,雖然它們可能位於不同的位置或者順序不同,但我想寫一個可以包含在每個站點中的定義文件,所以我可以只需調用定義的常量,而不是每年在構建的每個站點上編寫幾百次代碼。此外爲了編輯後期的目的,這將使我的生活更輕鬆。

定義文件將類似於以下內容:

define('UPCONTACT','<h1>Contact Us</h1>'); 
define('ULCONTACT','<a href="contact_us.php">Contact Us</a>'); 
define('UPABOUTUS','<h1>About Us</h1>'); 
define('ULABOUTUS','<a href="about_us.php">About Us</a>'); 

顯然,這是一個非常簡單的例子,但我認爲你的想法。

所以問題是以這種方式使用define()的優缺點是什麼?

+1

我認爲不是使用常量,而是創建模板要容易得多。另外,您必須選擇將其修改爲行 – Ibu

+0

我實際上正在考慮將其用作我的模板系統的一部分。 – user3154948

回答

1

這是非常好的。缺點是,由於您使用的是常量,因此無法爲單個頁面或網站覆蓋它們。

使用數組來代替:

config.php

return array(
    'aboutus' => '<h1>About Us</h1>', 
    'contactus' => '<a href="contact_us.php">Contact Us</a>' 
); 

包括像這樣在您的網站:

$config = include('config.php'); 

然後你就可以打印很容易

<?php echo $config['aboutus'] ?> 

您還可以在需要時更改數值:

$config = include('config.php'); 
$config['aboutus'] = '<h1>About My Company</h1>'; 

這可能是您的最佳選擇。

+0

是的,我更喜歡這個!更有意義,它可以編輯!謝謝! – user3154948

+0

謝謝你接受我的回答:) – tacone

0

它有上漲和下跌。

好處在於,這種方式比從數據庫加載設置(並創建數據庫;創建抽象層...)要快。

缺點在於這種方式不能由客戶端定製。如果他們需要更改,請事先確保該網站是靜態的,並且每次更改都會收取費用。

恕我直言,最好有一些東西由客戶端定製,而其他東西不是。但是,通過以這種方式使用define()(除了可能允許的數據類型),沒有任何技術問題。

+0

這些網站大部分是靜態的,除了事件頁面外,其中的「管理」區域與WP張貼頁面類似。我想我可以向管理員添加另一部分的個人信息,位置,聯繫信息,電子郵件地址等。這實際上很簡單。 – user3154948

0

一個更好的方式來使用ini文件或類似的東西。 (從智能手機輕鬆地編輯,如果它是一個遞歸任務,爲您:)

尋找一個內建PHP函數,可以簡化你的生活

http://php.net/manual/fr/function.parse-ini-file.php

,或者你會更強大,靈活的系統, 隨時隨地模板(找智者,或自制的正則表達式的模板)

尋找我的第一個正則表達式函數(龍年前) Quitting Smarty to do it manually

注:

使用常數不提供你動態修改它們 內嵌代碼,並且是窮人支持的類型(你不能存儲,而不連載例如數組)

0

我建議級聯INI文件:

$conf_dir = dirname(__FILE__); 
$config = array_merge_recursive(
    parse_ini_file($conf_dir.'base.ini'), 
    parse_ini_file($conf_dir.'client.ini') 
); 

的好處是可讀性,執行無力(我想鎖定下來的東西,可以是),你可以在git跟蹤base INI(或任何你使用)而不是客戶端。有一些缺點,但這就是生活。可以肯定,感覺更乾淨,但它們不會比.php更快。

如果你想消除任何冗餘執行(聽,任何「性能優勢」仍然有其「利」),系列化:

<?php 

define('CACHE_DIR', '/tmp/'); 
// where 'http' is a path part that directly follows the app root, and will always 
// be below where this file is called from. 

$ini_cache = CACHE_DIR.'config.ser'; 

if(!file_exists($ini_cache)) { 
    // Build your config in any way you wish. 
    $conf_dir = dirname(__FILE__); 
    $config = array_merge_recursive(
     parse_ini_file($conf_dir.'base.ini'), 
     parse_ini_file($conf_dir.'client.ini') 
    ); 
    // Store it serialized 
    file_put_contents($ini_cache, serialize($config)); 
} else { 
    $config = deserialize(file_get_contents($ini_cache)); 
} 

你可以得到這更有創意,但本質上,這允許您以任何您希望的方式存儲/生成您的配置。如果你想不必刪除每一個變化的序列緩存,你可以添加一個atime檢查:

<?php 

define('CACHE_DIR', '/tmp/'); 
// where 'http' is a path part that directly follows the app root, and will always 
// be below where this file is called from. 

$ini_cache = CACHE_DIR.'config.ser'; 
$conf_dir = dirname(__FILE__); 

$config = array(); 

if(file_exists($ini_cache)) { 
    $client_stat = stat($conf_dir.'client.ini'); 
    $cache_stat = stat($ini_cache); 

    if($client_stat['atime'] < $cache_stat['atime']) { 
     $config = deserialize(file_get_contents($ini_cache)); 
    } 
} 

if(empty($config)) { 
    // Build your config in any way you wish. 
    $config = array_merge_recursive(
     parse_ini_file($conf_dir.'base.ini'), 
     parse_ini_file($conf_dir.'client.ini') 
    ); 
    // Store it serialized 
    file_put_contents($ini_cache, serialize($config)); 
} 

無論使用哪種序列化方法,可以使用以往$config生成方案,你喜歡什麼,如果你使用PHP ,你甚至可以獲得真正的創意/複雜,並且緩存命中到頁面將是微不足道的。

相關問題