デザインテンプレートの探索機能の仕様検討 about ec-cube HOT 26 CLOSED

2.4系の時に戻るってことでしょうか？

from ec-cube.

@nobuhiko 2.4の頃のように一部だけとかではなく、デフォルトも含めてインストール時点で、コピーされて1のフォルダに展開されるイメージです。通常は1だけで事たりるようにしたいと思います。
何かご意見やご懸念あれば、よろしくお願いします。

from ec-cube.

@Yangsin

（本体のバージョンアップで変わる可能性のあるjQueryはデザインテンプレートに同梱された物を使うなど）

この部分って、どこからどこまでなのか結構精査する必要がありそうです。
セキュリティに関わってくる部分でもあるので、デザインテンプレート次第、としてしまうと後々問題が出てきそうです。

from ec-cube.

@konotakanobu
ありがとうございます。
Twigファイル以外でデザインテンプレートが依存しているファイルは同梱する。くらいをガイドラインとして定めるのが限界かなと思っています。
システム側で絶対こうだ！と制御しきれるところでもないかなと。
セキュリティに関しても、デザインテンプレートで担保すべきことと、本体で担保すべきことを分けておく方があつかいやすいかなと思ってますが、いかがでしょうか。

from ec-cube.

@Yangsin 有難うございます！デザインテンプレートで担保すべきことと、本体で担保すべきことを分けることを明言化されれば大丈夫だと思います！

システム側で絶対こうだ！

というのは難しいと思うんですけど

EC-CUBEはこういう方針ですのでどうぞご理解の程を！

って強く言っていくとツッコまれなくて良いかと思います！

from ec-cube.

@konotakanobu
そうですね。デザインテンプレートにとどまらず、カスタマイズポリシーというか、こういう開発を想定しますというのを、できるだけ、明示できるように努めます。
そちらについても随時ドラフトなど共有させていただきます。

from ec-cube.

原本を取っておくのは、新機能で追加されたページが、古いテンプレートにない場合に補完する用ということですか？

from ec-cube.

そうですね。
バージョンアップでページやブロックが追加された場合を想定しています。

from ec-cube.

原本だけ自動アップデートされても、それだれも使わないので無意味なような・・
WPみたいに問答無用でアップデートされてしまうから、部分的に継承できる仕組みが必要ってことならわからなくはないですが

from ec-cube.

ファイルが分散すると grep 面倒だから嫌だな。

from ec-cube.

インストール時だけじゃなくて、存在しない場合に「インストール時点」に限らずコピーすれば・・・と一瞬思ったけど、それでも EC-CUBE 本体の開発が面倒になりそう。

from ec-cube.

@nobuhiko
4の原本がアップデートされても、1のところに持ってこないと誰も使わないという様なイメージでしょうか。
本体がアップデートされて、ページがなどが追加された場合に、何か1のベースになるものが必要かと思いまして。いかがでしょうか。

@seasoftjapan
grepの件は、ルールさえわかっていれば、まだ大丈夫かなと思ってますが、いかがでしょうか。
本体開発が面倒というのは、4を参照しなくしてしまうと、本体開発でも、1を常に用意してでも実際コミットするのは4を。という面倒くささかと思いますがあってます？

from ec-cube.

@Yangsin FTP オンリーな動作環境も多いので、ダウンロードする領域が増えるのは手間です。シェル経由にしても、grep する領域が分散するのは、2.4 で懲りている。

本体開発が面倒というのは、4を参照しなくしてしまうと、本体開発でも、1を常に用意してでも実際コミットするのは4を。という面倒くささかと思いますがあってます？

はい。

3 は、用途を把握できていないのですが、プラグイン同梱のテンプレートをユーザーが書き換えて1に置ける構想でしょうか?

from ec-cube.

今回はそもそも自動アップデートなので、こちらの仕様でよいとおもいます。
基本的には1の部分のみをローカルのレポジトリに保存をしてもらい、それ以外の部分は自動アップデート対象となる感じだと思います。

基本的にはテーマのセットアップ時に1を作成するような形でいけば良いと思います。
今の問題はテーマがバージョンアップに追随できず、テーマを変更した場合に容易に原本の確認ができないことだと思います。

