一言で片付けると「include pathが通っている(あるいは通す予定)のところに、MagicWeaponのソース(ファイル)を一式置いておく」ことが求められます。
っちゅわけなので、必要なのは
・ファイルを設置する場所決めて
・ファイル群をゲトって
・ぶち込む
の３工程。おまけでもう１工程あると楽なんで、そのあたりも含めて。
まず「ファイルを設置する場所」ですが…まぁぶっちゃけお好きに。
…ってだけだと指針になりにくいので、いくつか指針の草案を。
・「専用サーバ」かつ「単一サービスを運用する or ちゃんと管理された複数サービスを運用する」なら、例えば「/opt/htdocs/MW/」とかがお勧め。「/var/httpd/MW」とかってのもまぁあり。
・「共有サーバ」または「実験的に用いる」場合、ログインしたときの、いわゆる「カレントディレクトリ」直下にMWってディレクトリを切ったりすると割合に幸せです。で、もし「カレントディレクトリがDocumentRootを兼任している」場合、mod_rewriteが使えるのであれば
RewriteEngine on RewriteRule ^$ プロジェクト用ディレクトリ/wwwroot/ [L] RewriteRule (.*) プロジェクト用ディレクトリ/wwwroot/$1 [L]なんて書いておくと、色々と面倒が省けたりします。
ダウンロード一覧からでもよいのですが…ごめんなさい、たぶん、割とメンテナンスがなってません orz
http://sourceforge.jp/projects/magicweapon/svn/view/PHP.tar.gz?root=magicweapon&view=tar
のレポジトリからのダウンロードを、わりと強めにお勧めいたします。
お好きなソフトで、あらかじめ決めておいた場所にずずずんとぶち込んでください。tar ballのままでぶち込む人もいないかとは思いますが、一応念のため、ご注意くださいませ。
初めから「サーバ上でwgetする」ってのも賢いかと思われますが、その辺はお好みで。
MagicWeaponは、概ね「ファイルを設置する場所」にinclude pathが通ってることを前提にしています、前述したとおり。
なので、以下のようなファイルを作っておくと色々と手間が減ります。
ファイル名は、まぁお好みで。おいちゃんは「mw.conf」って名前にしてます。
<?php // Frame workのクラスが一式インストールされてる場所 $dir = "ファイルを設置する場所"; set_include_path(get_include_path() . ":" . $dir);
いやまぁ別に「広大なのっぺりしたディレクトリにありとあらゆるファイルが渾然一体としてまったりとした」状態を否定はしませんが、扱いにくいからやめませう。つまりは否定ｗ
とりあえずまず何よりも、今回のWebアプリ(プロジェクト)で１ディレクトリをまず切ります。
んで。その中に、まずは以下のディレクトリを切っておきましょう。
conf lib wwwroot temlpate log
何はともあれ設定ファイルです。最低限設定したいものを盛り込んだ設定ファイルは、概ねこんな感じざんす。
ファイル名はまぁなんでもよいのですが、config.confって書いてることが、おいちゃんは、割合に多いですかねぇ。
あわせて、DIの話も。んと…以前はconfig.confに書いていたのですが、ちと機能的に「増えてきたし切り出したほうが効率的だなぁ」的出来事がありまして、切り出しました。
「でぺんでんしぃ いんぢぇくしょん(Dependency Injection：依存性の注入)」とかって名前が付いてますが、現実的には「工場(ファクトリー：factory)」程度の機能をご想像ください。
MagicWeapon のプロジェクト Wiki ページへようこそ。 さて…なに書こうかねぇ(笑
とりあえず、このPageは「開発者およびその周辺の人たち向け」なので、単純な使い方とかはまた別Pageにまとめる予定。
2011/03/吉日：
久しぶりに文書書きます。
ちと本格的に使いかたを。書きあがったらまたそのようにお知らせをいたします ノ
2008/01/10：
一発目がメモかよ特集ｗ
別ウィンドウでデバッグトレース出力が出るとうれしいな。モード切替で。
console.log()にはき出してくれても素敵かも。
エラー系の制御は欲しいですね。 特に最初にMWを導入する時など、何が原因で稼働していないのか調査に時間かかることもあると思うので。 PHP4バージョンのMWを導入時に2日3日ハマった記憶がありますです。。。
2007/12/24：
イブになにやってんだスペシャルｗ
携帯関連とか少しものができあがってきました。
2007/11/22：
DBクラスのクラス名変更しました。
…本来ならかなりクリティカルな変更ですが。実際には多分DBマネージャつかって、誰一人として生のDBハンドルクラス触ってないと思うので(笑
これで、PEARと(大文字小文字が違うのに)クラス名一緒とか言われる状況を避けられます。
ついでに、これはまだ未定ですが。DBハンドルクラスインスタンス内に、SQL作成用のクラスインスタンス持たせちゃう予定です。
その辺は後日。
それ以前ｗ
uncheckingディレクトリは「コメントとか復帰値とかがまだ未チェック」なブツです。
一応がるが一通りコメントとか修正する予定ですが、手伝ってくれる人いたら是非にもよろ。っつかぶっちゃけ多すぎ(苦笑
ついでにドキュメンターも鋭意募集中ｗ
今後の予定。
とりあえず、まずとにかく「PHPDoc用のコメント入れて」「復帰値をルールに従って変更して」ってのをやって、0.1.0として出します(これはLHAにもする予定)。
その後は色々とイメージしてる改修を。最低限、いくつか現状想定している部分(特にMVC関連のクラス)を落ち着かせて、かな。
1.0.0をどんなバージョンにするかは現状まだ未定。まぁあんまりその辺細かくは考えてないんだけど(笑
とりあえず使えるクラスから使って、なんかあったら連絡くださいませ。
使用マニュアル
MagicWeapon の使用マニュアルを書いてみます。まずはここの文章を一通り読んでいただけるとありがたいです。
インストール方法草案
インストールの方法への「提案」です。
使い方の提案
MagicWeaponをどんな風に使うのかの「提案」です。
使い方の提案MVC編
MagicWeaponを「MVCありありフレームワークとして」どんな風に使うのかの「提案」です。
空メールで会員登録携帯編
携帯サイトでありがちな「空メール打って～の登録してぇの」な流れを簡単にやる一案です。
clump系覚え書き
MagicWeaponの特徴的なクラス群「clump系」についての覚え書きです。
conv覚え書き
MagicWeaponの特徴的な？置換エンジン「conv」とその周りについての覚え書きです。
開発陣用各種文書
開発の時のルールとか。
要望各種
とりあえずメモ＆考察用に。
セッション情報の保持の仕方
ログインクラスとか自作なので。$_SESSIONとか使いたくないんで色々作ってます。
雑文置き場
整理できてない文書をとりあえず置いてます。
大抵、推敲もなんもあったもんじゃない文章なので、覗くときは「そ～っと覗いて」「生暖かく見守って」ください。
データクランプ説明書
ある意味、MagicWeaponの最大級の特徴の一つとも言える(ついでに言うとMagicWeapon内で尤もメタボなクラスでもある(苦笑) )、data clumpと、その継承クラスであるdata clump validator(通称validate clump)の「基本的な使い方」と「お便利な手の抜き方」を書いてみます。
wikiの文法は http://sourceforge.jp/projects/sourceforge/wiki/Guide%2FWikiSyntax#h2-.E8.A6.8B.E5.87.BA.E3.81.97 を参照。
SVNは http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/?root=magicweapon ここから最新のソースがげとれる。
PHPDocumentorによるドキュメントを作ってみました。 http://maporfic.m-fr.net/mw_doc/ http://maporfic.m-fr.net/mw_doc_s/ こんなあたりからどんぞ。
]]>PHP用フレームワーク「MagicWeapon」の、概ねチュートリアルです。 「概ね」というのは、単純に使い方だけではなくて、その「裏側にある思想」も書いてあるからです。 思想とかいうと格好よいけど、まぁ大抵は本音と愚痴と悩みに躊躇を足しこんだカルテット B-p
フレームワークの使い方も去ることながら。 そこから、内側にある「おいちゃん的思想：我留流」を汲み取っていただければとってもうれしいざんす。
注意 わりと「身内向けの文体」なので、そのあたり平にご容赦のほどを。
最低限の知識を先に
MVCとは？
テンプレートエンジンとは？
MWでのMVCの流れ
まずは基本のHelloWorld
最低限のinstall
configを書く
mapファイルを書く
modelを書く
temlpateを設置
デバッグプリントの出し方
ログの吐き方
Smartyを使うときは？
共有サーバで使うとき用の一案
テスト環境と本番環境の共存のさせ方
環境依存系configの切り分け方とデプロイの仕方
mailの書き方
とりあえずmockupを設置
cgi requestを取得する
validateチェックとエラー用の転送
転送処理の細かい流れとbagのお話
mailを送る(雑)
input -> confirm -> fin
テーブルを切る
DB ハンドルの設定
data_clumpの(とりあえずの)設定
入力を受け取る
validateの設定をしてみる ＆ validateチェックをしてみる
データを書き込む
DBの情報を出力する
単純なlist出力のお作法
Pagingのお作法
「検索条件付き」のお作法
「検索条件付きでのPaging」のお作法
考察ネタ：レコードの削除はどうする？
１レコードの詳細表示と修正
とりあえず１レコードを表示してみる
set_from_cgi_inputとset_from_cgi_editの使い分け
mailの書き方 改良編
data_clumpを作ってみる
validateをdata_clumpに任せた状態で、プログラムを改修してみる
管理画面と認証系の書き方
とりあえずmockup
標準モジュール使って認証させてみる
認証後Pageの閲覧
認証の種類を増やす
frontの一部を認証系にしてみる
認証周りってどうなってるの？
関所について少し
「アプリ全体」で特定の処理をしたい
「管理画面全体」or「front全体」で特定の処理をしたい
携帯サイトのためにその１
configの設定のしなおし：文字コード
単純に携帯サイトだけの場合(view classの変更
PCと携帯(とスマフォ)で共存させる場合(スイッチ付きの変更
携帯サイトでの認証
先にセキュリティの話
(あきらめて)契約者固有IDで認証をしてみる
バッチとの共存
バッチを作るための基本
設定のどのあたりが「Web側と共有」出来ているのか？
「空メール受信を契機にした会員登録」の実装で学ぶバッチの実例
設定して
空メールを受け取って
mailを返して
web:その他入力がない場合の処理の流れ
web:その他入力がある場合の処理の流れ
data_clumpに追記してみる
ラジオボタンの書き方
チェックボックスの書き方草案
出力要素が増えてみた
ど～しても、情報を暗号化しておきたい
大規模にむけて
DB分散とmemchachedのやり方
とりあえずMVCに関しては適宜ぐぐってください…だと色々とぶれるので。
手前味噌恐縮ですが、以下を先にご一読くださいませ。
http://www.phppro.jp/school/oop/vol4/1
http://www.phppro.jp/school/oop/vol5/1
MWでは
という流れになります。なので、基本的には
という、controller主体の動きとなります。
また、このために、１プロジェクト単位でみると
というインスタンス割り当てになります。
…っていきなり書かれてもよくわからないと思うので。
わからなくなったら適宜戻ってきてください。そのうちだんだん「あぁこーゆーことだ～」って思えるようになりますんで。
九分九厘、index.phpとかいう名前になりますが、別に固定ではありません。
中身は多くの場合
<?php
// MW config
require_once('mw.confへのフルパス');
// config
$bp = 基準ディレクトリ;
$config = $bp . 'configファイルの位置';
//
require_once('controller.inc');
//
$cobj = new controller;
$cobj->set_base_path($bp);
$cobj->set_config($config);
$cobj->run();
最低限必要なのは以下のとおりです。
# 入力(内部処理エンコーディング) inside_encoding_type = EUC # 出力 output_encoding_type = SJIS
いやまぁ内部UTF-8でもよいのですが、なんとなくEUCのほうが実績が多いのでEUCにしてます。
出力は、PC系ならUTF-8のほうがベターかと。携帯系だとsjisでほぼ決まりですね現状。
# map ファイル mapping_file_path = マップファイルをフルパスで
MVCのmodelを決め打ちしてるファイルなので、これがないといろいろ始まりません。
mapファイルの書式
# DB設定 db_config_path = DB設定ファイルをフルパスで
DB使うならほぼ必須だと思ってください。
なお、このファイルにはDB接続のパスワードが書いてあるので。documentroot以下に置くのは厳禁です。
DB設定ファイルの書式
# 共通ルーチンが入っているPath。include_pathにくっつけてもらえるから便利。 # マッピングファイルに書かれているビジネスロジックの場所 common_include_dir = 基準になるディレクトリ。最後は'/'で終わりませう。
基準になるディレクトリをひとつだけ指定しませう。
# テンプレートファイル template_dir = テンプレートが入ってるディレクトリ。最後はやっぱり'/'で。
HTMLテンプレートが入ってるディレクトリ名をここで指定します。
# 認証config session_config = 認証設定ファイルをフルパスで
認証系の場合、自力でどうにかしてもよいのですが、この設定ファイルを使うとめっさ便利です。
認証configの書式
configファイルをまとめると大体こんな感じです。
# 入力(内部処理エンコーディング) inside_encoding_type = EUC # 出力 output_encoding_type = SJIS # map ファイル mapping_file_path = マップファイルをフルパスで # DB設定 db_config_path = DB設定ファイルをフルパスで # 共通ルーチンが入っているPath。include_pathにくっつけてもらえるから便利。 # マッピングファイルに書かれているビジネスロジックの場所 common_include_dir = 基準になるディレクトリ。最後は'/'で終わりませう。 # テンプレートファイル template_dir = テンプレートが入ってるディレクトリ。最後はやっぱり'/'で。 # 認証config session_config = 認証設定ファイルをフルパスで
適当なmodel基底クラスを継承します。多分、普通ならbase_model、認証系ならbase_model_authってところでしょう。更なる基底としてbase_model_skeletonがありますので、必要に応じてお好みに。
とりあえず(ほぼ)共通する内容なので、まとめて。
public function initialize() { }
public function finalize() { }
modelクラスのインスタンスが生成されるタイミング＆破棄されるタイミングでcallされます。再帰callの場合入れ子でcallされます。…が、まず確定で「処理必要ない」と思います。
基底クラスでabstract宣言してるので、実装だけはしておいてください。
public function execute()
public function execute_auth()
このどちらかのメソッド(名前みれば一目瞭然ですが、authついてるほうが認証系です)がいわゆる「マウントポイント」になります。ので、処理はこのメソッドを起点にしてください。
で、実際必要なのはこのインスタンス内で持ってるエトセトラだと思うので、いくつかかいつまんで。
$_POSTとか$_GETとか、あまつさえ$_REQUESTなどを生でcallするのは厳禁です。厳禁ですったら厳禁です(理由は省略。とりあえず、magic_quoteとロギング関連と文字コードという単語から適宜妄想してください)。
上述のリクエストはすべて、cgi_requestクラスがまかないます。とりあえず
$req = $this->get_cgi_request();
$s = $req->find(cgiでの名前);
$array = $req->find_array(cgiでの名前);
$dbh = $this->get_db();
でどうぞ。あとは、このハンドルにqueryとかいうメソッドを使うと簡単にDBにアクセスできます。
なお、基本的には「model内でダイレクトにSQL書くのは厳禁」です。そーゆー処理はクラスに弾いてラッピングしておきませう。
CONV使用前提です。で、
$conv = $this->get_conv();
auth限定ですが。
$id = $this->get_id();
前提であれば、
$this->make_body_with_conv(テンプレートファイル名);
hiddenはとりあえず(ほぼ)論外として。
セッション情報は、session_dataクラスからの派生クラス(普通はsession_data_dbクラス)を使って格納してください。
require_once("session_data_db.inc");
$sb = new session_data_db;
$sb->set_db(DBハンドル);
$sb->set_id(個人が特定できるようなID);
が大前提。直前にデータがある可能性があれば、この後で
$sb->read()；
$sb->fix_session();
データは
$sb->add("name1","value1-1");
$sb->write();
使い終わったら行儀よく
$sb->del();
SQLを(万が一)手で作るときは、sql_utilまたは最低でもsecurityクラスを使ってきちんとエスケープ処理をしてください。
convに出力用置換データを渡すときもsecurityクラスでのエスケープを忘れずに(これは、後でsecurity_convとか作るかもしれないですが)。
data_clumpの派生クラス…ではなくて。data_clump_valudatorの派生クラスを用意します。
自力で書くのもありですが。ぶっちゃけ、junk box http://www.gjmj.net/ にある data_clump_validator作成 http://www.gjmj.net/make_clump.php 使うほうが楽かもです。
フォロー必要ならコメントよろしく(笑
端的に書くと「validatorもしてくれるclump」です。そのまんま。
現状実装してるtypeは
any 種類問わず
alphanum 英数字
numeric 数値：minとmaxの意味合いが変わる
email email
url URL
digit 数字
dir ディレクトリ
くらい。
alpha 英字
alpha_lower 英小文字
alpha_upper 英大文字
xdigit 16進数の数字
tel
jzip 日本の郵便番号
については実装する…かもしれない。ので、欲しい人は挙手。
完了はともかく、入力と確認はそこそこ面倒。特に入力画面は「エラー画面兼任」なので厄介。
厄介なら自動化ってことで validator_util_with_conv で使えるテンプレ自動作成 http://www.gjmj.net/make_template.php をどんぞ。
以下メモ。 性別 <INPUT type="radio" name="customer_sex" value="***sex:1***">男 <INPUT type="radio" name="customer_sex" value="***sex:1***">女<br>
チェックボックスも似たような書式。
都道府県はjunk boxにしまってある。
base_model(素)なりbase_model_auth(認証必須)なりbase_model_ambiguous(認証してもしなくても)なり、それぞれのwith_mobileなりを適宜継承。
$tmp_name = "てんぷれのファイル名";
$conv = new f_conv;
// 出力
$this->make_body_with_conv($tmp_name);
中身はとりあえずこんなもん。ここまでで一回test。エラーつぶして。mapfileとか書き忘れてない？ 大丈夫？
テンプレはjunk boxで作れるので。単純にまずは遷移できることを確認。
XXX
入力チェック。validator_util_with_convのcheckメソッドで。
突っ返すときは$convにはすでに情報入ってるしbag機能で持ちまわれるので
$this->recursive_on();
$this->set_recursive_command(つっかえすコマンド多分input);
//
return ;
で。
以下書いてない orz
]]>大雑把に言うと「あるデータの塊を一意に扱う」ためのクラスです。とりあえず「１塊 == DBの１テーブル」であると認識していただいて差し支えはまったくありません。
この特徴のため、いわゆる「O/Rマッパー」的な側面があります。
何はともあれclassを作成して扱ってみましょう。
まずファイルの格納先ですが。どこでもいいんですが、個人的には libディレクトリ内に clumpというディレクトリを切って。clump系のクラスはすべてそこに突っ込むようにしています。だってわかりやすいしｗ
概ね「テーブル名_clump」というクラス名にする事が多いのですが(混乱がない)、まぁその辺はお好きに。
各classは、data_clump、もしくはdata_clump_validatorのいずれかの継承クラスとして作成してください。以下、説明は全て「data_clump_validatorを継承した」前提で執筆します。
とりあえず。ほぼ定型処理として以下を入れてください。
public function __construct()
{
//$this->init();
parent::__construct();
}
public function init()
{
parent::init();
$this->set_element();
}
/**
* 基本的な情報の設定
*
* テーブル名およびカラム名を設定する
*
* @access protected
*/
protected function set_element()
{
// テーブル名の設定
$this->set_table_name('team_topic_res');
// 要素の設定
// $inname, $cginame, $tmpname, $dbname, $keyflg
$this->push_element('res_id','','','','pk');
$this->push_element('topic_id', '', '', '', '');
$this->push_element('client_id', '', '', '', '');
$this->push_element('comment', '', '', '', '');
$this->push_element('write_date', '', '', '', '');
// validate項目とvalidateの仕方の設定
// $name, $type, $must = false, $min = -1, $max = -1
$this->make_validate('comment', 'any', true, -1, 500);
}
こんな感じです以上…では切ないので色々と。
set_table_nameはまぁそのまんま。ここうまく使うとちょいと面白い事が出来るですが(大規模なんかで「IDのhash値でテーブル名分ける」とかね)、とりあえずは素直にストレートに。
「デフォルトとして、class名から"_clump"を削除した値」って事も想定はしましたが、現状実装はしてません。
とりあえずdata_clumpの最大級の眼目の場所。簡単に書くと「内部呼称とHTML内のINPUTエレメントのnameアトリビュート値とDBのカラム名とテンポラリテーブル(セッションテーブル)に格納するときの一時的な名前と、あとはプライマリキーであるかどうか」を一気に指定していきます。いやまぁなんていうかほぼそのまんま。
基本手でごりごり書いていくですが。一応、
なんてのが、運が良ければ、作成の…0.5助くらいにはなる、かも…しれません。多分。あるいは。もしかしたら。
ちなみに。空文字の場合のデフォルトは「内部呼称(inname)の値」。特に問題がなければ、一緒にしちゃって良いように思われます。気になる人や問題がある人は個々に設定してください。
チェック項目用のListです。データの形、必須か否か、最大値、最小値がそれぞれ指定できます(ぢつはもうちょっと柔軟に出来るのですがそれは後ほど)。
データの形は、validator_clump というclassにそのまんま依存しています。で、原稿書いている 2008/09/02 現在。
に対応しています。いやまぁisクラス書きゃ対応追加は容易なので…要望はお早めにｗ
なお。数字と数値は「文字か値か」の違いです。具体的にはmaxとminの指定で差異が発生します。
$this->make_validate('age', 'numeric', true, 0, 120);
は０歳から120歳までをフォローしますが、万が一これで
$this->make_validate('age', 'digit', true, 0, 120);
以下、model(base_modelとかその系列)の継承クラスのexecute系メソッド内で使う事を想定しています。
そうでない場合は、適宜かみ砕いて都合良く読み替えたり脳内置換したり脳内補完したりしてください。
また、以下「hoge_clump」というクラス名で説明をしていきます。
// cgiリクエストが詰まったオブジェクト取ってくる
$req = $this->get_cgi_request();
// hogeクラスを「にゅ～」
$hobj = new hoge_clump();
$hobj->set_from_cgi($req);
いぢょ。これで、clumpクラス内にデータががっつり入りました。
// DBハンドル取ってくる
$dbh = $this->get_db();
// hogeクラスを「にゅ～」
$hobj = new hoge_clump();
$hobj->set_db($dbh);
$hobj->set_value('key', $key, false);
$ret = $hobj->get();
これで「keyというカラムが$keyな値であるデータをDBからいただいてきて腹ん中に修める」事が出来ます。
このパターンだと「プライマリキーとして指定したものでしかWHERE出来ません」が。例えば「今回は email という値から検索したいなぁ」なんて時は
// DBハンドル取ってくる
$dbh = $this->get_db();
// hogeクラスを「にゅ～」
$hobj = new hoge_clump();
$hobj->set_db($dbh);
$hobj->set_value('email', $email, false);
$ret = $hobj->get_nopk();
ごくごくシンプルですが。get_valueメソッドを使います。
$email = $hobj->get_value('email');
set_valueを使うのですが…ここはちょいと色々と。
O/Rマッパ的要素があるために。set_valueは、呼び方というか引数一つで「DBと連動したりしなかったり」します。
ちょいとその辺の要素を分解整理してみましょう。
まず。「getやget_nopkをcallするために、keyを指定するset_value」では、当然ながら「DBと連動しちゃ困ります」。
なので、この手の用途の時には、第3引数に明示的にfalseを指定します。前述してるソースですが、今回はset_valueを中心に眺めてみてください。
// DBハンドル取ってくる
$dbh = $this->get_db();
// hogeクラスを「にゅ～」
$hobj = new hoge_clump();
$hobj->set_db($dbh);
$hobj->set_value('email', $email, false);
$ret = $hobj->get_nopk();
つぎ。getしたりget_nopkした時の値変更ですが。…これも二種類ありまして。
基本的には「Object内のデータが変わったら連動するようにDBの値も変わって欲しい」ので。その場合、第3引数にtrueを設定します。
$hobj->set_value('counter', $counter, true);
$hobj->set_value('counter', $counter, false);
$hobj->set_value('hogera', $hogera, false);
$hobj->set_value('mugera', $mugera, false);
$hobj->update();
おまけ。CGI Requestデータから情報をげとってそのままDBに格納する場合、
// DBハンドル取ってくる
$dbh = $this->get_db();
// cgiリクエストが詰まったオブジェクト取ってくる
$req = $this->get_cgi_request();
// hogeクラスを「にゅ～」
$hobj = new hoge_clump();
$hobj->set_from_cgi($req);
// データ突っ込む
$hobj->set_db($dbh);
$hobj->insert();
いわゆる「入力 -> 確認 -> 完了」なんかの時に便利ですね。基本はこんな感じで。
// データ突っ込む
$hobj->set_to_tmp();
というロジックになります。
ただ。「すでに手持ちにあるセッションオブジェクトに入れて～」というケースもあるので。その場合
// データ突っ込む
$hobj->set_to_tmp($お手持ちのセッションオブジェクト);
概ね、set_to_tmpと一緒です。つまり、通常は
// データげと
$hobj->set_from_tmp();
// データげと
$hobj->set_from_tmp($お手持ちのセッションオブジェクト);
convインスタンスはmodelクラスから取得できるので、って前提で、こうなります。
// convインスタンス取ってくる
$conv = $this->get_conv();
// 設定
$hobj->set_all_to_conv($conv);
ちょいと話が飛びますが。
DBのkeyには、自然キーと人工キーという二種類があります。リレーショナルデータベース、という数学論としては「自然キー」を推奨しているのですが、例えばOracleとか、その辺の製品を扱っている、いわゆるデータベースエンジニアとかいう方々は、人工キーを推している事が多いようです。
まぁ善し悪しって話はおいておくのですが。
個人的には、やはり「候補キー」と呼称されるタプル群がいくつかあってその中の一つを「主キーにする」というのが、大変にきれいであるように感じられます。
別の観点として。
いわゆる「デリートフラグ」とかってやつですが。…あれがtrue(削除された)ってデータが増えると、テーブルが太るんですよね。ちょっと気になるところです。
等々、の観点から。
MWでは「デリートキーをonにする論理削除ではなく、レコードそのものを物理削除するほうを推奨する」方向で考えています。
ってのを踏まえて。
// 削除
$hobj->del();
ここからが、妙技。
まず。「テーブル名 ＋ '_delete'」というテーブルを用意してください(この辺、prefixにするかsuffixにするか、また付け加える文字列については可変予定です)。
しかる後にdelメソッドを。
するとなんと不思議。本体テーブルから削除されて、_deleteテーブルに同じ情報がinsertされています。 ちなみに_deleteテーブルは「主キー設定をしない」「元テーブル＋'delete_date'というタプル」という構成が好ましいですっていうかそれ前提です。
これであれば。
例えば「emailは重複させたくないからuniquではじきたい」とかそういった「真っ当なDBの使い方」が割と簡単にできるようになります。
今までの説明でも概ね使えるのですが。さらにより一層「お便利に使う」ための一助としてのご提案です。
例えば現状。CONVで、いわゆる「単置換」しかサポートしていないです。言い換えると。typeがtextだったりtextareaだったりするとよいのですが、これがradioだったりselectだったりすると、どうしても個別ロジックが必要になります。
また、確認画面では「selectで得られた値」ではなくて「selectで得られた値から導き出される文字列」になる事も多々。
そんな時の、ぶっちゃけご提案的Tipsです。
まず。convでいうところのconv_util::monoDicCheckedなどは。data_clump継承クラス内に作成します。
概ね、こんな感じで。
public function set_all_to_conv($conv)
{
// まずは親call
parent::set_all_to_conv($conv);
// で、個別処理
conv_util::monoDicChecked...
}
なんてルールを決めた上で、同じくset_all_to_convメソッド内に記述してしまえば便利です。
これもset_all_to_convと全く同様で。個別にmodelとかに散らかすのではなく、clumpクラス内に集約して持っておくようにしましょう。
二点ご紹介。
いち。
「トークナイザつかってユニークなIDを与えたい」なんてケースは多々。この場合
$hobj->set_value_token(カラム名, false);
に。
「今この瞬間の日付を入れたい」ってのが以下略。同様に
$hobj->set_value_nowdate(カラム名, false);
「最低限きちんとntpで時刻あわせをしておきましょう」。
よく「DBの側の日付を取得」と言いますしそれは正論なのですが。それも「DBサーバを複数台にした」瞬間に同じ問題が発生するので。
まずは「きちんとntpで時刻あわせをする」事を意識しましょう。
で…ある意味ここが真骨頂。がつりんといってみましょう。
んと。ぶっちゃけここは「静的なHTML」で結構ざます。適当なメアドを表示してください。
とりあえず… member_add@domain.com とかいう名前にしてみませう。
まず「メールが届いたらそのままプログラム起動してstdinにメールのstring渡すよ」な設定をします。
大抵の場合、/etc/aliases あたりになります。書式としては
メアドのlocal-pert: | 起動したいプログラムって感じです。今回は
member_add: | "/usr/local/bin/php /opt/www/hogeramugera/batch/member_add.php"としておきましょう。phpのパスは自分で調べてね。
まずはconfig.confに「このファイル使って処理よろ」という設定を。
# 会員登録用 member_add = /opt/www/hogeramugera/conf/member_add_config.conf当然ながら、左辺値のお名前はなんでもいいんだけどね。下記のバッチのconfig->findのところとずれると動かないので要注意。
# 登録用空メールごにょごにょのconfig # insertするDBのtable名 table_name = empty_mail_cushion_member_add # 暗号化用config crypt_config_name = /opt/www/hogeramugera/conf/mail_crypt.conf # メールテンプレート mail_template = /opt/www/hogeramugera/template/mail/member_add.tpl # from アドレス from = admin@hogeramugera.com from_name = hogeramugera_admin # タイトル subject = 新規会員登録概ねわかると思うんだけど、ポイントは「暗号化用config」。トークンを暗号化するので、そのための設定。…とりあえず下記コピペしてｗ
# 今のところ MCRYPT_RIJNDAEL_256 だけ type = MCRYPT_RIJNDAEL_256 # cbc, ecb, cfb, ofb, nofb block_mode = cbc # secret key(32文字まで) key = 半角で適当な文字列入れといて通常の暗号化用の設定ファイルと書式は一緒。
以下のURIをクリックすると登録が完了します。 http://hogeramugera.com/index.php?c=add_fin&guid=on&i=%%%token%%%i=％％％token％％％が絶対に必須で(別にi=ぢゃなくていいんだけど)、最低限これがあればOK。
身も蓋もなくざくりと。
base.inc
MWとconfigファイルの場所の設定。index.phpでも使うので一回外だし。
<?php
// MWを使えるようにする
require_once('/opt/www/MW/mw.conf');
// configファイルの場所を設定
$config = '/opt/www/hogeramugera/conf/config.conf';
cron_base.inc
cronの時に使う、configとDBのインスタンスをとりあえず作っとく。
<?php
//
require_once('base.inc');
require_once('config.inc');
require_once('db_manager.inc');
//
$cobj = new config;
$cobj->set_file($config);
// dbh
$dbh = db_manager::get_handle( $cobj->find('db_config_path') );
実処理。 member_add.php
<?php
require_once('/opt/www/htdocs/hogeramugera/cron_base.inc');
require_once('empty_mail_cushion.inc');
// メールクッションクラス
$obj = new empty_mail_cushion;
$obj->set_db($dbh);
$obj->set_config_filename($cobj->find('member_add'));
// 処理
$obj->run();
最低限必要なのは…
require_once('empty_mail_cushion.inc');
// iが無いときの処理
// XXX とりあえず有り得ないので雑に
$i = $req->find('i');
if ("" === $i) {
print "error (i is empty) \n";
exit;
}
// uidが取れないときの処理
$uid = $this->get_id();
if ("" === $uid) {
print "error (uid is empty) \n";
exit;
}
// メアドげとって
$obj = new empty_mail_cushion;
$obj->set_db($dbh);
$obj->set_config_filename($this->get_config()->find('member_add'));
// 多分本当はこう
//$obj->get_なんりゃら($req->find('i'));
//$email = $obj->get_email();
$email = $obj->get_email($req->find('i'));
emptyで使う一時テーブル、現状削除ロジック書いてないんだよねぇ orz
ごめんそのうち書くからしばらくの間は適当にお掃除君入れてあげてくださいませ orz
んと。基本的にはユーザIDの類をkeyにするのですが(携帯だとサブスクライバIDの類使ったりもします)。
ぶっちゃけ制限緩いので。必ずしも「１ユーザ１セッションデータ」とは限りません。
まぁ使い方みて何となく想像してくんなまし。
とりあえず、何はともあれここは必須。
$sed_obj = new session_data_db;
$sed_obj->set_db($this->get_db());
$sed_obj->set_id($this->get_uid());
$sed_obj->read();
基本的には「どんどん追加」と「同一のkeyがあるんなら上書き」の２種類。
$sed_obj->add($key, $value);
$sed_obj->add_once($key, $value);
$s = $sed_obj->find($key);
$array = $sed_obj->find_array($key);
前者が単値、後者が配列でデータを探します。
ちなみに。
$sed_obj->erase_key($key);
$key_array = $sed_obj->get_all_keys();
$sed_obj->init();
これやらないと「DBに反映されない」で切ない思いをするので注意。
$sed_obj->write();
置換エンジン。Smartyの代用品だと思ってください。
Smartyはちと個人的に「多機能に過ぎて」トラブルに遭いやすいので。convを普段は使っています。手持ちのクラスのなかでも、ルーツが格段に古いモノの一つです(1999年の７月とか８月とかにCで作成したのが源流)。
執筆中
テンプレート記述についても書いておかないとねぇ。
「とりあえず入力値一式テンプレートに設定したい」なんて時に便利。
require_once('conv_util.inc');
// とりあえずrequest情報一式突っ込む
// XXX 持ち上げられそう？
$sp = new simple_request_put;
$sp->set_conv($conv);
$sp->set_request($req);
$sp->set();
旧来「data_clump」と呼称されていたクラスから上下に派生したクラス群です。
哲学の根幹は「データをひとかたまりにして扱う」というものになります。構造体とかいうなｗ
執筆中
set_from_cgi、set_to_tmp、set_from_tmp、set_to_dbがひとつ。
set_data＆get_dataが一つ。
あとお便利君達。
まずdata_clump_validateクラスの継承で作る。
しかる後に
// validator
// $cobjはclump_validate継承のインスタンス。
require_once('validator_util_with_conv.inc');
$vobj = new validator_util_with_conv;
$vobj->push_clump('custorer', $cobj);
$vobj->set_conv($conv);
$ret = $vobj->is_valid();
Smarty版は………作る？
作るならついでに、conv_utilと同様のsmarty_util作ると便利かも。
]]>適当なファイル～例えば"/etc/framwork/mw.conf"とか"/opt/www/mw.conf"とか～に以下の内容のファイルを作成します。
<?php // Frame workのクラスが一式インストールされてる場所 $dir = "/usr/src/MW/"; set_include_path(get_include_path() . ":" . $dir);
あとは、mw.confのファイルの「絶対パス」だけ、開発者に周知しておいていただければOKです。
開発者的には、上述ファイルをrequire_onceすれば、MagicWeaponのクラスは一通り使えます。
]]>データの取得はcgi_requestインスタンスを使ってください。
面倒な色々がずいぶんと減ると思いますんで。
calendarクラスで色々できます。是非覗いてやってください。
結構楽なのは「文字列を取り込むset_stringメソッド」とか「日付を加減算出来るメソッド」とか。
いわゆる「ユニークなトークン」が必要なときに鬼便利です。
特に何か無ければ
tokenizer::get()
で簡単に「ユニークなトークン」が作成していただけます。
いわゆる「name = value」形式なら簡単に読み込めます。 １カラム目が＃の時はちゃんとコメントアウトと見なしてくれます。
「これは英文字？」「これはURL？」などの単純な文字列チェックが色々と収められてます。
ログがかけます。いやまぁそれだけなのですが…ちょっとしたバリエーション＆スイッチが案外に便利です。
具体的には「出力のon/offがメソッド一発」とか。高頻度のログの時は「時間をyyy/mm/ddではなくエポックタイムで書く」のも案外に効果的だったりします。
とりあえず、最低限のエスケープくらいは「たしなみ」ってもんです。
テンプレートエンジンです。機能は簡素ですが、それ故のメリットも色々。
簡単かつ的確にCSV情報をパースできます。
]]>結構いろいろあるので(制限含めてね)、ちとしっかりと、背景込みで。
# セッションID用の暗号フォーマット & 鍵 session_crypt_config = /opt/www/conf/admin_session_crypt.conf
いきなりですが暗号configの書式参照で。MWのセッションは「わざわざ暗号化までしてるから」比較的しぶとい…と思います。
# 制限値関連 # パスワードのエラー許容回数 # default 5 pass_error_count = 5
ユーザが「何回までパスワード間違えちゃっても心広く許容してあげるか」の回数です。１とかやるとタイトすぎるので適切な値を設定してください。
一応、デフォルトは５回を想定しています。
これを０(または負の値)にすることで「何回間違えてもロックしない」ようにはできますが、力技でパスワードクラックが可能になるので、可能な限り全力でそんな設定は回避してください。
# パスワードエラーでの一時ロック時間：単位は秒 # default 3600(sec) = 1h pass_error_lock_time = 3600
上述の「pass_error_count」回数間違えると、そのアカウントは一時的にロックされます。そのロック時間をここで設定してください。
極論、ここが数分でもよいです。pass_error_countを無制限にするくらいなら、ここの時間を短くしてください。
# セッションの寿命：単位は秒 # default 600(sec) = 5min session_expire = 600
１セッションあたりの寿命です。言い方を変えると「この時間だけ無操作ならいったんセッション切るからね」な時間です。
デフォルトは結構厳しいですが、長くても数時間の前半が限界じゃないかなぁと個人的には思うのですがどんなもんなんですかね？
# session_module_loginにまつわる設定 # login_id_form_name = ログインのときにIDが入ってるformの名前 # login_pass_form_name = ログインのときにpasswordが入ってるformの名前 # login_error_return_command = ログインにしくった時の移動用コマンド名 # login_return_command = ログインに成功した時の移動用コマンド名 login_id_form_name = id login_pass_form_name = pass login_error_return_command = index login_return_command = top
session_module_login.incにあるsession_module_loginクラスを使うときに必要な設定です。
これを適切に設定すると、mapファイルに、IDとパスワードを入力するPageのコマンド設定を
login = session_module_login.inc:session_module_loginこんな風にかいておけば、あとは勝手に
を自動的に解決してくれます。
ちなみに微妙Tipsですが。認証後のPageは、base_model_authからの継承クラスにした上で、マウントポイントのメソッド名を通常のexecuteではなくexecute_authにしておくと、簡単に「ログイン後限定のPage」にできます。
# session_model_authにまつわる設定 # とはいえ一部はsession_module_loginでも使うんだけどね # auth_key_cookie = Cookieを使ってkey埋め込むならon default on # auth_key_cookie_name = Cookieにkey埋め込むときのname default s # auth_key_post = postを使ってkey埋め込むならon default off # auth_key_post_name = postにkey埋め込むときのname default s # auth_key_get = GETは基本offだよねぇ？ # auth_error_return_command = 認証NGのときに遷移するコマンド名 auth_key_cookie = on auth_key_cookie_name = s auth_key_post = off auth_key_get = off auth_error_return_command = index
base_model_authで使います。…内容はコメントに書いてあるくらいで大体通じますよね？(あ、手抜き
注意点としては「auth_key_postがonのときでも別に勝手にhiddenを作ったりはしない」不親切設計なので、そのあたりはmodel側で実装よろ。…とはいえ何か対応はするかもしれないけどもしかしたら。
# セッションの寿命が迫ったときの対応方法 # 0:なにもしない（激しく非推奨 # 1:新しいセッションを作成する。古いセッションも寿命までは有効 # 2:新しいセッションを作成する。古いセッションは破棄する # 3:寿命そのものを伸ばす(非推奨 # default 1 session_expire_flg = 1
コメントそのまま。特に問題なければ１番でよいと思うです。ちなみに１～３の動くタイミングは「TTL(寿命)が半分以下になったとき」。
# ログインのときのDBのほうの場所 # とりあえずテーブル構成は「きめうち」する。session_auth_clump.inc読んで。 # ここ自由にしてもしゃぁないっしょ。 #SELECT auth_user.id FROM auth_user WHERE auth_user.id = 'cgi(id)' and auth_user.pass = 'encrypt(cgi(pass))'; # auth_clump = authテーブルのclumpクラスファイル名 : クラス名 # auth_clump_table_name = authテーブルの名前。default auth_user auth_type = 0 auth_clump = session_auth_clump.inc:session_auth_clump auth_clump_table_name = auth_admin_user session_clump_table_name = auth_admin_session
ほぼそのまんま。data_clump使ってるので、そっち系の知識が少し必要かも。
# パスワードの暗号種別 # sha-1, md5, 3des, rijndael(256), none #password_crypt_type = sha-1 | md5 | 3des | rijndael | none # default sha-1(…でいいかなぁ？) key ハッシュなのもあってdefaultはなし password_crypt_type = sha-1
パスワードハッシュの種別。とはいえ、md5とかありえないしnoneなんて呪われてしまえ。基本はsha-1。個人的には次点でrijndaelを推したいけど、そのあたりは賛否両論なので微妙。
]]>このconfigは、crypt_factoryクラスのget_instanceメソッドに渡す引数のファイルに書かれているものになります。
# 今のところ MCRYPT_RIJNDAEL_256 だけ type = MCRYPT_RIJNDAEL_256
本質的には、typeでは「ブロック暗号方式」を指定します。…が、とりあえず現在サポートしてるのはrijndael256だけになりますごめんなさい。
別の暗号の実装は多分そんなにしんどくはないので、必要なら教えてください。List増やします。
# cbc, ecb, cfb, ofb, nofb block_mode = cbc
ブロック暗号モードです。一応いろいろとサポートしてますが、ecbとか設定する人は呪われてください。
迷ったら有無を言わさずcbcにしておくのがとりあえず無難です。
# secret key(32文字まで) key = 暗号キー配列
秘密鍵です。これが漏れたら暗号の意味が根底から覆りますのでご注意のほどを。 このままだとある程度推測が容易な可能性があるので、そのうち、bit単位２進数指定ができるような設定記述を追加する予定です。
]]>type=DBの種類(現状、mysqlとpgsqlに対応)
database=DB名
user=接続用のユーザ名
pass=接続用のパスワード
host=DBサーバのIPアドレス。省略するとlocalhost
port=DBサーバの接続ポート。省略すると各DBのデフォルトのポート番号
将来的には複数のDBハンドルとかにも対応してみたいけど、とりあえずシンプルに。
]]>現状、基本的には以下の形式になります。
コマンド名 = includeすべきファイル名:newするクラス名たとえば、c=topというパラメタを受け取ったときに、common/top.inc内にあるtopというclassをmodelとしてたたきたい場合は
top = common/top.inc:topと設定することになります。
パラメタでc=が省略された場合、コマンド名"index"が渡されたものとみなします。 ですので、top pageのコマンド名をindexにしておくといろいろと楽だったり便利だったりします。
コマンド名とファイル名、クラス名がすべて一致する場合、省略記法ありを考えてます。 具体的には、上述のtopを例にとると
top = common/:ってな省略をOKしようと思ってます。commonまで省略可能な記法も考えてますがまだ思案中です。
[dir = common/] top # 顧客情報系 [dir = user/] user_find user_list user_detailとかって感じになるのかなぁ？
基本のテンプレートファイル名を列挙できるようにしようと思ってます。 イメージとしては
top = common/top.inc:top, 正常系テンプレートファイル名, 異常系テンプレートファイル名とか
top = common/:, 正常系テンプレートファイル名, 異常系テンプレートファイル名とか
[dir = common/] top = , 正常系テンプレートファイル名, 異常系テンプレートファイル名とか、かなぁ。 実際には、テンプレートは３つ以上指定可能にする予定。 ]]>
原則は「１ファイル１クラス」。
基本的に「哲学」に由来する名前をつけ、間違っても「機能」に由来する名前はつけない。 なお、クラス名によって明示されている名前については、冗長なのでつけないようにする。 configクラス内において「configファイルの名前を設定する」メソッド
良い例： set_filename() set_filepath()
微妙な例：ちょっと冗長 set_config_filename() // configは分かりきってるので冗長
悪い例： set_string() // 文字列であるかどうかなんてのはぶっちゃけどうでも良いので
かならず public/protected/private 修飾子をつける。(PHP) なお、メソッドであっても、必要に応じてprotectedにすることが望ましい。
finalについては必要に応じて。ただ、フレームワークの柔軟性を考えると、あまり使わないだろうと思われる。
特殊なケースを除いて、原則としては、throwは「フレームワーク内では」投げない。 ちょっと検討が必要かも。
「へび」とする。 英小文字を用いる。複数単語がある場合、アンダースコアを使ってつなげる。 例： get_value
命名は「へび」とし、最後にアンダースコアをつける。 例： dbh_ user_data_
クラス変数は「アクセッサ以外では絶対に触らない」事を鉄則とする。 また、かならずprivateとし、protectedにはしない(アクセッサで対応すること)。 (デバッグ時の捕捉の問題があるので。 アクセッサは基本的に以下の２パターンのいずれかとする。
通常の場合 set_名前 get_名前
配列系(複数のデータを設定できるもの)の場合 push_名前：データを積み上げる set_名前：配列を一気に設定する：もとにある情報は潰して上書き、のイメージで get_名前：これは「配列を全部取得」する(keyなどを利用して一つだけ欲しい場合、別口にメソッドをつくり、このgetメソッド経由でアクセスする) clear_名前：データを消す
(PHP) また。これは強制ではないが、セッターの引数については 数字を期待していたら$i 文字を期待していたら$s 配列を期待してたら$a インスタンスを期待していたら $o にしておくと分かりやすい
型があるものと考え、かならず「一つのメソッドは一つの型を返す」ようにする。 なお、エラーについては以下の通りとする。
数値を返すものの場合：-1 ただし「正常な値として負の値も戻る」ようなメソッドの場合、原則として「boolean」復帰にする。
文字列を返すものの場合："" 空文字 ただし「正常な値として空文字も戻る」ようなメソッドの場合、原則として「boolean」復帰にする。
配列を返すものの場合：空配列 ただし「正常な値として空配列も戻る」ようなメソッドの場合、原則として「boolean」復帰にする。
オブジェクトを返すものの場合：NULL ただし「正常な値としてNULLも戻る」ようなメソッドの場合、原則として「boolean」復帰にする(…って。ありえるのか？)
booleanを返すものの場合：false
ぶっちゃけ。基本的には、処理系はすべてboolean復帰とし、trueが帰ってきたら情報をget系で取得したほうがよいと思う。
注：これは要検討かも tabインデントであることはMust()。 見栄えを重視したときのtabのサイズは、一応２を推奨するが、４又は８でもよしとする。
各インデントは以下のようにする。 メソッド、変数宣言などはすべてインデント０
class クラス名
{
コンストラクタ
デストラクタ：必要に応じて
init
アクセッサ
メソッド各種
//
変数宣言
}
基本はPHPDocumentorを使用するイメージ
/** * classの説明(一行)：基本的にクラス名 * * classの説明(複数行)：クラスに対するコメント突っ込みの類 * HTMLに反映されたとき改行はされない * * @package magicweapon * @link http://www.grid-works-guild.net/MagicWeapon/ MagicWeapon * @access public * @author Michiaki Wuzawa <wuzawa@m-fr.net> * @create $LastChangedDate$ * @version $Revision$ */
メソッドあたりのコメント /** * メソッドの説明(一行)：基本的にメソッド名 * * メソッドの説明(複数行)：詳細な説明その他 * * @access publicかprivateかprotectedか * @param 型 名前 説明 * @return 戻り値の型 簡単な説明 */
一応「お便利君」であると想定すると、基本的には
がある程度正しいのではないかと推測してみたりみなかったり。
持ちまわりたいものが入ってるクラスつくるか。 grobalに近いけど、これならまだしも制御しやすいし。
持ちたいものとしては
…書かないとねぇ
]]>最終的には約一名の独断と偏見になりそうなのですが。一応、方針っていうか方向性を。
設計如何にもよりますが、基本的には許可の方向で。
ただ設計方針は割合にシビアにチェックします。
基本的には
の方向があると思ってください。
「明らかにどう考えても最低限これだけは何が何でもいるだろってかなきゃまずいし動かないし」 っていう、ぎりっぎりまで削り取ったクラスです。
skeltonとかいう名前にすることが多いかな。
skeltonを継承したりすることが多いと思うですが。
基本的には「普通に使うならこれくらいは欲しいよねぇ」というバランス感覚満ち溢れたクラスです(笑
ここには「あると便利だよねぇ」は基本含まれません。
文字通り。唯一、うち的には比較的「肥え太った」クラスです。
「掲示板に便利」とか「ECサイト用」とか、割合にピンポイントなものです。 これは必ず「ディレクトリを分けて」入れます。
実装方法はたぶんうるさいくらいチェックします(笑
とりあえず、独裁政権引いてる約一名の脳みそをこじあけると…
などなど。
何かほかに出てきたら追加します。
別にこのファイル名でなくてもいいのですがなんとなく慣習的に。 「MagicWeaponのファイル群がどこにあるのかを知っているファイル」になるので。 唯一にして最重要な「path情報を保持する」ファイルです。
これもかなり慣習チックですが。大抵、ここに設定がごっちゃりと入ってます。
データベースの接続情報が入っていること「が多い」ファイル名です。 少なくとも、wwwroot以下に置くなんてアバウトなマネは控えましょう。危険すぎます。
]]>なんか要望とかあったらかいといて～
エラー処理、マップファイルフォーマット修正、鞄オブジェの持ち回りなどなどを実装予定。
一式作る。line_clump、find_clumpも視野内。
(X)HTMLコメント外しの話がでてる。携帯系で顕著かな。
携帯系といえば「絵文字対応」とかね。…でも絵文字対応は「別class」作った上で「必要に応じて当てはめる」感じかなぁ。 どっちかってぇとCONVの拡張になりそう。
鋭意作成中ｗ
]]>