kvex2004さんは書きました：

それと、データ数についてですが、インスト直後のサンプルデータしか入っていない状態ですので、レコード数が多いわけでは無いと思うんですよね。なのでよけいに悩んでいました。

「邪魔になる」という表現が悪かったですね
例えば商品のデータを取得した後で表示するというprocess() 関数があった場合に、データの取得と表示の間に割り込ませたい処理があるとします。
現状では、親クラスの関数を使わずに、まるまるコピーした後で割り込ませたい処理を追加するだけの冗長なコーディングをせざるを得ません。
だとすると、今回のアーキテクチャ変更の恩恵が減少してしまうように感じるわけです。

    function init() {
        parent::init();
        $this->objView = new SC_SiteView();
    }
    function process() {
//        parent::process();
        // レイアウトデザインを取得
        $layout = new SC_Helper_PageLayout_Ex();
        $layout->sfGetPageLayout($this, false, "index.php");

    }
    function display() {
        $this->objView->assignobj($this);
        $this->objView->display(SITE_FRAME);
    }

そして、index.phpを

$objPage->init();
$objPage->process();
$objPage->display();

としたところ、無事に表示されました。

テンプレートにアサインする段階で、objViewも道連れにアサインしちゃってますけど

本来であれば, 各 process() 関数にロジック部分は記述せず, ロジックはしっかりリファクタリングしてローカル関数化し, process() 関数は switch などで画面遷移をコントロールするのみにするべきだと思います.
しかし, 現状では 1.x 系列のロジックを, ほとんどそのまま持ってきているため, カスタマイズ時は冗長なコーディングをせざるおえないと思います.

〜〜〜 略 〜〜〜

上記のようなコードであれば, カスタマイズしたい場合, 一部の関数のみオーバーライドしてやれば良く, 表示処理も邪魔にならないと思います.

すべてのコードを上記のようにするには, 大変な労力が必要ですが, 開発コミュニティやコミッターの頑張り次第ではないでしょうか. . .

できれば, objViewは道連れに. . . したくないですよね. . .

本日ひとつだけエラーを発見しました。
管理画面のレイアウト編集でプレビューをおこなうとSmarty errorが発生します。
/user_data/templates/preview/default/top.tpl" in /virtual/comeback/private/ec/data/module/Smarty/libs/Smarty.class.php on line 1095
確かに
/user_data/templates/preview
には/default/top.tplが見当たりません。