2.4のような半端な分散はよくないですが、他のほとんどのCMSでは @Yangsin さんの書かれている構造になっているとおもいます。
Twigになり、テンプレートエンジンに継承など様々な概念が導入されていますので、そちらも合わせて確認をお願いします。

from ec-cube.

自動→FTP以外でのアップデートに対応していく方針
ですね、すいません。

from ec-cube.

みなさまご意見ありがとうございます。
ご意見を参考に以下のように決めたいと思います。

前提

• SRC以下は直接変更しない。アップデート時に上書きされる。
• プラグインはテンプレートに介入をする。上書きはしない。
• フロントと管理画面で探査順を変える

ディレクトリの役割

管理画面のテンプレートの変更・追加

管理画面のテンプレートを変更したり追加したいものだけ（アップデートされたくないもの）は、app/template/Admin として配置する。

探査順

• フロント
  1. app/template/[TPL-Code]/
  2. src/Eccube/View/
  3. app/plugin/
• 管理画面
  1. app/template/Admin/
  2. src/Eccube/View/Admin/
  3. app/template/[TPL-Code]/
  4. src/Eccube/View/
  5. app/plugin/

探索の挙動image

フロント側コントローラ

render('Entiry/index.twig');

1. app/template/[TPL_CODE]/Entry/index.twig
2. src/Eccube/View/Entry/index.twig
   #3. app/plugin/Entry/index.twig

-> 通常2で確実にマッチする

管理画面コントローラ

render('Basis/index.twig');

1. app/template/Admin/Basis/index.twig
2. src/Eccube/View/Admin/Basis/index.twig
3. src/Eccube/View/Basis/index.twig
4. app/plugin/Basis/index.twig

-> 通常2で確実にマッチする

プラグインコントローラ

利用するテンプレートで上書き可能

render('[PluginName]/View/index.twig'):

1. app/template/[TPL_CODE]/[PluginName]/View/point.twig
   #2. src/Eccube/View/[PluginName]/View/index.twig
2. app/plugin/[PluginName]/View/index.twig

-> 2で意図しないテンプレートを読み込む可能性があるが配置されている事自体がおかしい

管理画面での更新（ブロック編集やページ詳細）

現在利用しているテンプレートを読み込み。なければ標準をもってきて、新たにapp/template以下に保存

読み込み

