プライバシーポリシーを検討しているところです。
ここに、問い合わせ先の記述を追加しようと思いました。
各端末種別で用意する必要もあり、また、記述ミスをなくす意味で、
店舗基本情報（$arrSiteInfo）を使おうと思いました。

が、よくよく考えると都道府県名は、番号（$arrSiteInfo.pref）です。
そのままでは、$arrSiteInfo.addr01, $arrSiteInfo.addr02と連続文字として利用できません。

そこで、
data/class/pages/LC_Page.php内

この$this->arrSiteInfoに文字列に変換した都道府県名も含めるとともに、
プライバシーポリシーのテンプレートに、
「お問い合わせ先」の記述例を追加してあれば、ありがたいと思います。

気付きとしては良いかもしれませんが、この辺りは微妙なところですね。。


・IDで管理することでそもそもは扱いが容易
・ページを呼び出す度に上記配列が構成される
・都道府県を文字列で呼び出す箇所は多くない

こういったことを踏まえると、
文字列に変換する処理は、該当するページクラスでやってしまえばいいように思います。

が、正解があるものではありませんので参考までに。。

そういえば2.4.4系の時はそういう挙動になっていましたね
いつの間にかなくなってしまったようです

SC_Helper_DB_Ex::sfGetBasisData()を修正すればそのような挙動に出来ると思いますよ

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

本当は、対象のエンティティクラスを作って、結合した文字列を出力するメソッドを作って、テンプレートで読んでやるのが良いと思うんですけどね

＞本当は、対象のエンティティクラスを作って、・・・

この辺りの指標というか、「これが本当だ！」と言う根拠になるようなモノってあるんでしょうか。

似たようなケースで、色々想定は出来ますがハッキリした答えが分からなく迷うことがしばしばあります。。

こんなものは作ってみましたが、本当に良いかどうかは、開発スタイルにもよりますし、一概には言えないかなと。

http://svn.ec-cube.net/open_trac/wiki/EC-CUBE標準規約/開発効率向上のためのTips#エンティティクラスを作成する

# Java 嫌いな方には顰蹙を買いそうです(汗)

EC-CUBE 本体のコードは、連想配列をゴリゴリと書く従来からのスタイルを崩さない方が良いということで、現在のようなかたちになっています。

こんにちは。。。

全くもって、ECCUBEからは逸脱しますが、、、

この直近で、Webアプリケーションシステムを構築する案件があって、、、小規模であったので、

小生の手の内、、、
PHP・Smarty
java
　jsp
　struts
　spring
　seaser2
　click(含むVelocity)
から、code and driveの効率から、clickを採用したものが有りました。

メインフレームからの移行ですと、seaser2辺りまで持っていかないと、信頼性の担保が出来ないでしょう。

>＞本当は、対象のエンティティクラスを作って、・・・

これは、nanasess様からの提言であって、
本人も曰く、結構、javaよりになってまずが、小生の様な、機械語育ちで、現状、『java』を選択し得ざえない身からみると、 『そうだよね』、、、な、『賛同できる点の多い』提言と思えます。

>この辺りの指標というか、「これが本当だ！」と言う根拠になるようなモノってあるんでしょうか。

『小生の知る範囲』では『無い』です、、、ねぇ。。。
OSSへの貢献の多い方からは『これが、今の一押し』な、主張が得られるとは、容易に、想定します。

>似たようなケースで、色々想定は出来ますがハッキリした答えが分からなく迷うことがしばしばあります。。

だと思います。
今では、Internet公開講座を開いてるUnivercityも多いので、そうした、講義を受講して、自らの『解』を得るのも、一つの『道』ではないでしょうか。

『システムの要求値』から、『自らが、見つけ出し、自らが、確信し得た』ものを『まずは良し』とし、、、『壁』を感じた時、新た道を探ることになります。

小生も、直近で、先の状況にあって、、、
.netは、この歳になって、関わっても、もう、手遅れと判断し、
perlはかじったがrubyは知らない、
javaは、四六時中、頭から離れない、
phpは、eccubeでどっぷり、

で、clickを採用した訳ですが、、、もう少し、早く、nanasess様からの提言を得ていたら、選択結果は、変わっていたかも知れない。

が、小規模andイントラネット内だったので、Smartyより、Velocityということで、、、結果は同じだったでしょうが。。。


『ハッキリした答え』は、
・システム構築はGUIと口頭指示(キーボード改めマイク)
・クラッカー対策は自動構築
で、、、Developderは構築案件の実装に集中するのみ、、、
なのですが、我々が『世』に『存在する内に実現される』かどうかは微妙、、、と、いったところでしょうか。。。

># Java 嫌いな方には顰蹙を買いそうです(汗)

これは「jaba嫌い」とは、全く関係ないんでは、ないでしょうか。。。

PHPの連想配列の次世代がエンティティ(コンストラクタ)ではないのでしょうか。。。

どっちが、新旧との議論ではないです。

人とCPUの親和性の議論です。
人とDSPの親和性の議論です。

＞nanasess様
＞Ringo様

大変貴重なご意見をありがとうございました。
エンティティは使い勝手も良さそうですし、一度試してみようかと思います。

個人的には税計算もSQLでやっちゃえばいいんじゃないかと思うんですが・・
SQLを関数化してしまったほうが何かと使い勝手良くないですか？

このデータ作るためにforeachが多すぎる気がしちゃいます。。
update分も逆に冗長になってるような・・updateしたい値以外不要な情報ですよね

※java文化全く無いのでごめんなさい

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690