バージョン選択

フォーラム

メニュー

オンライン状況

72 人のユーザが現在オンラインです。 (60 人のユーザが フォーラム を参照しています。)
登録ユーザ: 0
ゲスト: 72
もっと...

サイト内検索

機能要望 > 管理機能 > プライバシーポリシーを記述するにあたり

管理機能

新規スレッドを追加する

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
ゲスト
投稿日時: 2013/6/15 21:00
対応状況: −−−
Re: プライバシーポリシーを記述するにあたり
最後の、、、EC-CUBE、、、からの「逸脱」として。。。

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


SQL86, SQL89, SQL92, SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011
以降でも「関数」が「担保」されるのであれば、それは「良い」かもしれません。

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


この辺りは「M」の作り込みに際して「思慮」が如何に深くなされているかではないでしょうか?
この辺りを、少しづつ掘り下げで行きたい思っています。

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


プログラム言語は、それを提唱した「人」の「その時点での信念でしかない」のですから、
javaもその「信念」を継承出来ない時期に来ており、、、プログラム言語は

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


において、その都度、生まれ、変化する。。。

「php」や「java」、、、「他」、、、を駆逐する「概念」が出て来てきていない今、、、
「何をどうして良いのか」、、、「頭の中」で「ホワイトペーパー」が駆動されていな状態では何も提言出来ないのですが、、、

「はやぶさ」を帰還させた JAXAの「知」も持ってすれば、雑作もないことだとは思うだが。。。
seasoft
投稿日時: 2013/6/15 23:02
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7365
Re: プライバシーポリシーを記述するにあたり
> SQL86, SQL89, SQL92, SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011
> 以降でも「関数」が「担保」されるのであれば、それは「良い」かもしれません。

個人的には、「現状使えて、(実装レベルで)廃止の方向でない」ならば、そこは「良し」かなと思います。

非対応な実装に対しては、リアルな DBMS の関数でなく、DBMS で処理させる為の仕組みでも代替可能でしょうし。


とはいえ、この処理を DB 関数で行うは、今のところ些か否定的な気分ですけど・・・


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

red
投稿日時: 2013/6/16 0:31
対応状況: −−−
登録日: 2010/2/15
居住地: 東京都
投稿: 1568
Re: プライバシーポリシーを記述するにあたり
書き方が悪かったですね、SQLの関数を使うではなく、PHPの関数化するです
SC_DB_DBFactoryを使うイメージです

SQLも部品化して再利用しやすいようにしてやるほうがメンテも、使い回しもしやすいかなと。プラグイン化もしやすいですし


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

seasoft
投稿日時: 2013/6/16 1:51
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7365
Re: プライバシーポリシーを記述するにあたり
> このデータ作るためにforeachが多すぎる気がしちゃいます。。

全てのエンティティクラスで同様に記述するなら、確かに多いような気はしますね。

ただ、ざっと見た印象では、ある程度は基底クラス化できそうなので、相対的な記述数は削減できるのかも。

あと、SC_Entity_OrderDetail#getCategoryIds の foreach あたりは、冗長に書いてしまったポカミスかなとも。


> update分も逆に冗長になってるような

確かにサンプルだけ見ると、そんな印象はありますね。

現実的に重要なのは、もっと実際の実装のように、込み入った時にどうなるかでしょうか。


> updateしたい値以外不要な情報ですよね

最近は、DB の処理が最適化される方向なので、この辺りの心配は軽視できそうです。

そうでなくても、エンティティクラスサイドで、差異のあるカラムのみ出力するとかは簡単にできそうな気もします。


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

seasoft
投稿日時: 2013/6/16 2:05
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7365
Re: プライバシーポリシーを記述するにあたり
> # Java 嫌いな方には顰蹙を買いそうです(汗)

変数で駆逐を目指したはずの「ラクダ」が、メソッドでやたら蘇っている!

これは地味に嫌だ。


【追記】
・・・って、おい! 脳内 PHP コンパイラが Notice 発報。


      public function setOrderId($orderId) {
          $this->order_id = $order_id;
      }

やっぱり、(Java でありがちな) 画一的な setter getter を PHP に持ち込むのは勘弁・・・


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

ゲスト
投稿日時: 2013/6/16 16:35
対応状況: −−−
Re: プライバシーポリシーを記述するにあたり
引用:
【追記】
・・・って、おい! 脳内 PHP コンパイラが Notice 発報。


public function setOrderId($orderId) {
$this->order_id = $order_id;
}


やっぱり、(Java でありがちな) 画一的な setter getter を PHP に持ち込むのは勘弁・・・


「setter getter」に関しては、小生も「わけわかめ」。。。

いづれにせよ、題名から、趣旨が外れて来ましたので、
「Yellow Book for EC-CUBE」なスレッドを起こします。
« 1 (2)
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ


 



ログイン


EC-CUBE公式 Amazon Payプラグイン

統計情報

総メンバー数は88,295名です
総投稿数は109,692件です

投稿数ランキング

1
seasoft
7365
2
468
3217
3
AMUAMU
2712
4
nanasess
2303
5
umebius
2085
6
yuh
1818
7
h_tanaka
1610
8
red
1568
9
mcontact
1240
10
tsuji
958
11
fukap
907
12
shutta
835
13
tao_s
796
14 ramrun 789
15 karin 689
16 sumida 641
17
homan
633
18 DELIGHT 572
19
patapata
502
20
flealog
485


ネットショップの壺

EC-CUBEインテグレートパートナー

Copyright© EC-CUBE CO.,LTD. All Rights Reserved.