if (app/template/[TPL_CODE]/block/) {
read(↑);
else {
read(src/Eccube/View//block/)
}

保存

save (app/template/[TPL_CODE]/block/)

from ec-cube.

決定かと思いますが、以下の点で修正できないでしょうか。

カスタムテンプレートについて

以下の点、 #197 で実装した感じで、上記ルールだと若干難しい部分があるので、以下のとおり変更で着ないでしょうか。

• AdminをView以下ではなく、別のtemplateとして扱ってほしいです。
• 解凍 -> インストールを簡単にできるようにするためにユーザーテンプレートを
  /template/[template_name] 以下にする
• admin / default などのローディングの関係を容易とし、namespaceからSymfony系の一般的なルールに近いResourceの中にデフォルトのテーマを入れる。
  src/Eccube/Resource/template/[template_name] 以下にする
• Pluginでの上書きの場合も考え、 app/plugin/[plugin_name]/Resource/template/[template_name] とする。

from ec-cube.

探索順についても、プラグインで定義されたテンプレートを上書きしたい場合があると思いますので、以下が良いかと思います。
上が優先順位が高いとして、管理画面のテンプレートも差し替えができることを考えて。。。

フロント

1. /template/[template_name]
2. app/plugin/[plugin_name]/Resource/template/[template_name]
3. app/plugin/[plugin_name]/Resource/template/default
4. src/Eccube/Resource/template/[template_name]
5. src/Eccube/Resource/template/default

管理画面

1. /template/[template_name]
2. app/plugin/[plugin_name]/Resource/template/[template_name]
3. app/plugin/[plugin_name]/Resource/template/admin
4. src/Eccube/Resource/template/[template_name]
5. src/Eccube/Resource/template/admin

from ec-cube.

@ttsuru
全テンプレートファイルの原本と編集用のコピーという動きはしない という前提で考えたいのですが

AdminをView以下ではなく、別のtemplateとして扱ってほしいです。

app/template では、分ける前提でいますので。可能なら分けたいですが、twig,pathとしての渡し方で悩んでたので、いただいているPRと合わせて確認させていただきます。

Pluginでの上書きの場合も考え、

前提にかいているように、「プラグインはテンプレートに介入をする。上書きはしない。」という風に考えています。テンプレートが独自のページやブロックでテンプレートをもつことを制限するわけではないので、支障がないと判断しましたが、具体的に何か課題になるようなユースケースがありそうでしょうか。

/template/[template_name] 以下にする
admin / default などのローディングの関係を容易とし、namespaceからSymfony系の一般的なルールに近いResourceの中にデフォルトのテーマを入れる。

こちらの2点は、 src/Eccube/View という構成自体や全体のDIRの構成に関わるところなので
#201 でも、ご意見いただいてますのでそちらで、検討させていただき、こちらのIssueでは、テンプレートファイルの役割ベースで、どう探査するかという事に絞らせてください。

from ec-cube.

@Yangsin

app/template では、分ける前提でいますので。可能なら分けたいですが、twig,pathとしての渡し方で悩んでたので、いただいているPRと合わせて確認させていただきます。

そうすると、Adminを別テンプレートとして扱わないといけないと思います。PRを確認ください。

前提にかいているように、「プラグインはテンプレートに介入をする。上書きはしない。」という風に考えています。テンプレートが独自のページやブロックでテンプレートをもつことを制限するわけではないので、支障がないと判断しましたが、具体的に何か課題になるようなユースケースがありそうでしょうか。

通常は上書きはしないルールとしていただければよいと思いますが、例えば、カスタマイズなどでTwigテンプレートを変更する際には、優先順位がPluginが上になっていればPluginの中でTwigファイルをおけたほうが、アップデートに対応をしたカスタマイズがしやすいと思いました。

通常のプラグイン作成ルールでは上書きをしないことをルールとしていただく方がよいとは思いますが、カスタマイズなどを考えると、EC-CUBEデフォルトが最も優先されない順位の方が拡張性が高いと思います。

from ec-cube.

@ttsuru ありがとうございます。

Adminを別テンプレートとして扱わないといけないと思います

PR197 のようにFrontとAdminでtwig.pathをわけているのであれば、大丈夫そうですね。

通常は上書きはしないルールとしていただければよいと思いますが、例えば、カスタマイズなどでTwigテンプレートを変更する際には、優先順位がPluginが上になっていればPluginの中でTwigファイルをおけたほうが、アップデートに対応をしたカスタマイズがしやすいと思いました。

ルールで縛るかシステムで縛るかの悩むところですが、カスタマイズ等の想定であれば、ふつうに上書きしたい既存ページのテンプレートを app/template/[hoge] におけば事は足りると思います。
Pluginで既存ページの上書きをしてしまうと、複数のプラグイン間で上書きをしあって競合が発生しやすくなると思いますが、そちらについてはいかがでしょうか。

from ec-cube.

ルールで縛るかシステムで縛るかの悩むところですが、カスタマイズ等の想定であれば、ふつうに上書きしたい既存ページのテンプレートを app/template/[hoge] におけば事は足りると思います。
Pluginで既存ページの上書きをしてしまうと、複数のプラグイン間で上書きをしあって競合が発生しやすくなると思いますが、そちらについてはいかがでしょうか。

もちろん、プラグインが上書きした場合には競合が発生してしまいますが、例えば、カスタマイズの後のデフォルトのテンプレートを用意し、それを app/template/[hoge] で更新していくオペレーションの方がシステム開発上はデフォルトの状態を管理しやすいと思います。
app/template/[hoge]は運用者が書き換えていくテンプレートなので、たとえばシステムテストを行う場合にもプラグインのテンプレートの優先順位が上の方が使い勝手が良いと思います。

たとえば、デフォルトのテンプレート A があり、システム開発会社が A-2 をカスタマイズで開発した場合、 A-2(app/plugin/[hoge]) という動作が保証された状態をどこかに保管しておきたいのではと思います。
運用者は A-3(app/template/[hoge]) を更新するオペレーションになると思いますが、何かあった際の差分として、A-2 とのDiffが将来的にブラウザで参照できた方がよいかなと思います。

公式プラグインは既存ページの上書きはNGにしてよいと思います。

from ec-cube.

@ttsuru
ご提示させていただいた方法でも、通常のカスタマイズであれば、app/template[hoge]で更新されていくので不都合はなさそうですね。

公式のプラグインなら・・・という、運用ルール的なものは利用者も開発者にも、暗黙知として覚えることが増えるか、管理ロジックが複雑化するので、望ましくはありません。

3系の開発の大きな目的の1つでもある、プラグインの競合をどう制御するかという点から、プラグインの競合が起きにくい状態であることを優先したいと思います。

差分管理的なものが管理画面でできればというのは、ディレクトリの探査で解決するよりも、もうすこしリビジョン管理など別なアプローチが本来かなと。
先の他の方のご意見も実際に利用しているファイルがどこか見通しが悪くなることのほうが、管理しづらいというご意見だと思っていますし、システム開発会社であればことさらWebサーバー上での管理にとらわれる必要はないと思いますので。

他にご意見などあがらなければ、ディレクトリ探査についてはPR197 の分岐を採用して、以下とさせていただければと。

ディレクトリ探査順序

フロント・管理画面共に

1. ユーザーがカスタマイズした・利用しているテンプレート
   2） EC-CUBE標準
2. Pluginのテンプレート

としてFixしたいと思います。

from ec-cube.

@Yangsin

できるだけその方針でいきたいことは理解しました。
私の方ではBoltなどのイメージが強く、Composerで最終的に管理できるようになることを念頭にした考えでの提案になっています。

差分管理的なものが管理画面でできればというのは、ディレクトリの探査で解決するよりも、もうすこしリビジョン管理など別なアプローチが本来かなと。

ここについては理解に違いがあると思います。
そもそもの話として、「ユーザーがカスタマイズした・利用しているテンプレート」にコピーをする前提で、そもそもプラグインでデフォルトのテンプレートの上書きファイルを作っても全く反映されないはずです。
なので、上記で言えば、暗黙知にはならないと思います。

カスタマイズを Plugin として作成し、外部リポジトリとして管理した場合そもそもの管理はバージョン管理でできていると思います。
それとは別に運用者側が日々追加する変更があるとおもいます。
このあたりはバージョン管理の範囲に通常置くことが難しいとおもいます。

機能として、「テンプレートをデフォルトの状態に戻す機能」をぜひ実装したいと思います。
その際に、Pluginのなかにデフォルトのテンプレートを入れておけばその内容からデフォルトに戻し、なければEC-CUBEデフォルトのものに戻すといったことが実現できれば、容易なバージョンアップと、差分の解消ができるのではと思います。

また、現状ではサポートしていないテーマのアップデートも課題に入れると、Pluginや(購入した)Templateが2番目の優先順位にあった方がよいとおもいます。
Wordpressなどでもテーマのアップデートは頻繁にあり、そのあたりも勘定した方がよいかと思います。

以上、長くなってしまいましたが、お伝えしたい内容は以上となります。

from ec-cube.

@ttsuru

意図されている内容については承知いたしました。多数のご意見ありがとうございます。
ただし、3.0としては、テンプレートのバージョン管理やアップデートといったところまで実装をするのは難しいと考えており、またプラグインの競合の安定化に重きをおいておりますので、まずは提示させていただいた探査順ですすめさせていただければと思います。

3.0以降で、デフォルトのテンプレートに戻す機能などもより具体的に検討できればと存じます。

from ec-cube.

こちらまとめをWikiに移しました

https://github.com/EC-CUBE/ec-cube/wiki/EC-CUBE3%E3%81%AE%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E6%8E%A2%E7%B4%A2%E4%BB%95%E6%A7%98

これにてクローズとさせていただきます。

from ec-cube.