うほ、ありがとうございます！
アクセスさえ出来ればあとはどうにでもなりますね
もしくはマスタ数に上限を設けて、requiredがfalseなフォーム値を
上限分書いて逃げようと思います

smartyのincludej関数を使って、ヘッダー部やフッター部を別ファイルにしたいのですが
それ様の格納フォルダみたいなものってないのでしょうか？もしくは何か良い方法あれば
お願いします

>>57
テンプレートディレクトリの中に好きなようにディレクトリ作って突っ込めばいいですよ。

ログの出力をなんでもいいから全部ファイルに出力したいときはどうするのん？

おお、ありがたい

ちなみになんだけど
Ethna_Controller の getManagerClassName と getObjectClassName 。
微妙に名前の変換ロジックが違う
CVS版だと同じになってんのかな？

http://ihc.mydisk.jp/

>>63-64
いやいや、PEAR_DB版でもADOdb版でも、トランザクションは
$this->db->begin();
$this->db->rollback();
$this->db->commit();
で統一されてるよ。

Ethna_DB_ADOdb.phpだとbegin()で単にBeginTrans()を呼んでるだけだけど、ADOdbのStartTrans()ってBeginTrans()より色々とよきに計らってくれるんですよ
/**
 Improved method of initiating a transaction. Used together with CompleteTrans().
 Advantages include:
             
　a. StartTrans/CompleteTrans is nestable, unlike BeginTrans/CommitTrans/RollbackTrans. Only the outermost block is treated as a transaction.
　b. CompleteTrans auto-detects SQL errors, and will rollback on errors, commit otherwise.
　c. All BeginTrans/CommitTrans/RollbackTrans inside a StartTrans/CompleteTrans block are disabled, making it backward compatible.
 */
function StartTrans($errfn = 'ADODB_TransMonitor')
{....

ぐあ、StartTrans()のことは知らなかった。ごめん、typoかと…orz
CompleteTrans()でエラーを自動判定したり、トランザクション中に
別のメソッドでcommitされても大丈夫というのは便利ですね。
ADOdbの独自拡張ぽいから、Ethna_DB_ADOdb.phpを拡張するか、>>64氏の
書いたように直接呼ぶのが良さそう。

# ドキュメントに「毎回エラーチェックする必要ないよ」て書いてあるのは
# 無駄にSQLの実行回数が増えてしまうので微妙な気もするけど…

詳しい人おしえて、

Ethna使ってて　actionに書くべきか viewに書くべきか迷うんだが、

例えばactionで
AppManager使って必要なデータ取ってきてたとして
ついでに af->set()で出力のお膳立てもしてしまった方が楽に感じるんだが、

あえて、どこかに溜めておいてview側でaf->set()すべきなのかね？

>>68
actionformのsetはactionclassのperformに入る前の段階
つまり、authenticateとprepareで行うべき。

viewでやるのはもってのほか。

AppObject/AppManagerなどのModelにも極力行かすべきではない。


というルール付けでやってMVC意識してる。

>>70
どういうこと？

なかなか興味深い

>>75
とりあえず1分でも早いことコーティング終わらせたい！
って時は、確かにViewレスにしてperformでsetAppする。こともある。

前はそうやってたけど、最近面倒でもviewつくるようにしてる。
まぁ、1分かからんでしょ。

理由は2つあって、ひとつは、結局あとから追加仕様が加わった時に
viewがあるとそこに流し込めば良いという意識でAction作ってしまえる。
viewを造ってないと、結局違うActionに同じsetAppするようになる。
ある意味、そっちの方が絶対使い回しできない。

もうひとつは、forwardをいじりたい場合。
view/Subview.php
view/Subview/Draw.php
view/Subview/Draw/Finish.php
ってする場合、APPID_View_Subview::forward()に仕掛けをしてやって
テンプレパス変えたりする場合、クラス定義だけでもしておけばそれ以下の
viewもよろしくやってくれるけど、viewを定義しないとControllerで設定した
view使っちゃうからな。まぁ、特殊な場合だけど、forwardいじれるのは強力だからな。

>>76
>もうひとつは、forwardをいじりたい場合。
これは分る。確かにforwardいじりたい時もある。

>viewを造ってないと、結局違うActionに同じsetAppするようになる。
>ある意味、そっちの方が絶対使い回しできない。

そうかなー。viewを作ってあったにせよ、viewに渡すものが抽象化
しきれてなければ、結局使い回せない気がする。
一番抽象的で、どんなviewでも理解できるもの、つまりはActionFormを
渡すというお約束が、ゆるくて最強の接点だと思うんだが。

>>78
>渡すというお約束が、ゆるくて最強の接点だと思うんだが。
その辺は、開発スタイルとか案件に依るんじゃない？
取りあえず「オレはこういう感じでやってる」ってだけで、別に色々な方法があると思う。
使ってるうちに変わるだろうし、ってオレがそうなんだけど。

そのへんのゆるさはEthnaのいいところだし、一人や数人でやる分には気楽。

みんな、AppObjectというかORM使ってるのか。
俺はjoinのやり方が分からなくて涙目だったので、いまだにSQL書いてるよ。
ZnedFrameworkも試してみたけど、Zend_Db_Tableが全然使えないので
結局そっちもSQLというチンカスっぷりだぜ。

joinは少し前まで、まともにできなかったはず。
なんで漏れもSQL書いてるよ。AppObjectはテーブルのレコードと１対１でやり取りする場面だけ
使ってる。検索して一覧引っ張ってくるようなケースは、joinする場合が多いし、
where文SQLで書く方が慣れているんで、SQL書いた処理をAppManagerに詰め込んでるよ。

view作ってwhere条件だけEthna_AppSearchObjectで作るってのはナシ？
もっとも、それやった香具師がMLで「table読むときはカラム名小文字になるのに、viweを読むと大文字になる。がっでむ！」と言っていたので、あまりお勧めではないのかもしれん。

……S2EthnaでS2Dao.PHPか？w

>>89
http://www.php.net/manual/ja/language.references.php
参照はスカラー型でもオブジェクトや配列でも使えるよ。

余談だけど、PHP5以降では関数の戻り値や変数への代入なんかで
同じオブジェクトを指し示している必要がないのであれば、参照渡しを
するべきではないので注意。メモリの効率化とか思っていると、むしろ
無駄に消費されることがある。
http://www.phppro.jp/news/304

PHP4/5に対応するEthna(本体)には関係ない話だけどね。

このフレームワークって他のフレームワークにあるような
AjaxヘルパやHTMLヘルパーなんかは装備されないんでしょうか？
あと、ルーティングをもう少し改善して欲しいですな。

スマートURLを使えるようにするにはapacheの方も色々設定しないと駄目？

例外処理をしたいのですが、
AppManager 内で
throwして
アクション内でcatchしたい場合、
どのように記述すればよいでしょうか？
単にAppManager内でthrowすると
PHP Fatal error: Uncaught exception 'Exception'
がおきてしまいます

>>67
エラーが発生したらトランザクション中の後続するSQLはスキップしそうだけどね
そうじゃなきゃあんまりでしょｗ

>>97
いや、ソース確認したらチェックしてなかったんだよ
あんまりだ

$obj =& $this->backend->getManager('hoge');
$obj->setParam( $param );
$obj =& $this->backend->getManager('hoge');
みたいな感じにすると
$obj->setParam( $param );が既になされている状態になる理由が
よくわからんです。

参照渡しってやつのせい？
$this->backend->getManager()
をオブジェクト生成（new）と同じ感覚で使ってたけど、
もしそうなら大きな勘違いですよね。

newみたいに使う方法ってないでしょうか？