CodeMirror はブラウザ上でのソースコード編集に便利なjavascriptモジュールです。
なんでもCMS でもテンプレート編集画面に導入しています。
そのときにIEでエラーが出てしまって嵌ったことがあったので記録しておきます。
IEでjavascriptのエラーが出ると追跡が困難で厄介なんですよね。。
今回の原因は、CodeMirrorで編集対象のtextareaタグがpタグの中に入っていたことでした。(なんと単純)
pタグじゃなくてdivタグのなかにtextareaを入れたら、すんなりエラーが無くなりました。
DOMのinnerHTML操作がinlineのコンテナだとIEではエラーになるそうです。
たったこれだけのことで結構はまってしまいました。
[tips] CodeMirror導入時にIEでエラーが出たら・・・ はコメントを受け付けていません
投稿者: miztaka, カテゴリ: PHP, なんでもCMS, tags: cms, php
なんでもCMS にはこれまで簡易的な画像リサイズモジュールが付いていましたが、もう少しイケてる感じにしようと思い作り直しました。
たとえば、
/files/Sunset.jpg という元画像があったとして、
/icache/w100/files/Sunset.jpg にアクセスすると
こんな感じで幅100pxの画像が表示されたり、
/icache/w200h200bFFFFFF/files/Sunset.jpg のように
余白を指定したカラーで埋めて固定サイズの画像を作れたりします。
一度リサイズした画像はキャッシュされるのでパフォーマンスも問題無いですし、元画像が変更されればキャッシュも更新されるようになっています。
このモジュールはなんでもCMSのモジュールからは完全に独立しているのでいろいろなところに転用できそうです。
/icache/`パラメータ指定`/`元画像のパス名` というURL形式でアクセスすると指定したパラメータのとおりに加工した画像が表示されます。パラメータの指定方法は
w120
h200
w150h150
w200h200bFFFFFF
のようになります。
- wXXX 幅をpxで指定します。(省略可能)
- hXXX 高さをpxでしていします。(省略可能。幅または高さのどちらかは必須)
- bXXXXXX 余白の色を指定します。これを指定すると幅、高さ固定となります。
リンクの書き方次第で様々な大きさの画像を作り出せるので非常に汎用的で使いやすい仕組みではないかと思います。
「なんでもCMS」にリサイズ機能付き画像キャッシュモジュールを追加 はコメントを受け付けていません
EC-CUBEはここ数年勢いを増していてかなり認知度があがってきています。2.11.4も登場してスマートフォン向けのデザインが強化されるなど、機能も充実の一途です。そんななかプログラマーを悩ませるのは、「コードが酷い」ということ。。もう少しきれいなコードだったらカスタマイズしやすいのになあ。。何度そういうため息を漏らしたことでしょう。
こういった状況を少しでも改善していきたいと、まずはDB操作のコードを楽にするためのプラグインを開発しました。
「開発した」といっても弊社で公開している Teeple2 というフレームワークのORマッパーである TeepleActiveRecord をEC-CUBE用に移植しただけなのでたいした工数はかからずにできました。
使い方はほぼ http://code.google.com/p/teeple2/wiki/DatabaseIntro こちらに書いてあるやり方と同じです。(こちらではPDOは使っていません。)
下のコードは同梱したテストケースからの抜粋ですがこんな感じでなにをやっているか一目瞭然のコードがかけます。
$productList = Entity_DtbProductCategories::get()
->join('dtb_category')
->join('dtb_products')
->contains('dtb_category.category_name', 'なべ')
->contains('dtb_products.name', 'なべ')
->order('dtb_products.product_id')
->limit(10)
->offset(0)
->select();
$this->assertEquals('おなべレシピ', $result[0]->dtb_products->name);
こちら から。(無料でご自由にお使いいただけます。)
配布しているアーカイブは以下のようにEC-CUBEのディレクトリ構成と同じ形になっていますので、そのまま配置してください。
(実行に必要なのは data/plugin/activecube 以下のみです。)
data
|- plugin
|- activecube
test
|- class
|- activecube
次に data/require_classes.php の末尾に
require_once DATA_REALDIR . 'plugin/activecube/config.php';
と記述を追加してください。これだけで使えるようになります。
- lowlevelでは EC-CUBEの SC_Query クラスを使用しています。トランザクションの制御などはこちらを使用して行なってください。本ライブラリはあくまでSC_Queryのラップであり、SQLを組み立てやすくしたり、結果セットの扱いをオブジェクト階層構造で扱えるようにしたりしています。
- MySQL, 2.11版のみ用意しています。(私がMySQLしか使わないため。。) Postgresへの対応は少しの修正でできるのではないかと思います。
- Entityクラスにjoinの設定があります。間違っていたり足りなかったりした場合はここを修正するとよいです。
- Entityクラスに自由にドメインロジックを追加することができます。そのような使い方をすると便利かと思います。
- ログはEC-CUBEのsite.logに出力されるようになっています。ログレベルを変更したい場合はActiveRecord.php の 48行目あたりを修正してください。
- 本ライブラリはフリーで提供していますので、不具合等によるいかなる損害についても弊社では責任を負いません。自己責任でご利用をお願いします。
EC-CUBEのDBを「流れるインターフェース」でらくらく操作できる「ActiveCube」を開発しました はコメントを受け付けていません
日本語ロケールのダウンロードはこちら
LifeType はオープンソースのブログシステムなのですが普通と違うのは「ポータル型ブログシステム」だということです。つまり、1つのシステム内に複数のブログ、複数のユーザを作ることができ、ブログ:ユーザは N:N の関係になっています。
WordPressも3.1以降(?)になって複数のブログを1つのシステム内に作れるようになりましたが、最初からそのように設計されているのとそうでないのとでは後々差が出てくるとしたものです。
LifeTypeではサマリーページといって、システム内の全ブログの統計が見えるようなしくみになっています。
用途としては、以下のようなものが考えられるかと思います。
- アメブロやLivedoor Blogなどのようなブログポータルサイト
- 社内ブログシステム
- 多店舗型ビジネスのポータルサイトとして
etc.
このありそうでなかったブログシステムが気に入ったので日本語のロケールファイルを作ってみることにしました。
LifeTypeはきちんと多言語化対応されていて、サイト用と管理用2つのロケールファイルを翻訳するだけでサイトを日本語化することができました。(といってもあわせて1500行ぐらいある大変なものでしたが・・・)
ロケールファイルを翻訳していくとだいたいどんな機能があるかイメージできてくるので、そういう意味でも有意義な作業だったと思います。
LifeTypeをダウンロードして解凍したら locale というディレクトリを確認してください。たくさんロケールファイルがあると思います。ここと、この直下のadminというディレクトリに日本語ロケールファイルを配置します。
インストールプロセスは英語で進みます。 Step6 の Blog Conficurationのところで Languageの選択肢に「 Japanese locale file for LifeType 」というのが出てくると思いますのでそれを選択してください。
既に別のロケールでインストールしてしまった場合も管理画面から変更することができます。
管理画面にログインし、「ADMINISTRATION」タブをクリックします。
中ほどにManage Locales というセクションがあるので、New locale をクリックします。
このページで「Scan Locales」というボタンをクリックすれば、localeディレクトリに手動で配置したファイルが読み込まれて選択できるようになります。
LifeTypeというオープンソースのブログシステムを日本語化してみた はコメントを受け付けていません
「楽観的排他制御」という言葉を初めて目にしたのはJavaフレームワークSeasar2のS2Daoにおいてでした。
それまでの開発ではSELECT FOR UPDATEを多用していた気がしますが、以来ほぼすべてのプロジェクトで「楽観的排他制御」のパターンを用いることにしました。統一的でシンプルな仕様だからです。
以下のようなしくみを言います。
- 全てのテーブルには version列(int)またはtimestamp列(timestamp)を用意する。(version列のほうがよいと思います。)
- レコードの更新をするときに version列もwhere句に含め、set句にはversion列をインクリメントする。(timestampの場合はtimestampをセット。)
- update件数が0件だったら例外を投げる。
- 上記動作をDBアクセスライブラリ(ORマッパー)が透過的に取り仕切る。(開発者は意識しない。)
Teeple2 でこれを実現する方法を解説します。
Teeple2のDBアクセスライブラリ Teeple_ActiveRecordでは、insertおよびupdateの実行前に teeple_activerecord_before_insert, teeple_activerecord_before_update という関数の存在を調べ、存在した場合はこれらを実行した後に insert(update)を実行するようになっています。
このhook関数にはエンティティオブジェクト自身が引数として渡ってくるので、ここでversion列をインクリメントしたり条件を追加することによって楽観的排他制御が実現できるわけです。
例えば以下のようなコードをuser.inc.phpに追加します。
function teeple_activerecord_before_update($obj) {
if (property_exists(get_class($obj), 'version') === TRUE) {
// 楽観的排他制御
$obj->setConstraint('version', $obj->version);
$obj->version += 1;
}
return;
}
Teeple2で楽観的排他制御を実現するには はコメントを受け付けていません