ちょっと色々考えてみました。

要件がわからないので正しいやり方かどうかは置いておいて、
/data/class/SC_View.php
のSC_AdminView()がコールされた時に適当な変数をグローバル宣言するか、定数をdefineするのが一番書くコードが少なさそうです。

あとはSC_AdminView()で

とされているので、管理画面かどうか調べたいページで

とするのはどうでしょうか？

既存の実装では無理で、新規変数などで追加実装する場合、
\html\require.php
\html\mobile\require.php
\html\admin\require.php
でセットしようと考えています。


とりあえずは継続して、既存の実装範囲で判定する方法につきまして情報をお待ちしております。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

引用：
↑が一番素直ですね

私も深く解析したことはないのですが、ソースを追った感じではtao_sさんと同じく手を加えるならSC_ViewのSC_AdminView、SC_SiteView、SC_UserView、SC_InstallView、SC_MobileViewあたりかなと思いました。

ただ私も、やはりtao_sさんが書かれているように「要件がわからない」のですが...
Helperのところでフロントか管理かを必要とするということは、それによって内部の処理を変えるということなんだと思いますが、具体的にHelperでできたら便利というのが思い浮かばずです（汗）。

現状での要件は、冒頭に書いたとおりです。

以前に、共通クラス内のエラー制御関係で、欲しいと思ったことがありました。
結局、ページクラスまでステータスをリターンする、ダサいコードで誤魔化しましたけど。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

すみません。
引用：
の具体例ってもらえませんか？

「現状、あるかないかが知りたいだけだ」といわれたらそれまでですが（汗）。

> すみません。
> の具体例ってもらえませんか？

SC_Helper_Mail#sfSendOrderMail のメール送信でエラーが生じた場合の対応です。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

ありがとうございます。
無理やり答えさせたみたいで申し訳ないです。

この件とは直接関係あるわけではないのですが、よろしければ下記をご覧ください。
※既にご存知でしたら申し訳ありません。

・カスタマイズと移行の手引（v2.0）
・EC-CUBEのフォーク版

フォーク版の記事のほうに当時の私もズケズケと書いておりますが、2系の形はnanasessさんが作ったもので、そのメインは自動更新の部分と複数カテゴリだったと思います。
1系のページ周りや関数をガッツリとクラス分けしたのもこのときです。

で、カスタマイズと移行手順のほうに書かれていますが
引用：
という分け方で、当時はとりあえず分けて、動くところまで持っていって、後から見直そう的なムードでした。
※私がそう思っていただけかも知れませんが。

結局のところ今でもそのまんまなのですが、見直すチャンスでもあるのかなぁと。

seasoftさんの考えは現状をなるべくいじらず、簡単に実装することだと思います。
※違っていたらごめんなさい

私が思ったのは、その処理はどこでやるべきかみたいな。
場合によっては「ステータスをリターンするコード」がいいのではないかと。
深く考えているわけではないので本当に申し訳なないです...

なんだか大事を書いちゃってますが、そういう意見を他の人からも聞いてみたいなぁと思っています。

呼ばれた気がしたので出てきましたw

引用：

クラスデザインの観点からすると, Helper クラスは, Page クラスで呼ばれるべきです.
本来, Helper クラスから Page クラスを呼んではいけません.
(Page クラスは呼ばないけど, 特定の Page クラスのみ使用するビジネスロジックを記述するのは可)

Helper クラスの中で Page クラスの情報を取得することは, Page クラスのインスタンスに依存した Helper クラスができてしまうのであまりよろしくありません.

ユニットテストも, 非常に書きにくいと思います.

Helper の中身は, できるだけシンプルにし, エラー制御を分岐したい場合はエラー処理用のコールバック関数(or クラス)を用意して, Page クラス側で処理した方が良いです.

実装は大きくなってしまいますが, ステートレスになるのでメンテやテストもしやすくなります.


##
あと, 全くオフトピですが, GW 後半に, やっと EC-CUBE と戯れる時間がとれそうなので, 2.x を作った時から永らく考え中だった, 新しいプラグインの仕組みを作ろうと思っています.

アクセス解析用タグの埋め込みとか, 自作のブロックなどが EC-CUBE 本体が依存することなく作れるようになるはず...

ramrun 様

> seasoftさんの考えは現状をなるべくいじらず、簡単に実装することだと思います。

そうですね。根底には記述量を抑えたいという考えはあります。


> 私が思ったのは、その処理はどこでやるべきかみたいな。
> 場合によっては「ステータスをリターンするコード」がいいのではないかと。

例に挙げた SC_Helper_Mail#sfSendOrderMail の場合ですと、メソッド内で生成した SC_SendMail_Ex をリターンしています。そうなると、ストレートにリターンできないので、クラス変数に退避させるといった、対応が必要でした。

本来は、try catch が使えれば、早いと思うんですけどね。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。