一か月近く更新できていませんでしたが、飽きたとかではありません。
やることがおっつかなかったり、先週末DJ土日両方だったりで、
落ち着いて記事を書く暇がとれなかったのです。
最近は、Zendも1.6.2になり、Zend_View_Smartyを拡張して、
pagerのViewHelperを使えるようにしてみたり、今更ながらjQueryを試したりしています。
そちらについても、おいおいまとめていきます。
今週末は土曜日にパーティー行って、日曜日は家で頼まれたプログラム等の予定です。
今月末にはBody & Soulが控えているし、その後はもう年末ですし、
ゆっくり一日寝て過ごせるような日がくるのはまだ先のようです。
楽しいからいいんですけどねー。お金がついていくだろうか。
protectedで定義した変数は、そのクラスを継承したクラスからは参照できますが、継承していないクラスからは参照できません。これはメソッドも同様です。
私は、クラスAにprotected変数がある場合、クラスAを継承したクラスB、クラスBを継承したクラスCからも参照できるものだと思っていました。しかし実際は、孫クラスにあたるクラスCからは参照できませんでした。よくドキュメントに書いてある、サブクラスというのは、子クラスのみをさしていたのですね。
javaのときはどうだったか覚えてないですが、phpではこうでしたってことでメモ。
夜になると寒いって思うような気候になってきたので、お鍋を食べてきました。
前々からうまいよっていう噂を聞いてきた、ちゃんこダイニング若で。
お鍋は二人前を三人で食べてもいいようなボリューム。
サイドメニューも美味しかったです。エビマヨ、手羽先も美味しかった。
どの料理もボリュームがあるので、少なめの品数で注文することをおすすめします。
findManyToManyRowset はとても便利なメソッドです。
以下の様なテーブル構成の場合
・テーブルA
・テーブルB （テーブルAの子テーブル）
・テーブルC （テーブルBの子テーブル）
findテーブルCViaテーブルB
または
findManyToManyRowset(‘テーブルC’ , ‘テーブルB’)
と書くことで、Cの情報を1行で取得することができます。
以前の記事でこの場合、テーブルBのデータも参照のみ可能な状態で、
Zend_Db_Table_Rowsetクラスに含まれていることを書きました。
しかし、テーブルCのデータを更新して、save()した後、テーブルBのデータは、オブジェクトの中から消えてしまいます。
もともとテーブルCのRowsetオブジェクトなので、理解できるのですが、
予想していない挙動だったので、ここにメモしておきます。
参照するなら、テーブルCの情報を更新する前に。ここ大事です。
昨日書いた対処により、Mac OS9 Outlook Expressでは化けなくなったが、
他のメーラーではまだ化けることがあるようでした。
そんなときに、会社のメールサーバ等に詳しい方から情報をもらいました。
日本語メールの本文のエンコーディングは、7bitでないといけないということを。
メールヘッダのContent-Transfer-Encodingの部分です。
というわけで早速変更してみました。
以前、Zend_Mime::ENCODING_BASE64としていた部分を、
Zend_Mime::ENCODING_7BITに変更です。
$mail = new Zend_Mail(‘ISO-2022-JP’);
$mail->setBodyText($text, null, Zend_Mime::ENCODING_7BIT);
これで、文字化け問題から解放されることを望みます。
また新たなメーラーで問題がおこりませんよーにー。
以前https://life.co-hey.com/2008/09/zend-mail-6.htmlという記事を書きましたが、的外れだった可能性がでてきました。
メールヘッダーがbase64になっていたのに、printableで送信していたため、
この対処を入れて様子を見ていたのですが、まだ文字化けする場合がありました。
Mac OS9で、Outlook Expressをの場合に文字化けする現象がでました。
いろいろ試したところ、以下の対処で文字化けしなくなりました。
$mail = new Zend_Mail(‘ISO-2022-JP’);
$mail->setBodyText($text):
上記のように、base64の指定をしない形に戻す。
次に、メール本文の最後に改行を入れる。
これでMac OS9 Outlook Expressでも文字化けしなくなりました。
誤った情報を書いてしまったことをお詫び致します。
最近、ユニクロでちょうどいいサイズのスリムストレートデニムを買った。
これまではブーツカットとか、ゆるめのストレートのみだったので、
スリムストレートは初めて。でも、とてもいい。
リーバイスとかに比べると、生地は薄めでしっかり感はないけど、
履き心地はいいし、薄い分洗濯した後も乾きが早い。
しかも、4000円弱というお値打ち価格。よくて安いのはかなり強力。
消耗品の部類に入るデニムならなおさら、そこは魅力的。
ファッション業界にいる友達の話によると、ユニクロは価格帯から考えると
とても他社が真似できないようないい生地を使っていることは有名だそうだ。
大量生産による恩恵なのか、理由はよくわからないけれど、
安かろう悪かろうというイメージは必要なさそうだ。
最先端って感じのものはないし、そういうものをユニクロに求める人はいないだろう。
ベーシックなラインのもの、時々やるデザイナーとのコラボ商品。
これらは、少なくともチェックする価値はありそうだ。
今回、メーラーによっては、日本語の本文が文字化けするという現象を確認。
調査したところ、通常、本文はPrintableでエンコードされて送信されていました。
なので、ここをbase64にてエンコードするように修正して解決。
$mail->setBodyText($text):
と書いていた部分を以下のようにエンコード形式を指定して設定します。
$mail->setBodyText($text, null, Zend_Mime::ENCODING_BASE64);
文字化けってほんとやっかいです。
select
t1.column_a,
t2.column_b
from
table_a as t1
left join table_b as t2 on (t1.hoge = t2.hoge and t2.make_date <= 'xxxx')
where
t2.column_b is null
こんな感じで、left joinしたテーブルに対しての条件を、
更にwhere句で追加できるとは知らなかったです。
勝手にできないものだと思っていました。
この場合、t2.column_bがnullではないものは、left join on で指定してしまえばOKなのですが、
nullの場合、カラムの値がnullでなくても、make_dateの条件に合致しなければ、nullが
取得されるので、今までは取得結果をループで回してnull以外のデータをはじいてました。
これで、無駄なソースが減る場所がいくつかあったので、メモです。
マニュアルはこちら
http://dev.mysql.com/doc/refman/4.1/ja/control-flow-functions.html
left joinでNULLのときの表示値設定や、カラムの値によって、レコード数をカウントしたり
使い勝手はいいと思うし、実際に使ってみたらとても便利。
case ～ then もいいけど、elseが必要になる場合ってあまりないから、
ifの方がSQL文も短くですっきりしますね。