placeholderではなく、予め文字列を入れ込みたい
EC-CUBE案件もかなり数が出てきており、入力欄にあらかじめ文字列を入れ込みたい。
と言う要望がきました。テンプレートに入れ込む事も考えましたが、定型文で良いと言うので、jQueryにまかせてしまう事にしました。
{% block javascript %}
<script>
$("#要素名").val("ここに文字列を\nいれます");
</script>
{% endblock javascript %}
普通のjQueryと同じで要素名に対して文字列を入れ込む。と言う少し力業かもしれませんが時間を掛けずお金をかけず対処。
改行は\nで認識しています。\n\rだと2行改行になるので注意。
神宮球場
24日の土曜日にスワローズ vs ベイスターズの試合のレフト参戦してきました。
神宮は実は2年前の4月の連敗の際に行ったっきりでご無沙汰だったことと、7月は半ばまで横浜スタジアムの終末試合が無いのでメットライフドームの試合の後にスワチケで購入。
チケット自体はブロックを選ばなければ、通路挟んで下段は6月8日の時点ではまだまだ選べる状況。
アクセス
今回行きも帰りもちょっと横浜から変則的な行き方をして、乃木坂を利用。
【東海道線：横浜駅】上野東京ライン 高崎行
↓
↓
【東海道線：新橋駅】
【東京メトロ銀座線：銀橋駅】渋谷行
↓
↓
【東京メトロ銀座線：表参道駅】
【東京メトロ千代田線：表参道駅】我孫子行
↓
↓
【東京メトロ千代田線】乃木坂
乃木坂から青山一丁目方面へは青山霊園に沿うように歩けば10分程度の良いお散歩。
R246沿いにセブンイレブンやファミマが有るので飲み物を買う際はこの辺で買うとよし。
入場
まずスワチケはQRコードでのチケット発券の為、QRチケット発券機が外野ライト側にあるので発券。チケット購入列と間違わないようにする。
チケットを受け取ったらバックスクリーン側入り口で入場、チケットさえスムーズに発券出来ればさくっと入場出来る。
今回は14時プレイボールのため12:30開門だった。
場内
やはり神宮と言えばフード、開門後ビジターのベイスターズファンがあちこちのフードに並びスタジアムグルメを堪能。
自分も神宮の名物のソーセージメガ盛り＋ポテトのメガポテセットを購入、13時過ぎの時点でかなり並んでおり購入まで10分くらい掛かる状況。
並んでいる列はベイスターズブルーが8割、さすがにホームのスワローズファンは食べ慣れているのか並んでいる人は少ない。
ブロックはレフト中央付近のコールリーダーの方が立つブロック近くの下段。
背もたれがついているが、中央だったので人が座っていると移動出来ない。協力的なグループの方だと助かるが椅子と椅子の間の通路が狭く四苦八苦する。
買い物や神宮を楽しみたい場合はなるべく通路側、ドリンクやフードは買い込んで動かない！と言うのであれば中央でも良いと思う。（次回は通路側にする。。）
特にビジターで入場が試合開始前後に駆け込んでくる人が多く、足元に荷物を広げて動けない。と言う事もあるのでなるべく時間は早めを狙うべき。
試合中
外野席の広さも関係あると思いますが太鼓とトランペットの音がズレる。特に前目の席だと太鼓の音が1テンポ遅れて聞こえてくる。
特にチャンステーマ時の手拍子がズレやすい。
球場の造りからか応援が響かずドームのような音のこもり方や横浜スタジアムのようなスタンドからグラウンドに投げつけるような迫力にはなりづらい。
＃他球団の場合は違うかもしれないけど
また7回の東京音頭の際に、トルクーヤがレフトに現れ、飲み物を買いにコンコースに出ようとした時に不意にすれ違ったので二度見してまった。
ベイスターズの試合は基本レフトのバックスクリーン側3ブロックはスワローズファンに開放されていて残りのブロックがベイスターズファンのブロックとなる。
タイガースやカープのようにビジターファンが多い場合は全開放となるみたい、ベイスターズももっと青く染められれば神宮レフト全開放は夢じゃないかも。
＃東京ドームはベイスターズファンかなり入るのにまだ開放は半分程度、ここも半分から1/3くらいまでに緩和して欲しい。ドームの抽選ホント当たらない。。
概ねベイスターズファンの皆さんは青を身にまとうので本当にベイスターズビジターカラーである横浜ブルーでスタンドが染まる。
土曜日の試合の観客は概ね27000、3塁側はしっかりとビジターであるベイスターズファンがギッシリ。
ただ1塁3塁側共に空席は結構見える。特に内野の奥側は列で開いている状況。
あとは意気投合した隣のグループの神宮マスターの方いわく、訳あり席のベイスターズ戦なら当日でも買える。ただし柱に遮られピッチャー見えないけど。との情報あり。
やはり当日券はその日、その時のチーム状況もあるからギャンブルになると思うが、どうしても野球が観たい！と言う時は当日券も最終手段としては選択肢に入れられるかと。
EC-CUBE3でカートに入れるボタンをクリックした後の挙動の変更
自分の研究不足と言う事もあるが、EC-CUBE2の時代はカートに商品を入れる際には力技でセッションに入れ込むと言うやり方で結構やっていたがEC-CUBE3になってからノウハウがホントない。
カートに入れる際にはコントローラとしてCartControllerを経由してデータ商品を入れ込んだ後にページをリダイレクトするってなやり方をしている。
/src/Eccube/Controller/CartController.php
#166行目 return $app->redirect($app->url('cart'));
実体としてはカート処理を終えてページをカートページにリダイレクトする処理が書かれている。
このリダイレクト先を任意のページに変更する。
例はトップページへリダイレクト
$app->redirect('/');
各ページへのリダイレクトに関してはgrepすれば大半の遷移先が書いてある。
ただしこの場合、一律イベントとして「カートに追加する」アクションをした場合にトップページに戻るだけの機械なのでPOSTされたページに戻す場合はそれなりにロジックを書かないとダメ。
それとこのままでは
「正常/異常を問わずカートに追加した後の挙動」
をカスタムする事になるので、異常時にどのようなエラーだったかをページに表示させるか。という設計が必要である。
仕掛けどころと勝負どころと
ベイスターズは神宮球場で2勝1敗、石田今永両左腕が躍動し恒例となった勝率5割の壁が目の前に迫ってきました。
勝った試合は素直にプラス要素が多かったのですが、金曜日の井納投手は6回「まで」は完璧だったのが6回に途端に崩れて試合がもつれサヨナラを献上してしまう痛い1敗となった事は間違いないかと。
計算外?
今回の計算外は井納選手が途端にストライクが入らなくなり3点を献上、その後田中健二朗選手が火消しに上がるも上田選手にタイムリーを浴び同点。
この時点で健二朗選手をワンポイントで起用、回跨ぎを経て8回は砂田投手、この砂田投手も2アウトから2点献上
9回、三上投手が投げた時点で10回はパットン投手か山﨑康晃投手だろうと思っていたのですが、この重要な場面で平田投手をチョイス。
この継投の意図としては下位打線を平田投手に押さえてもらい11回12回は盤石のリレーを敷く伏線と言う計算でしたが、平田投手が打たれサヨナラを献上してしまいました。
逆転された9回土壇場で秋吉選手を捉え同点にもちこみ、まだいける！と言う流れがあっただけにダメージは大きく、プレッシャーの掛かる場面での平田投手の不安定さはまだまだ課題。
「流れ」
よく、野球では流れと言う言葉を使うが、それって結果論でしょ？と言われてしまうとぐうの音も出ない。
どうしても長年野球を観ていると、この「流れ」と言う物を感じてしまう事が多々あり自分も使ってしまう。
この試合で言えば間違いなくこの「流れ」をスワローズに渡してしまったのは10回の代走で出てきた関根選手。
筒香選手のヒットでノーアウトランナー1塁、走力に自信のある関根選手を起用した途端に石山投手に牽制死を献上。
さあ得点に！と言う流れが一気に途絶えてしまったと。
これまでの選手起用から言えば筒香選手に代わって守備固めを行う場合の定石は関根選手でしたが、この土日は乙坂選手だった事を考えると
走力と守備力で乙坂選手よりも重用されていたチャンスを関根選手は逸してしまった形になりました。
ただ、この「やらかし」に関して言えば去年から頭角を現した宮﨑選手も守備でのエラーから1軍に呼んでもらえず苦しい時期を過ごし今に至っています。
現状では取り戻そうと必死なプレーも必要ですが、自分の持っているストロングポイント、そしてそれを活かす為にどうするかと言う事に向き合って欲しいです。
特にベイスターズは3,4,5,6番を打つ選手が決まっているだけに、意外性のある7番か、桑原選手とは違った切り込み隊長としての1番
梶谷選手が現状になっているパンチのある2番、関根選手にはどれにもなれる実力が有るからこその厳しい決断だったかと思います。
次に背番号63を見る時、怪我で選手やりくりが苦しい中での起用ではなく、関根が良いから関根！と言われる選手である事を願うばかりです。
EC-CUBE3でマスターデータを追加する
データベース知識を有してる事が前提
管理画面＞設定＞システム情報設定＞マスターデータ管理にプルダウンで新しいマスタデータを作りたい。
昔のEC-CUBE2の時代は簡単に出来たハズだったけど、色々と変わってしまったので追加手順のまとめ
1.DBに必要となるテーブルの作成
mtb_hogehoge と言う新しいマスタデータテーブルを作成する。
他のmtbテーブルと同じ形式に合わせて、必要となるマスタデータを入れ込んでSQLを実行する。
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; SET AUTOCOMMIT = 0; START TRANSACTION; SET time_zone = "+00:00"; CREATE TABLE `mtb_hogehoge` ( `id` smallint(6) NOT NULL, `name` longtext, `rank` smallint(6) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `mtb_hogehoge` (`id`, `name`, `rank`) VALUES (1, 'いち', 0), (2, 'にー', 1);
これでテーブルの用意は完了。その辺のテーブルをdumpして出せば良い。
2.実体ファイルの作成
/src/Eccube/Entity/Master/
上記のディレクトリの適当なファイルをコピーしてリネームする。
今回の例でいけば Hogehoge.phpと言う名前で保存。
class Hogehoge extends /Eccube/Entity/AbstractEntity
クラス宣言の所をマスタデータ名に変更
3.リポジトリの作成
/src/Eccube/Repository/Master
上記のディレクトリから適当なファイルをコピーしてリネームする。手順2と同じ。
HogehogeRepository.phpと言う名前で保存。
class HogehogeRepository extends EntityRepository
クラス宣言の所をマスタデータ名に変更。これも手順2と同じ
4.テーブル定義ファイルを作成する
/src/Eccube/Resource/doctrine/master
周りのマスタデータファイルをコピーしてファイルを作成、Eccube.Entity.Master.Hogehoge.dcm.yml として保存。
定義部分の修正
Eccube\Entity\Master\Hogehoge:
type: entity
table: mtb_hogehoge
repositoryClass: Eccube\Repository\Master\HogehogeRepository
実体ファイル、リポジトリ、テーブルをそれぞれ作成した対象に書き換える。
ここまで出来たら
管理画面＞設定＞システム情報設定＞マスターデータ管理 にアクセスしマスターデータのプルダウンに
mtb_hogehoge が追加されており、内容が反映されている事を確認する。
EC-CUBE3の独自ページのuser_dataディレクトリを除去する
独自ページを作ると
[ドメイン]/user_data/命名したページ名
と言う構成になる。静的ページを入れ込む際に既存のページから階層が一つ下がらないようにしたい。
/src/Eccube/ControllerProvider/FrontControllerProvider.php
// user定義 $c->match('/'.$app['config']['user_data_route'].'/{route}', '\Eccube\Controller\UserDataController::index')->assert('route', '([0-9a-zA-Z_\-]+\/?)+(?<!\/)')->bind('user_data');
これを
// user定義 //$c->match('/'.$app['config']['user_data_route'].'/{route}', '\Eccube\Controller\UserDataController::index')->assert('route', '([0-9a-zA-Z_\-]+\/?)+(?<!\/)')->bind('user_data'); $c->match('/' . '/{route}', '\Eccube\Controller\UserDataController::index')->assert('route', '[0-9a-zA-Z_]+')->bind('user_data');
元のデータをコメントアウトして定義されたroute直下に宣言を書き換える。
独自ページ作成画面では /user_data/ がついているが、アクセスを
[ec-cubeのドメイン]/[作ったページ] でアクセスすると表示される。
※※ 既存のページと同じ命名にするとぶっ壊れるので注意 ※※
※※ 既存のページが動かなくなったので没 他のロジックをいじる（予定） ※※
CentOSの時計合わせ
開発用のローカルマシンにVMWareでブリッジ接続して開発をしていると立ち上げた当初は良いが日に日に時刻がずれてくる。
理論上はシステムをサスペンドした状態にしてるから再度VMWareを起動すると中断した時間から再開なのでそりゃズレてくると。
$ date date Wed Jun 21 17:59:14 PDT 2017
ん…？PDT？
これってロサンゼルスの時刻になっちゃってるって事か。と言う訳で時刻合わせをする。
$ cp /usr/share/zoneinfo/Japan /etc/localtime $ vi /etc/sysconfig/clock
ZONE="America/Los_Angeles"
これを
ZONE="Asia/Tokyo"
こうする。
んで時間の確認
$ date Thu Jun 22 10:11:31 JST 2017
JSTになったのでこれで時刻の同期が取れた。
