05/10/22 20:53:13
CakePHPのソースを漫然と眺めていたんだけど、その語尾の特殊変化の設定ファイルに
penisとtestisがあったよ。これで下品なソースでも安心だね。アダルトサイトにも最適。
でもこれいいわ。なんて言うか、流れに身を任せればとても楽。コンパクトだから見通しもいい。
それにやっぱり死にかけのプロジェクトよりも生きのいい方がいいしね。
512:nobodyさん
05/10/23 02:30:29
>>511
>語尾の特殊変化の設定ファイル
なにそれ
513:nobodyさん
05/10/23 02:34:17
>>510
？xA0; みたいなやつ？
他キャリアのつもみんなドコモのやつに置き換えるの？
てか、フレームワークすれでこんなこと聞いてすまん。
514:nobodyさん
05/10/23 06:55:11
cake
515:nobodyさん
05/10/23 16:59:56
>>512
cakeはRails系なので、規約は設定に勝るっていう哲学で作られてる。
たとえば、Userというモデルが対応するテーブルはUsers決め打ちになる。
だから、特殊な場合の変化形を自前でもっとく必要がある。
もちろん、大抵の規約は上書きすることができるけど、それだとcakeの意味がないしね。
516:nobodyさん
05/10/23 20:58:51
>>507
JavaのJakartaプロジェクトみたいなものかな。
今後の標準になるようなものを作って欲しいなぁ。
517:nobodyさん
05/10/23 21:58:24
>>516
Zend自身が乗り出してるから標準を目指してるんだろうね
これをふまえて今の草の根フレームワークはどう動くんだろ？
Mojavi4は完成するのか…
518:nobodyさん
05/10/23 23:50:08
>>517
Zendはどうせ金になるエンタープライズ領域しか目に入っていないだろうから
既存のフレームワークとは競合しないような予感。
あとは、ZendStudio必須とか、余計なことしちゃいそう。
519:nobodyさん
05/10/24 00:45:36
>>518
たしかに余計なことしちゃいそう
よく考えるとZend提供のPHP関連サービスに
いい評判はあまりないもんなぁ。
520:nobodyさん
05/10/24 03:51:45
URLﾘﾝｸ(www.symfony-project.com)
mojavi + rails = symfony
てか、もう迷うのも面倒なんで
そろそろ定番出てきてﾎｽｨ…
521:nobodyさん
05/10/24 04:36:42
定番を望むのもわかるけど、
何でもできる＝どれも中途半端な性能
てことが往々にしてあるので、すきなの見つけて自分で
進化させていくのがいいかも。
できればsourceforgeとかつかってｗ
522:nobodyさん
05/10/24 15:04:10
Zend PHP Framework
あれどうなってんの？
523:nobodyさん
05/10/24 15:04:59
>>519
Smartyとか？
524:nobodyさん
05/10/25 10:38:07
SmartyってZend発？
525:nobodyさん
05/10/25 12:33:45
違うと思う
526:nobodyさん
05/10/25 22:39:29
まぁZendの事だから、期待出来ないな。
今までノータッチだったけど、Ethnaって良さそうだなぁと思い、
本家のML見て見てみたら、ら○じぃがいるじゃねぇかよ。
あいつ嫌いなんだよな・・・。
坊主憎けりゃ・・・じゃないけど、なんかEthnaやだなぁ・・・。
藤本神は好きなんだけどなぁ・・・。
527:nobodyさん
05/10/25 23:01:50
そんなこと言うもんじゃありません
528:nobodyさん
05/10/25 23:04:45
URLﾘﾝｸ(netevil.org)
ｱｸﾚｺｷﾀｺﾚ
529:nobodyさん
05/10/26 07:10:19
ZendのFrameworkはお布施用にきまってるだろ
530:nobodyさん
05/10/26 08:56:51
いやフレームワークでは金は取らないじゃないか？
531:そりゃないか
05/10/26 09:23:36
Zend Framework Lite 無料
Zend Framework Enterprise 有料
532:nobodyさん
05/10/26 14:00:18
DB周りのコンポーネントとか有料かもな
533:nobodyさん
05/10/27 03:34:49
Zend Studioお布施済みの俺としては、Studio対応で無問題。
534:nobodyさん
05/10/28 21:50:40 geHxPjMK
Mojaviで
モバイル/PCの分岐はどこでどんなふうにやってる？
535:nobodyさん
05/10/29 01:43:09
>>534
やったことないけど、フィルタでforward分けしたらいいんじゃない？
536:nobodyさん
05/10/29 02:16:56
>>534
なにを目的として分岐をするかによる。
機能を分けたいならActionを分けるだろうし、
表示を分けたいだけならViewだろう。
537:nobodyさん
05/10/29 13:30:02
Mojaviのフィルタって好きなだけ作れるけど
プリフィルタしか使わない場合とかポストフィルタしか
使わない場合とかってある？
538:nobodyさん
05/10/29 23:44:53
それはよくあるでしょ。
539:nobodyさん
05/10/30 11:03:38
agavi api 日本語訳
URLﾘﾝｸ(www.geocities.jp)
540:nobodyさん
05/10/30 11:22:35
>>539
乙
541:nobodyさん
05/11/01 22:33:59
php5のひとはどのフレームワークつかってんの
agaviとか？
542:nobodyさん
05/11/01 23:23:56 D/XKY8a/
Mojavi3を使っているんだけど、
複数のActionから共通のViewを呼び出すにはどうするのが綺麗なやりかただろう？
543:nobodyさん
05/11/01 23:39:42
>>542
Actionでarrayかえせばええやん
544:nobodyさん
05/11/02 01:36:57
MojaviはActionとViewが
ｲﾁｲﾁで対応してるからどうやってもトリッキーになりそうだな。
俺はViewを分けるほどのことないだろと思ってｵﾘﾌﾚ作ったけど。
ViewHelperの仕込みとか結構ごちゃつくから分けてもよかったかもと
思ったりもする。
545:nobodyさん
05/11/02 01:46:12
>>544
日本語変。
546:nobodyさん
05/11/02 18:54:03
>>543
ActionでArrayをかえすってどういう具体的にどうすること？
547:nobodyさん
05/11/03 02:43:18
＊＊＊ すべてのPHPユーザーに告ぐ ＊＊＊
URLﾘﾝｸ(www.hardened-php.net)
URLﾘﾝｸ(www.hardened-php.net)
URLﾘﾝｸ(blog.ohgaki.net)
PHPに深刻な脆弱性がある事が発表されました。今まで見つかったPHPの脆弱性の中でも「最悪」の脆弱性です。全てのPHPユーザは今すぐ対処を行う必要があります。
548:nobodyさん
05/11/03 12:11:06
>>546
俺も意味が分からなかった
549:nobodyさん
05/11/03 13:09:55
>>546
Mojavi3ではActionの戻り値として、
第一要素がモジュール名第二要素がビュー名の配列をかえすことによって、
遷移先を指定できる。
550:nobodyさん
05/11/03 16:33:22
>>549
そうなんだ
そりゃ便利だね
551:nobodyさん
05/11/04 23:32:52
テンプレートエンジンをSmarty-lightにしてる人いる？
Smartyとほとんど変わらず使えて、しかも軽くなるなら、
結構お得だと思うけどどうなんだろう。
552:nobodyさん
05/11/05 00:49:33
おいagavi使ってるやついるか
553:nobodyさん
05/11/05 02:20:18
10分で作るCakePHPアプリ for Windows - p4life
URLﾘﾝｸ(p4life.jp)
cakeってここまでやってくれるのか・・・
554:nobodyさん
05/11/05 21:01:35
>>553
それだけ見ると Rails と変わらないよね
555:nobodyさん
05/11/05 21:21:51
簡単すぎて不安になるな
鯖一つで収まるようなｼﾝﾌﾟﾙなアプリにはかなり最強かも…
556:nobodyさん
05/11/05 21:37:15
つーか、rubyの勢いはマジですごい。
557:nobodyさん
05/11/05 21:47:05
海外の連中はそのうち業を煮やして、Rails 用の Ruby を
fork させそうな勢いだよな。
558:nobodyさん
05/11/05 21:49:19
ﾜﾛｽww
559:nobodyさん
05/11/05 23:42:35
EthnaでPEAR::DBじゃなくてADODBって使えるのかな？
560:nobodyさん
05/11/05 23:55:13
>>559
Ethna 専用ｽﾚがあるよ
【PHPフレームワーク】Ethna【スケルトン自動作成】
ｽﾚﾘﾝｸ(php板)l50
561:nobodyさん
05/11/05 23:59:23
>>560
お、サンクス。
ちょうどその辺りの話題のレスがあるね。
562:nobodyさん
05/11/06 01:02:45 1KuwxXQW
S2PHP使ってる方いますか？
どんな感じでしょう。
563:nobodyさん
05/11/06 11:37:34
>>562
流石に仕事に使ってる人はいないだろうね。
触った感じは面白いよ。上の方に出てたpokﾌﾚとして。
まぁ当然まだまだなんだけど、将来はかなり楽しみ。
564:nobodyさん
05/11/06 12:29:44
Mojaviの
index.php/param/value/param/value
形式のURIってmod_rewriteとの併用前提なんだね。
間にindex.phpがまるだしでﾀﾞｾｰURLになるなーとｵﾓｯﾃﾀ…
565:nobodyさん
05/11/06 16:28:01
>>564
ソースは？
566:nobodyさん
05/11/06 19:17:49
>>564
mod_rewrite使わなくても、index.phpに相当するファイルをForceTypeしちゃえばいいと思うよ。
567:nobodyさん
05/11/06 22:26:13
>>564
別に mod_rewrite 前提ってわけじゃないっしょ。
568:564
05/11/07 05:38:11
>>565
そうじゃないかな？と思っただけでソースはないよ
>>566
（入口）URLﾘﾝｸ(hoge.com)
(出口）URLﾘﾝｸ(hoge.com)
これをForthTypeでやるにはどうすればいいの？
考えてもいまいち分からなかった
>>567
まあ検索エンジン対策という意味では
index.phpがあってもなくても関係ないからなぁ
569:nobodyさん
05/11/07 10:02:24
path_info形式にすると
ブラウザがドキュメントURLを誤認識するのが面倒くさいね
リンク全部絶対URLにしなきゃならんのか。
570:nobodyさん
05/11/07 10:39:05
>>564
(入口）URLﾘﾝｸ(example.com)
(出口）URLﾘﾝｸ(example.com)
は無理だけど、
mv index.php hogehogeして、
(入口）URLﾘﾝｸ(example.com)
ならどうよ？
571:nobodyさん
05/11/08 00:44:57
PHPプログラマーズマガジンで Seagull ってのが紹介されてるね。
立ち読みしか読んでないけど。
これ、フレームワーク？ CMS?
572:nobodyさん
05/11/08 03:42:16
>>570
さんくす。
よくよく考えたら、mod_rewriteでindex.phpを無条件にはさむと、
他のファイルへのアクセスに支障が出るから、
そういう方法しかないかもしれない。
573:nobodyさん
05/11/09 02:42:24
URLﾘﾝｸ(longinus.org)
初めて見たんだけど、これの中ちゃんと読んだことある人いる？
574:nobodyさん
05/11/09 09:10:03
>>573
ぱっと見Mojavi系と似てるね
デフォルト拡張子がincなのはセキュリティー上
推奨できないと思う
575:nobodyさん
05/11/09 09:21:44
フレームワーク大杉
576:nobodyさん
05/11/12 16:50:24
Synfony勢いとかサイトのクオリティーで抜きん出てる気がする
これからはこれか？
577:nobodyさん
05/11/12 17:07:53
Symfonyのムービー見たらテンプレートにphp生書きで、
しかもテンプレート中から$user->getAttribute()とか平気でしてる。
最近Smartyみたいなテンプレートエンジンの
意義みたいなものに疑問を感じてきた俺には示唆的だった。
実際テンプレートエンジンから
独自文法の解釈外したら馬鹿みたいに短いコードで書けるんだよね。
もともとPHPはob_系関数があってキャッシュの実装なんかも
やろうと思えばすぐ出来る環境だし。
578:nobodyさん
05/11/13 01:22:28
デザイナーにはHTMLを触らせず、cssだけいじらせる時代になってしまえ
579:sage
05/11/13 08:33:59 nNKS4KNy
>>578
当方デザイナ（つーかコーダかな）ですが、それ大いに賛成です。
開発者からページに掲載するデータの定義だけ教わって
あとはxhtml＆cssと格闘するみたいな。
もしくはxhtmlの出力フォーマットだけもらってもいいや。
tableタグ使ったレイアウトに決別すると、
どうしてもそういう方向になってくる気がします。
580:nobodyさん
05/11/13 09:24:35
もう一歩進んでhtml作るときにtdiary互換のcssを参照するようになったりしたら、
webデザイナーの仕事が減っちゃうかもしれないよ?
でも、むしろその方が本来のグラフィックデザインの実力で勝負できていいのかな。
581:nobodyさん
05/11/13 17:30:56
おまいの作るhtmlは、えらく目的が限定されとるな。
582:nobodyさん
05/11/14 02:43:58
php5なんだけど、何がおすすめ？
583:nobodyさん
05/11/14 11:50:11
これは既出？
URLﾘﾝｸ(www.pm9.com)
何でもいいがFirefoxでもちゃんと見れるように作ってよ・・・orz
584:nobodyさん
05/11/14 12:29:09
ドキュメントとかしっかりしてるみたいだけど，
商用ライセンスってのが・・・
585:nobodyさん
05/11/14 14:49:17
>>583
■クラスタリング
高負荷サイトの為のWebサーバ、DBサーバの並列化に対応しています。
これが気になるなー
ちょっと見てみようかな
586:nobodyさん
05/11/14 21:59:02
>580
tdiary互換のcssって...なんでtdiaryなの？
587:nobodyさん
05/11/15 01:06:37
tDiaryのテーマを変えて喜んでるだけの厨房だから
588:nobodyさん
05/11/17 09:26:30
mojavi2ってsession_destroyは手動でやるしかない？
589:nobodyさん
05/11/19 15:36:29
Symfony見たらActionにショートカット用メソッド
（getRequestParameterとか）付けてたから俺もそうした。
何か綺麗さが損なわれるような気がしてﾔｾ我慢してたけど。
590:nobodyさん
05/11/21 03:01:02
mojaviを勉強しはじめました。
参考になるソースを見ようかなと思うのですが、お勧めのオープンソースなものって
ありませんか?
できればmojavi2系
できれば、smartyとかadodbとか使ってたり
携帯の処理なんて書いてあるとさらに素敵です。
591:nobodyさん
05/11/21 22:25:36
cakePHPってデータベース絡みには結構よさげだけど認証や権限関連が弱いな
592:nobodyさん
05/11/21 23:12:08
mojaviでFPDF使っている人いる？
なんかIEで表示されないんだけど、原因は何？
593:nobodyさん
05/11/21 23:14:05
>>592
あんたもか！漏れもだわ。
594:nobodyさん
05/11/22 00:24:11
>>592
あぁ、それIEのバグ
対処法はいくつかあるけど
595:nobody
05/11/22 12:19:16
mojaviの外に出たら、うまくいった。
596:nobodyさん
05/11/22 12:52:15
view_noneじゃなくてexitすると動くことがある
597:nobodyさん
05/11/22 16:52:59
>>591
Controller の beforeFilter と PEAR::Auth を組み合わせればカンタン。
aclがいらないなら5行もあればできる。
でも、組込み認証の是非に関する議論は一応やってたと思う。
個人的にはこれ以上Controllerは太らないで欲しいんだけど...
598:nobodyさん
05/11/22 19:29:40
>>597
早とちりかな？
認証はともかくとして、権限をどうやってPEAR::AUTHで簡単に？
五行のコード載せてみて
599:nobodyさん
05/11/22 20:31:33
> aclがいらないなら
acl = 権限ジャマイカ？
600:nobodyさん
05/11/22 20:39:40
>>594
対処法キボンヌ
601:nobodyさん
05/11/23 15:11:58
>>598
権限 = acl のつもりだったんだけど、どうしてもAclが欲しいなら今でもMyAclを使える。
うろ覚えで書くとたとえばこんな感じのメソッドをAppControllerにでも追加すればいいはず。
beforeFilterに_aclCheck、componentsにはMyAclを追加してね。
function _aclCheck(){
$this->auth =& new Auth(...);
$this->auth->start();
if(!$this->MyAcl->check($auth->getUserName(),
$this->params["controller"]."/".$this->params["action"]))
$this->_permFailed();
}
たぶんこのままでは動かんと思うけど、流れは大体こんな感じ。
権限不足画面などのViewを含めると5行はハッタリだったね、慌てさせてごめんよ。
nightlyにはさらに高機能なdbAclもあるらしい。
602:nobodyさん
05/11/24 22:26:05
agavi で DBに接続したんですけど、下記
$db = $this->getContext()->getDatabaseManager()->getDatabase()->getConnection();
クエリーを発行するにはどうしますか。
MySQLDatabase.class.phpにはメンバー関数がないようだし。
603:nobodyさん
05/11/25 14:25:00
MVCのModelにあたる部分は、Mojaviで言うとどの部分になるのでしょうか?
actionsでしょうか?
処理の部分をどこに書けばいいのかがわからなくて困っています。
MVCの記事をかなり読んだのですがどの部分がModelなのかちょっとよくわかりませんでした。
604:nobodyさん
05/11/25 14:28:18
>>602
よくわからんけどたぶんmysql_queryでやるんじゃん？
>>603
MojaviにModelあるけど
ActionはMVCのC
605:nobodyさん
05/11/25 14:37:14
Action内から呼び出す自作またはModelをextendsしたクラスあたりと思っていればよいかと。
606:nobodyさん
05/11/25 15:44:35
おいおいお前ら正気か
CってControllerのCじゃないんかよ
ビジネスロジックを担当するんだからActionクラスはModelだろ
それとももっと違う次元の話か？
607:nobodyさん
05/11/25 16:00:45
Action内でビジネスロジックを実行する場合はAction=M
Actionから一層掘り下げてModelを呼ぶ場合は
Action=Cになるんじゃないの？
前から思ってたがあまり峻別できない概念だよな。
MVCがお互いを包摂し合ってる部分がある。
音楽のジャンル分けみたいなもんだな。
厳密な区分が最初からあるわけじゃない。
608:606
05/11/25 16:09:51
なるほどね
まあ確かにそう使う場合もある罠
もともとWebｱﾌﾟﾘの世界の話じゃないしな、曖昧になるのは仕方ないというかなって当然
そういう意味ではDBの設計と似てるところがあるかな
MVCにとらわれすぎてクソな実装かますのが一番ダメダメ
つーか実際書き始めるとMVCとか結構どうでもよくなってくる
設計段階での指針程度にとどめておくべきだろうな
609:nobodyさん
05/11/25 16:20:05
結論
>>603
MVCとかどうでもいいからまず動くように書いてみろ、話はそれからだ
どうしても気持ち悪ければあとでいくらでもリファクタリングするよろし
その過程でだんだんMVCになることもあればそうでない場合もある
っつーのが本質だと思うんだな俺は。
610:nobodyさん
05/11/25 17:24:45
なるほど勉強になりました。
明確な区別はないんですね。
実はもうコーディングをしててformsの下とかviewsの下にもロジックを書いたりしていて
多分違うんだろうなぁ～と思って聞いてみました。
VIEWを返しているあたりは、action=Cと思ったんですけど、その前に処理を書こうかなと
思います。
formsはどこに当たるかといったら、まぁModelと考えておけばいいですかね。
そういうことがナンセンスなのかもしれませんが。
611:nobodyさん
05/11/25 21:04:56
PHP5.1.0リリースだというのに静かなものだね・・・。
俺が思うに、ある程度知識がないとMojavi使いきれないと思うよ。
とりあえずMojaviでいうＶｉｅｗが必要ないフレームワークにしてみたら？
612:nobodyさん
05/11/26 01:25:15 a7zffmpw
mojavi2.0を使っています。
URLﾘﾝｸ(www.stackasterisk.jp)
ここを参考にディレクトリ構造を変えたのですが、
レンタルサーバでhtdocsをベースに指定する事って出来るのでしょうか？
613:nobodyさん
05/11/26 04:50:35
そんな解決はできても難しいし、やるべきじゃない方法だよ。
多分、フレームワークの理解を根本的に間違えてるんじゃないかな。
DocumentRootにindex.phpを置いて、外部からアクセス禁止してる箇所にmojaviフォルダとwebappフォルダを置く。
あとはpath調整して動かすんだよ。
614:nobodyさん
05/11/26 08:50:15
そうそう
わかんないうちはとかくなにもかもマニュアルの通りにしないといけない、と鵜呑みにしがちだけど、
少し冷静に考えてみるとどうでもいい事なんてたくさんあるぜよ。
つーわけでindex.phpはどんな名前のディレクトリにあろうがブラウザから参照できる位置に置くべし
まーほとんどのレン鯖の場合public_html以下に適当な名前のディレクトリ作ってほりこんでるんでないかね。
615:nobodyさん
05/11/26 10:50:33
mojaviで "class IndexAction extends Action"のようにIndexでactionを指定しても
"URLﾘﾝｸ(xxx)"とわざわざ書かないと
Only variable references should be returned by reference と怒られてしまって困ってます。
環境は
PHP 4.4.1-pl1
mojavi 2.0.3 beta です。
616:nobodyさん
05/11/26 11:21:14
それは困りましたね＾＾；；；；；
617:615
05/11/26 11:41:56
すみません、解決しました
618:nobodyさん
05/11/26 12:33:18 2543W0TM
>>617
最近流行ってるね
619:nobodyさん
05/11/26 13:54:07
>>618
よくわかったね
620:nobodyさん
05/11/26 14:23:28
>>619
スキだからさ
621:＼＿＿＿＿＿＿＿＿＿／
05/11/26 15:15:03
Ｖ
＿＿＿＿_
／::::::::::::::::::::::::::＼
/::::::::::::::::::::::::::::::::::::::＼
|:::::::::::::::::|＿|＿|＿|＿|
|;;;;;;;;;;ノ ＼,, ,,／ ヽ
|::（ 6 ー─◎─◎ ）
|ノ （∵∴ （ o o）∴）
／| < ∵ ３ ∵>
::::::＼ ヽ ノ＼
:::::::::::::＼＿＿＿＿＿ノ:::::::::::＼
622:nobodyさん
05/11/26 15:36:40
PHPでフレームワーク（笑）
623:nobodyさん
05/11/26 20:37:10
あなたも技術者の端くれなら何か有用な情報を書き込んでください。
ここはWebプログラミング"技術"の板です。
煽りは必要ないです。
624:nobodyさん
05/11/26 21:19:29
>>623
迷惑掛けて申し訳ない
しばらくロムります
625:612
05/11/26 22:44:49
>>613,614
レスありがとうございます。
なるほど。アドバイスありがとうございます。
出来るだけアドレスを短くしたいんで
index.phpはDocumentRoot直下に置きたいんです。
でもレンタルサーバを借りているんで、そうするとmojaviフォルダとwebappフォルダも
DocumentRootになってしまうなと思いお聞きしました。
外部からアクセス禁止してるフォルダのあるレンタルサーバってあるのでしょうか？
それとも.htaccessで禁止するしかないでしょうか？
626:612
05/11/27 00:27:09
自宅鯖を立てることにしました。ありがとうございました。
627:nobodyさん
05/11/28 02:21:48
mojavi3のviewにあるdecorator ってプロパティーはどんないみあるの
628:1-627
05/11/28 10:56:11
すみません、全て解決しました。
629:nobodyさん
05/11/28 16:28:05
>628
流行ってんの？
630:nobodyさん
05/11/28 17:36:24
なあに、かえって免疫力がつく
631:nobodyさん
05/11/30 04:52:05
cakephpでADODBって実質使えないな…
selectLimitらへんとか、あの作り方じゃまともな対応期待できそうにないな
632:nobodyさん
05/11/30 17:47:33 yPyLs/p1
>>631
詳しく
633:nobodyさん
05/11/30 17:48:31
>>495
これどうなったんだろ
携帯に対応しやすいフレームワークって面白いかと思ったんだけど
Mapleの半角<-->全角とかも日本らしいくて、こっちも携帯とか期待できるのかな
634:nobodyさん
05/11/30 18:21:22
>>632
一番てっとりばやいのは、oracle8iとかDB2とか動かすこと。
まともにうごかない。
cakephpのselectLimitのソース見るとわかるけど、adodbの機構一切つかわず
Limit生書き。コメントにも、「adodbがlimit句のsql文取得するためのもの持ってないんで対応できませーん」
みたいなこと書いてある。
635:nobodyさん
05/11/30 22:27:42
ほんとだ...
でもこれ、lastInsertId()が単なるプレースホルダーで、呼んだ瞬間にdie()だから、
動かないのは当然だよね? Model::save()で死ぬし(w
wikiのドキュメントにあるadodb対応っていう看板はまだ外しておくべきだな。
636:nobodyさん
05/12/01 13:07:20
でもよく考えたら adodb にdbごとの適切なLimit節文字列を返す機構ってあったっけ?
adoのドライバのレベルの話?
AdoConnection::selectLimit() を使えよって話なら、そもそも "to get correct limit string"
するためのものじゃないし、上のレベルのModelはこのために全面改装が必要になるし。
637:nobodyさん
05/12/01 13:12:50
関係ないがadodbはReplaceの形でinsertとupdateもできるようにしてくれ。
あとautoquote時に数字もquoteしてくれ。
text型に入れてても000000が0になる。
638:nobodyさん
05/12/01 15:46:10
どのフレームワークでもいいんですが、フレームワークを使ったオープンソースな
ソフトってご存じないですか?
639:nobodyさん
05/12/01 15:57:03
存じております
640:nobodyさん
05/12/01 16:17:39
URLﾘﾝｸ(www.horde.org) の IMP や Chora とか。
Mojavi の知りたい。
641:nobodyさん
05/12/01 16:57:05
>>636
＞でもよく考えたら adodb にdbごとの適切なLimit節文字列を返す機構ってあったっけ?
文字列を返すのはないよ。
適切に実行することはできるけど
642:nobodyさん
05/12/01 21:07:40
>>639
存じておりましたら存じているものをここへ書いて下さい
643:nobodyさん
05/12/01 23:21:16
quickformでプルダウンメニューの入力チェックしたいんだけど、addruleでやってもうまく機能しません。
何故？
644:nobodyさん
05/12/02 01:43:30
BasicSecurityFilter使うと無限forwordループならね～か？
645:nobodyさん
05/12/02 06:04:33
>>642
WaWaWa
>>643
多分書き方がおかしい
>>644
使ったこと無い
646:nobodyさん
05/12/02 07:05:58
日経システム構築に、
セキュリティーの観点からは
DB格納の直前にもバリデーション行うべきって書いてた。
確かにそう思うけど、
となるとフレームワーク使った場合、
プレゼンテーション層とビジネスロジック層の
両方でバリデーションすることになるよね。
そのあたりどうしてる？
同じ一つの定義を読むのか、
ビジネスロジック層のバリデーションを簡易的なものにするか…
647:nobodyさん
05/12/02 07:11:52
＞DB格納の直前にもバリデーション行うべき
なにこれｋｗｓｋ
648:nobodyさん
05/12/02 07:28:41
>>647
普通はだいたい、
フレームワークに用意されたバリデーションをまず行ってから、
そのデータをDAO的なクラスに渡してDBに書き込むじゃん。
DAO的なクラスでも、
一度バリデーションを受けてるはずだからといってデータを信用するのではなく、
そこでも精査すべきだということ。
コードコンプリートでいう
防御的プログラミングというやつだね。
649:nobodyさん
05/12/02 08:58:48
>>648
了解
djb的思想だね
650:nobodyさん
05/12/02 10:37:43
みんなDAOな作りしてんの？
なんかDAOにしちゃうと、リッチなSQL書けなくならない？
又は、ビジネスロジックがDAOに入っちゃう。
だって、リッチなSQLってビジネスロジック含むじゃない？
651:nobodyさん
05/12/02 14:09:33
RDBMSはオブジェクト指向じゃないから。それをオブジェクトで取り出そうとすると、どこかしらに無理が出てくるのはしょうがない。
652:nobodyさん
05/12/02 14:37:00
そんなのは前提としてさあ
653:nobodyさん
05/12/02 14:37:10
DAOって再利用性けっこう低くない？（スキル低いだけって言われそうだけどorz）
再利用性を高くしようとすると、SQLを直につっこんでもあんま変わらないし。
特定の用途にカスタマイズすると再利用がだんだん難しくなるし。
できる奴はうまいことDAO作ってんのかな？
それともDAOって毎回がんばって作る宿命？
654:nobodyさん
05/12/02 16:01:31
>>653
DAOを上手く利用しようとするなら自分独自のクエリーを作ってそれを
各SQLに対応したクエリーに変換するclassを自分で作るしかない。
今の段階のDAOは・・・あまり意味がない。
655:nobodyさん
05/12/02 16:12:42
一人で開発してて、手が早いひとならSQLを直に書いたほうがいいんじゃないの。
大規模開発なら、APIを統一しないとやってられないだろうね。
656:nobodyさん
05/12/02 21:18:36
mojavi2ってPHP5で動かないの?
657:nobodyさん
05/12/02 21:37:14
mojavi3 が PHP5 用。
658:nobodyさん
05/12/02 22:16:38
>>657
mojavi3は終了して今mojavi4作ってます。
agaviも0.10 目指してｶﾞﾝｶﾞｯﾃます。
659:nobodyさん
05/12/03 02:41:18
>>658
Mojavi4進んでなくない？
これじゃagaviと合体する前に消滅の悪寒。
660:nobodyさん
05/12/03 06:50:17
シンフォニー力入ってんなぁ。
661:nobodyさん
05/12/03 06:53:47
新興フレームワークの方が発展していきそうだね
いずれにしろまだどれも固まってないから実務には使えない…
662:nobodyさん
05/12/03 10:52:29
今一番日本語のドキュメントがまとまっているのがEthnaかな？
現在勉強中。
663:nobodyさん
05/12/03 11:44:20
maple、DI入ってるからよさそう。EthnaはまだDIないし。
664:nobodyさん
05/12/03 11:45:19
まあ、Struts→Ethna Seaser→Mapleっていう構図だよな。
665:nobodyさん
05/12/03 13:18:46
>>663
そうだね。
Spring frameworkの紹介記事読んでMapleに興味持ったけど、
フレームワーク初心者にはちとドキュメントが足りない・・・。
後、データアクセス層のサポートがﾎｽｨな。
666:nobodyさん
05/12/03 19:53:00
EthnaやMapleは絶対にスタンダードにはなり得ない。
Mojaviでギリギリだろ。実質Zendフレームワークのだけじゃね？
EthnaやMapleなんか勉強しても無駄だからやめておけ。
667:nobodyさん
05/12/03 20:18:20
>>666
できればその理由なんかも・・・
668:nobodyさん
05/12/03 20:30:55
リリースされたZEND謹製フレームワークを見て
ケツから血を流すがいいです
669:nobodyさん
05/12/03 20:46:32
kunitﾀﾝはEthna,Maple,Seasar PHPと手を広げすぎないで
完成度を高めてほしい、というのはある。どれも中途半端。
670:nobodyさん
05/12/03 21:37:16
どっちかっていうとDI/AOPやらRoRやら概念的なことに手を広げすぎているような
あれもこれも取り入れたいってのは分かるんだけどね・・・いつまでたっても完成は出来んわな
671:nobodyさん
05/12/03 23:22:07
mojavi2を使用しているのですが、
php4.4.1でエラーが発生する事を今知りました。
もう開発は終わっているとの事ですので、修正される事はないんですよね？
このような点を考慮するとagaviというのを使った方がいいのでしょうか？
レンタルサーバの関係でphp5での使用は考えていません。
mojaviは気に入っていたのでmojavi系が良いと思っています。
672:nobodyさん
05/12/03 23:31:37
ソースはあるんだし、修正すればえぇやん
673:671
05/12/03 23:58:35 QwnhGijP
>>672
確かにその通りです。
今回のエラーは修正できますが、割と時間がかかりそうな場合や
自分では修正できないような時を考えてできるだけメンテが活発に行われている
物を使用したいと思ったまでです。
674:nobodyさん
05/12/04 00:14:45
どっかにパッチあったよ。
どっかに。
675:nobodyさん
05/12/04 00:34:35
>>671
URLﾘﾝｸ(www.stackasterisk.jp)
676:671
05/12/04 00:50:01 OBVYrvMK
>>675
どうもありがとうございます。
助かりました。
677:nobodyさん
05/12/04 02:19:47
>>676
というか、バグがあるからmojaviJapanのエラーの修正入っているやつにしれ
678:nobodyさん
05/12/04 02:25:41
ユーザ登録、メール送信、URLのクリックで認証というのをmojavi2でやりたいんですが
そういうコードないですかね
679:646
05/12/04 04:33:57
一番嫌なのが巨大なデータをSQLに仕込まれることなので、
データのサイズチェックだけすることにしたよ。
後はサニタイズだけちゃんとしておけば致命的にはならないだろう。
680:671
05/12/04 22:56:24 gXRf3OY+
>>677
そんなのがあるんですか。知りませんでした。
681:nobodyさん
05/12/05 02:11:12 dkL9yz1o
>>666
PHPの言語仕様自体がころころ変わっている最中なのに、
スタンダードなものは作れないと思われ。
でもオレオレフレームワークで好き勝手に作るよりは、上手い人の
エッセンスを流用して作る方がいいと思うので、現時点でマニュアルが
充実してて、開発を放棄されていない奴を選べばいいのでは？
682:nobodyさん
05/12/05 09:12:05
>681
そうですね、私は別にスタンダードじゃなくても、使いやすければいいか､と思ったりします｡
フレームワーク使い始めるまでは無手勝流でコード書いてたし､いまだにmojavi2使ってるし｡
また新しいのがでてた｡
XOAD
URLﾘﾝｸ(www.xoad.org)
683:nobodyさん
05/12/05 12:48:08
フレームワーク祭りだなほんまに
決め手にかけるところがPHPらしいというかなんというか･･･
684:nobodyさん
05/12/05 16:13:57
Mjavi2が主流ですか？ それともEthnaやMapleですか？ おすすめ教えて
685:nobodyさん
05/12/05 16:17:35 dKNEsuCU
>>684
個人的には maple。
もっとも、そのままじゃ実用に耐えないからかなり改造して使ってるが。
686:nobodyさん
05/12/05 16:20:36
俺は大したもん作らないからguessworkの自主改造版ぐらいで丁度いい。
687:nobodyさん
05/12/05 16:20:50
>>685
ありがとう。Mapleは実用に耐えられないわけですね。 やはりMojavi2かな。
688:nobodyさん
05/12/05 16:21:48
>>686
ありがとう。guesswork ってののあるわけですか・・・。 guessworkはいいですか？
689:nobodyさん
05/12/05 16:22:28
M2も結構手入れしないといけないから
グチャグチャになりがち
690:nobodyさん
05/12/05 16:27:15
>>688
guessworkはvalidatorが貧弱だったりするからその辺を補完して、認証とかサイト毎に
必要な機能を付ければ俺的には充分。
作成するファイルが少ないってのも俺好み。
691:nobodyさん
05/12/05 16:37:22
PHP5用のguessworkは結構期待してるんだが
なかなか出ないね
692:nobodyさん
05/12/05 16:43:21
mojavi2ってPHP4用ですよね？
一応ご確認あれ>>684
日本語の資料が一番まとまってそうなのは速構Web Frameworkかな？
URLﾘﾝｸ(www.pm9.com)
但し有料。
次点はEthnaじゃなかろうか？
URLﾘﾝｸ(ethna.jp)
693:nobodyさん
05/12/05 16:45:27
つーかガキじゃないんだから日本語の資料とかいらんでしょ？
英語でも読めて当然だろ、普通のＳＥなら大学ぐらい出てるんだからさ。
694:nobodyさん
05/12/05 16:55:24
>>690
guesswork素敵でつた。 補完したのコッソリ下さい。
695:nobodyさん
05/12/05 16:59:09
「このフレームワークを選ぶ理由は何ですか？」
つー質問に答えなきゃいけない立場の人は大変だろうねぇ。
696:nobodyさん
05/12/05 17:12:31
>>693
なにいきり立ってんの？
日本語の資料の充実度っていう軸でみてなんか不都合でも？
697:nobodyさん
05/12/05 17:14:56
>>696
たとえばメンテナの数や、たとえばコーディングのしやすさ
先に見るべき場所がほかにあるでしょ。
日本語マニュアルなんて、あればいいな程度のものを最初に持ってくる神経を疑う。
698:nobodyさん
05/12/05 17:22:54
>>697
まあそうだけど、フレームワークの概念自体を勉強したいっていうニーズだって
あっていいでしょ？
自分がプロのSEだからって視野が狭すぎ。
>>684が学生か社会人かもわからんだろうに。
699:698
05/12/05 17:25:34
あ、でも貴方の意見には全面的に賛成なんで、プロの目からみたお勧め教えて。
700:nobodyさん
05/12/05 17:33:00
理解するためのコストが高いと
取り組むリスクが大きくなるから
日本語資料があるに越したことはないね。
701:nobodyさん
05/12/05 17:34:02
>>699
俺が使ってるのはmojavi系。正確には2.00にパッチ当てたりして少しだけ拡張した奴。
メンテナの数が違う…が2,3,4,agaviとメンテナが分離気味なので動向を見守っているところ。
ことフレームワークなどに関しては、勝ち馬に乗るべきだと思ってる。
俺もメンテナが多いのが生まれたらそれに乗り換える。
ただ残念なのは、そうやってフレームワークが普及しても思ったよりネットでのコード共有が進まなかったこと。
みんな自分の書いたものは見せずに、他人のものばかり見たがる。俺もだがｗ
702:nobodyさん
05/12/05 17:34:38
英語の出来ない部下を持つ身としては、日本語資料は必須。
703:nobodyさん
05/12/05 17:38:15
言い方キツかったのは謝るよ。
すまないね。
>>702
それ結構悲惨だな…でもサンプルコードあったら理解してくれない？
PEARとでも英語しかマニュアル無いもの結構あるけど、どうするんだよ。
704:nobodyさん
05/12/05 17:43:02
>>703
サンプルを用意してあげて、ケツを蹴る。
705:nobodyさん
05/12/05 17:45:54
日本人雇わなきゃいいだけ
706:698
05/12/05 17:55:32
>>701
どうもありがとう。参考になります。
mojaviはagaviと統合してから手を出そうかと思ってました。
こちらも英語ができない部下（しかも直属じゃない）がいて、
しかも自分を含めて本職はSEじゃ無かったりします。
なんで、「わからないならソース嫁」と言いたいところですが飲み込むこともありｗ
でもメンテなの多さは魅力だな。早いうちにmojaviの資料にも当たっておこう。
707:nobodyさん
05/12/05 18:05:20 dKNEsuCU
mojavi はゴチャゴチャしててちょっとなぁ…。
708:nobodyさん
05/12/05 18:24:01
>693
うはっｗ
こういう奴ってまだいるんだｗ
709:nobodyさん
05/12/05 18:28:40
愛して欲しいのさ、本当はね
710:nobodyさん
05/12/05 18:33:47
お師様、温もりを…
711:nobodyさん
05/12/05 20:31:13
俺もmojavi4を待ってる状態だな。
邪魔になるかなとは思いつつTylerにメールして進捗を聞いたりした
11月の中ごろにはあと2ヶ月くらいで出来るとのことだったがその後音沙汰がないのが心配だｗ
712:nobodyさん
05/12/05 20:33:12
>>707
ごちゃごちゃしてるか？
mojavi2系に限ってならだけどかなりシンプルにまとまってると思うが・・・
713:nobodyさん
05/12/05 20:33:25
PHP4はもう置き去りですね・・・
714:nobodyさん
05/12/05 23:03:05
PHP4でもPHP5でも使えるやつってある?
715:nobodyさん
05/12/05 23:06:57
4.40以降に対応してる奴は多分両方いけるでしょ。
意味無いから試してないけどね。
716:nobodyさん
05/12/06 02:35:30 8b+BGlil
待ってたらいつまで経っても開発できないじゃん
現状ではメジャー技術を参考にしつつ自前開発するしかなさげ
だいたい大きな考え方はどのフレームワークにも共通するしね
717:nobodyさん
05/12/06 09:29:17
mojavi3いいよ。
オブジェクトの使い方とか理解しやすい。
718:nobodyさん
05/12/06 12:37:55
PHPについて初心者にも良く分かるように説明したサイトありませんか？
書籍の紹介でも構わないのですが。
719:nobodyさん
05/12/06 12:43:24
スレ違い
720:nobodyさん
05/12/06 12:45:34
>>718
URLﾘﾝｸ(www.php.net)
コレ
721:nobodyさん
05/12/06 13:20:37
どうしてこういう事を書けるのかホントに疑問だな>>718
スレタイ読まないのはまあ百歩譲るとして他のレスちょこっと読めばわかるもんだろ普通
722:nobodyさん
05/12/06 15:21:22
誤爆しただけです。すみませんでした。
723:nobodyさん
05/12/06 15:27:03
あっそう
724:nobodyさん
05/12/06 15:34:12
釣ってみただけです。すみませんでした。
725:nobodyさん
05/12/06 15:35:58
はいはい
726:nobodyさん
05/12/06 15:40:42
>>722
URLﾘﾝｸ(www.jca.apc.org)
727:nobodyさん
05/12/06 15:44:53
全て私一人の自作自演です。済みませんでした。
728:nobodyさん
05/12/06 18:30:42
>>716
そうやって沢山のフレームワークが出てきているこの現状
開発手伝ってやれや
729:nobodyさん
05/12/06 20:01:58
>>653
DAOとO/Rマッピングの区別ついてる？
730:nobodyさん
05/12/06 20:10:08
Agaviあたりが一番無難だと思う。
薄っぺらだから、把握するソースも少なくて済むし。
正式リリースはされてないけど、svnは着々と新しいクラスも
作られてる。
至れりつくせりなフレームワークは、いまのところ完成度が
低いものばかりなので。
pradoは完成度的には高いけど、XMLファイルの設定とか
結構面倒。
個人的にはsymfonyに期待してるんだけどね。
731:nobodyさん
05/12/06 22:51:06
結局Mojaviですよね
732:nobodyさん
05/12/06 23:32:14
あのー、function & getAuthorizationHandler ()
この、& の意味は何ですか？
733:nobodyさん
05/12/06 23:36:36
それってフレームワーク関係ないでしょ
734:nobodyさん
05/12/06 23:38:54
あのー、じゃあ何ですか？
735:nobodyさん
05/12/06 23:39:38
ＰＨＰのくだらない質問スレ
736:nobodyさん
05/12/07 00:25:58
>>732
山椒だよ。
737:nobodyさん
05/12/07 00:26:56
ピリリと辛い
738:nobodyさん
05/12/07 04:47:59
フレームワークのControllerを開始するメソッドの名前が
dispatchで、辞書で調べると
「打ち負かす」とか「急送する」とかの意味らしい。
いまいち合ってない気がするけど
何か言われがあるのかな。
executeで良くね？と思うんだが。
739:nobodyさん
05/12/07 04:59:46
実際の処理(ビジネスロジック)をする(execute)のはControllerじゃなくてModelだし、
Controllerは単にリクエストを適切なActionへ発送(dispatch)するからじゃね？
740:nobodyさん
05/12/07 05:49:46
あーなるほど。
741:nobodyさん
05/12/07 06:05:54
dispatchはどっちかというと「割り当てる」って意味だよ。
そこらのフレームワークはStrutsの影響だと思うけど、元々はOSのスケジューラがスレッドをCPUに割り当てるって意味。
MVCフレームワークではリクエストに応じてactionだのviewだのを割り当てるってこと（>>739はその意味で当たってると思う）。
loadなんかも「積む」って意味をこえて、メモリからレジスタにデータを読み込むって意味だったものが、ファイルなどの内容をメモリに読み込むって意味に転じて、果てにはWebサーバからブラウザにデータを読み込むってことにまで使われるようになった例だし。
742:nobodyさん
05/12/07 10:15:56
>>736
ありがとう。ピリリと解決。
743:nobodyさん
05/12/07 17:30:53
>>730
agavi.jpの更新が完全に止まっちゃってるのが残念だね。
744:nobodyさん
05/12/07 20:43:55
最近はここだよ。
翻訳してくれてる。
agaviユーザ多いかな。
URLﾘﾝｸ(www.geocities.jp)
745:nobodyさん
05/12/07 21:00:25
>>744
おお、こんなとこあったんだ。
サンクス。
746:nobodyさん
05/12/07 22:03:43
つか、Ajaviは公式が0.9から全然動きが無いな。
747:nobodyさん
05/12/07 22:05:08
svnは？
748:nobodyさん
05/12/07 23:01:18
>>747
snvでは結構更新あるよ。
749:nobodyさん
05/12/07 23:23:39
zend frameworkｷﾀ━━(ﾟ∀ﾟ)━━━!!!
hURLﾘﾝｸ(www.phparch.com)
750:nobodyさん
05/12/07 23:50:26
>>749
英語のプレゼンだからサッパリわからんが
PHPをﾋﾟｨﾁﾋﾟｰと発音することは分かった
751:nobodyさん
05/12/07 23:53:53
ははは
もれもそれ思ったよ！これからﾋﾟｨﾁﾋﾟｰって言おう！
752:nobodyさん
05/12/08 06:40:50
>749
これっていつごろできるの？
753:nobodyさん
05/12/08 08:49:04
けっこうagaviに似てる気がする
754:nobodyさん
05/12/08 18:17:58 v7tgLnK2
>>741
じゃあdispatchからのforwardってなんなの？
755:nobodyさん
05/12/08 18:25:17
>>754
「転送する」とか「回送する」とかの意味があるから、「処理をまわす」と
いう意味合いじゃないの？
つか、ここは英語のスレじゃないんだが。
756:nobodyさん
05/12/08 22:50:03
Zendフレームワークっていつリリースか明記してある？
757:nobodyさん
05/12/08 23:13:00
±1.5ヶ月でね
758:nobodyさん
05/12/09 12:10:21
>>749
プレゼンが下手糞で途中で飽きた。
文章でまとまってるのないの？
759:nobodyさん
05/12/09 12:21:49
流行りだからって何でもかんでもPodcastすればいいってもんでもないよね｡
テキストなら大事なとこだけ拾い読みできるのに｡
760:nobodyさん
05/12/09 12:43:07
メディアを云々する前にまずGoogleを覚えようぜ
761:nobodyさん
05/12/09 14:16:53
誤爆ですか？
762:nobodyさん
05/12/09 17:59:40 kJFA21a1
Decorator使ってる時にリダイレクトしたら、
サブテンプレート作成中に処理がブチギレるよね。
ポストフィルタでリダイレクトすべきなのか。
そのあたりどうしてる？
763:nobodyさん
05/12/10 14:39:54
質問です。
mojavi2でSmartyを使っています。
XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。
$lblocks = array(array('title' => 'エラー',
'content' => '<div><{$error}></div>'));
$renderer->setAttribute('xoops_lblocks',$lblocks);
すると<がサニタイズされて>に変換されて、html上表示されてしまいます。
サニタイズさせない方法ってあるでしょうか?
764:nobodyさん
05/12/10 19:34:26
>>763
$smarty->left_delimiter = '<{';
$smarty->right_delimiter = '}>';
てか、、マニュアル嫁
765:nobodyさん
05/12/10 23:53:59
>>764
>>763の
>XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。
とあるように、その設定はXOOPSのテーマを使うために既にしています。
そのために<と>がサニタイズされて困っているんです。
その設定をしなければ、{と}だけで問題ないのです。
テーマ側に<{$error}>と書けば問題ないのですが、setAttributeで渡そうとすると
サニタイズされてしまいます。
766:764
05/12/11 01:36:43
>>763
>smartyのデリミタが<{と}>です。
これ読めてなかった… すまん、763
767:762
05/12/11 11:51:35
リダイレクト後にexitしてるのが問題だっただけだった。
リダイレクトっていっても
ヘッダに出力するだけで、
処理が止まるわけじゃないんだよな。
768:nobodyさん
05/12/12 19:50:27
mojavi3つかってます。
modelで$this->getContext()->getRequest();するのと、
actionで$this->getContext()->getRequest();してモデルに渡すのと
どっちがmvc的に正しいですか？
769:nobodyさん
05/12/12 20:44:06
>>768
モデルはコントローラやビューと結合していないのが理想なので、action で
リクエストを取得して、それに応じて model に渡すのがよいと思う。
770:nobodyさん
05/12/12 20:44:31
「結合してない」って言い方は悪いな。「疎結合」に言い替える。
771:nobodyさん
05/12/12 20:44:42
>>768
前者の方がmodelとactionの結合が疎になりやすい。
772:768
05/12/12 21:33:07
どうもありがとうございました。
さっぱりしました。
773:nobodyさん
05/12/12 23:43:46
>>769
えええええええええええ？
だったらなんでmodelに
$this->getContext()->getRequest();
できる機能わざわざつけてあるのさ。
actionもMVCのmodelに相当するんじゃないの？
model内で
$this->getContext()->getRequest();とかやって、
actionでgetModelするのが普通だと思うが。
>>772よ。すっきりするのはまだ早い
774:nobodyさん
05/12/12 23:50:24
moja3て、Modelがあんだ～
class HogeModel extends Model って感じ？
775:nobodyさん
05/12/13 00:06:36
>>773
> actionもMVCのmodelに相当するんじゃないの？
違うよ。controllerとmodelのアダプタ（アダプタパターンとは別の意味）。
controllerの一部をコマンドパターンとして抽出したとも見れる。
だから本当はactionはビジネスロジックを書くところじゃないんだけど、ロジックもそのまま書けてしまう手軽さは利点であり欠点でもあると思う。
requestをいじるのはcontrollerであるべきだと思うから俺はaction内でgetRequestして、相応のmodelを呼び出す派。
776:768
05/12/13 01:51:59
やっぱり、model内で
$this->getContext()->getRequest();
のはなんか気持ち悪い。
777:nobodyさん
05/12/13 01:56:13
俺もactionでrequest派。
最初はmodelでやっていたが
そうなると、起点となるactionを見ただけでは
どんなパラメータをいじっているのかが分からず、
流れを把握しにくくなったから。
またリクエストパラメータはどちらかといえば
プレゼンテーション層に属するものなので
プレゼンテーション層であるactionで受け取るのが理にかなっている
とも思う。
バリデーションやコンバートはactionでやってるんだから
ノータッチでmodelに渡していても疎結合とは言えないのでは？
むしろactionで受け取ってmodelに渡すというレイヤパターンにした
方が疎結合といえる気がする。
778:nobodyさん
05/12/13 10:18:09
model で request 処理すると，model の unit test がやり辛くなると思う
それって context と request の両方を外部に依存することになるし
action で request を処理しちゃえば model は request の「値」のみに依存することになり
より疎結合になる
# なんてことを周囲に喋ると「日本語喋れ」とか言われる罠ｗ
779:nobodyさん
05/12/13 11:29:59
記述が楽＝疎結合じゃないんだよね
プロトコルを増やすわけだからむしろ記述は面倒くさくなりがち
780:nobodyさん
05/12/13 14:13:53
>>773
フレームワークが許容しているのと、理想的な設計との間には
隔たりがあるってことを理解するべき。
元の質問は
> どっちがmvc的に正しいですか？
‥なので、MVC 的には action に依存しない方が理想だろうね。
>>778 のいう「unit test がやり辛い」ってのは、model がフレームワークと
密接に結合していて使い勝手が悪い証拠。結合度が高いので、再利用しずらい
(再利用する時に、間接的にフレームワークにも依存することになる)。
model と action を分離しておけば、例えば、Web アプリとは別に DB に対する
バッチ処理を PHP で書く必要がでてきた時に model を流用できる。
ただ、理想的な設計が、即座に現場で適用されるべきかというと、それは
また別問題だけどな。
781:nobodyさん
05/12/13 18:51:28
>>780
いや、疎結合とかはlib側で考えるもんなんじゃないの？
＞フレームワークが許容しているのと、理想的な設計との間には
＞隔たりがあるってことを理解するべき。
許容じゃなくて、意図的に実装してるんだとおもうんだけど。
modelは明らかにactionと密接な連携を取るためのものだと思うし。
＞model と action を分離しておけば、例えば、Web アプリとは別に DB に対する
＞バッチ処理を PHP で書く必要がでてきた時に model を流用できる。
その流用はlibでつくったもののがやりやすいよね。
782:nobodyさん
05/12/13 18:54:29
>>777
自分は逆にactionはどんなmodelを使ってるかの道しるべとして使ってるから
流れ把握は全然困らない。てかむしろしやすい。
783:nobodyさん
05/12/13 18:59:51
てか、そもそもlibの存在忘れて疎結合とか言ってない？
784:nobodyさん
05/12/13 19:08:07
libって何さ、ライブラリ？
785:nobodyさん
05/12/13 19:10:01
なにこの流れ。
スゴいお勉強になるんだけお。
786:nobodyさん
05/12/13 19:11:38
>>780の言う「許容」ってのはModel内で$this->getContext()->getRequest()できちゃうって話だよね？
>>781と微妙に噛み合ってないみたいだけど。
つーかMojaviに関して言えばContextに一貫性を持たせようとした結果、たまたまModelの中でもRequestが取得できてしまうとも見れると思う。
その意味ではMojaviの欠点の一つかもしれんな。
まあ>>773から反論がない限りはgetRequestはActionでやるべきってのは満場一致でしょ。
その結論に至る思考プロセスが個々人いろいろなのがおもしろいなｗ
787:nobodyさん
05/12/13 19:18:52
>>786
ん？かみ合ってないのか？
＞つーかMojaviに関して言えばContextに一貫性を持たせようとした結果、たまたまModelの中でもRequestが取得できてしまうとも見れると思う。
つまり、Requestだけはmodelでやるべきではないってこと？getControllerやgetUserはありで？
だったらかみ合ってないてのはわかるんだけど。
>>784
いや、libはautoloadで定義するやつよ。
こいつにこそ疎結合を求めるもんだとおもうんだけど…
788:nobodyさん
05/12/13 19:21:40
>>786
ちなみにlibとmodelはどう区切ってる？
789:nobodyさん
05/12/13 19:34:56
M2のactionChainがなくなったのも、デコレータだけじゃなくgetModelが
追加されたからなんだと思うし…
790:786
05/12/13 19:40:45
>>787
いや、「かみ合ってない」って言葉が気に障ったなら気にしないでくれ。
疎結合の話に対してではなく、request云々の方で感じたこと。
> 許容じゃなくて、意図的に実装してるんだとおもうんだけど。
の部分ね。
modelとlibのどちらに疎結合を求めるかってのにはノーコメント。
俺の場合はlibにフレームワークのコンポーネントから外れた自分クラスとかは入れないんで。
多くはModelで、あとはSmartyの実装が微妙だったころに改造したViewとか。（最新バージョンがどうなってるのかはチェックしてない）。
> つまり、Requestだけはmodelでやるべきではないってこと？getControllerやgetUserはありで？
まあそういう風に見るとrequestとuserの非対称性が浮き彫りになるが、俺の場合は結果的にはそういう方針でやってるよ。
Modelの中でgetRequestを呼び出すのはせいぜいsetErrorするときだけだな。
>>788
前述の通り、俺的には「区切ってる」っていう感覚ではあまりない。
共通して使うものをlibに入れるだけ。
791:nobodyさん
05/12/13 19:51:24
フレームワークだから
ある程度の自由度を残してるのは当然ともいえるし
どっちもｱﾘっちゃｱﾘだな。
792:nobodyさん
05/12/13 19:54:09
>>790
なるほど、そういうことね。確かに勘違いだわ。
でも、
＞まあそういう風に見るとrequestとuserの非対称性が浮き彫りになるが、俺の場合は結果的にはそういう方針でやってるよ。
getUserもmodel内で使ってるんだ？
ますますわからんくなってきた…
ちなみに
URLﾘﾝｸ(forum.mojavi.org)
ここにあるようなソースはアリなんだよね？
793:nobodyさん
05/12/13 19:56:03
context自体を渡すことがおかしいって言ってるのかと勘違いしてた。
794:nobodyさん
05/12/13 19:59:28
どっちにしても、自分の場合、actionはアダプタじゃなくてmodelで、
action内が複雑になりそうなときmodelに助けを求めるって感じでやってるから。
例えmodel内でgetRequestしても自然なつもりなんだけどなぁ
795:768
05/12/13 20:11:31
じつはagaviでした。
agaviだとみんな食いついてくれないと思ったので.
結果予想以上に皆さんの意見が聞けてよかった。
796:nobodyさん
05/12/13 20:13:34
>>792
うーん、そこのソースのマズイ部分ってとりあえずどこ？ｗ
つーかgetUserをModelでやるのっておかしいかな？言われてみると少し迷うな。
ログインの処理をする専用のModelとかそのままsetAuthenticatedしてるのと、あとはaddCredentialみたいなのもModelの中でちらほらやってしまっている。
もろにビジネスロジックかと思うんだが。
>>794
まあどういう風にやっても間違いってことはないと思う。
Actionにビジネスロジックを書いても結果的には「ロジックとデザインの分離」っていう大元の目的は達成されてるわけだし。
797:nobodyさん
05/12/13 20:28:15
>>795
みなさんというか、２、３人だと思うけどね。自分含めてｗ
798:nobodyさん
05/12/13 20:31:02
>>797
まーこの板はそういうとこだよなｗ
799:nobodyさん
05/12/13 20:34:29
>>796
＞うーん、そこのソースのマズイ部分ってとりあえずどこ？ｗ
その感想自体が答えですｗ さんきゅｗ
＞ログインの処理をする専用のModelとかそのままsetAuthenticatedしてるのと、あとはaddCredentialみたいなのもModelの中でちらほらやってしまっている。
まぁたしかにgetUserはその辺の機能があるからね。言われれば気持ちはわかる。
ちなみに開発人数はどれくらい？
自分のとこの場合人数が5人で中途半端だから、下手に縛り設けようにもうまく機能しないことが多いんだよね…
フレームワークで許されている権利は使ってよしってことにしてるからってのもあるかも。
800:nobodyさん
05/12/13 20:35:06
userをmodelでいじるのは全然おかしくないと思う
つまるところセッションだし。
requestはブラウザから直接送られてくるデータだから、
いきなりmodelにいじらせるには生々しすぎる感じがするな。
801:nobodyさん
05/12/13 20:40:49
>>800
いや、それだと話がループする…
802:nobodyさん
05/12/13 20:42:35
>>800
そこはmodelで疎結合かどうかの話でしょ？
803:nobodyさん
05/12/13 20:45:33
>>800
＞requestはブラウザから直接送られてくるデータだから、
おいおい大事なget,setAttributeはどこいった？
804:nobodyさん
05/12/13 20:53:12
ひょっとして、getRequest＝ブラウザからのデータで話進められてたの？
805:nobodyさん
05/12/13 21:18:59
ああ、attribute忘れてたw
内部パラメータとしてのattributeならmodelでいじってもおかしくはないよね
viewに渡すためのコンテナとしてなら、
modelから受け取ってactionでこめこめするのがいいと思う
806:nobodyさん
05/12/13 21:31:18
modelでごにょごにょしたものはactionにいくのか？
それともviewか？
807:nobodyさん
05/12/13 21:38:24
>>792-793
model に context が渡ってること自体が気に入らない。理由は >>796 の人が
述べてる理由が近いかな。
>>805
attribute も model じゃ触らない。ビジネスロジックはコントローラに封じ込
めるべきってのは大体の人が賛成してくれると思うけど、attribute を
ビジネスロジックに一切関係ない使用例を見たことがない。もしあるなら
示してくれると、すごく嬉しい。
一般的(≒ Java の世界)にはそういう流れになってない？
モデルは POJO (getter/setter だけのオブジェクト) にして、必要に応じて
AOP でDAO や O/R マッピングしなさい、と。
808:nobodyさん
05/12/13 21:51:40
Javaとは言語仕様も実際の使われ方も違うのに、StrutsやIBMのホワイトペーパーと無理にあわせてもしょうがない。
809:nobodyさん
05/12/13 21:55:50
>>807
＞model に context が渡ってること自体が気に入らない。
えぇ？なんで気に入らないのに
>>796の人と同意なの？
根本的におかしいぞそれ。
810:nobodyさん
05/12/13 21:56:59
>>807
つまり、>>792のソースもおかしいってことだよね？
811:nobodyさん
05/12/13 21:58:05
>>806
actionにいってからviewじゃない？
直接viewにいくのはなんか気持ち悪いな
>>807
Model=POPOなの？
そこまで疎結合にするならModelをextendsする意味がないような…
俺はModel≒ビジネスロジックという認識だった。
812:nobodyさん
05/12/13 22:00:37
一般的ではなくm3やagaviで開発する上での話をしているので、
>>807の話はお門違いなわけだが
813:nobodyさん
05/12/13 22:04:25
mvc的に正しいのはって聞いてるんだから御門違いじゃないだろう
814:nobodyさん
05/12/13 22:05:40
まぁ、お門違いじゃないにしてもおかしなこと言ってるのは確かだな
815:nobodyさん
05/12/13 22:17:24
807は
モデルはフレームワーク自体からも疎結合である方がいいって意味だよね。
考え方は分からないでもないけど
そこまで疎にする必要がはたしてあるのか…
そもそもフレームワークを採用する時点で
全面的な依存を選択しているわけで、
モデルだけを疎結合することにどれほどの意味があるのか
816:nobodyさん
05/12/13 22:17:28
javaが一般的ってのも今は大分微妙になってるけどなぁ
817:nobodyさん
05/12/13 22:19:09
そもそもMVCモデルってそれぞれが密接に関連してるよなぁ
疎を考えるんなら777の言うようにレイヤーパターンで考えたほうが良いと思う
MVCパターンをレイヤーパターンに置き換えると
VCがプレゼンテーション層
Mがドメイン層とデータソース層
それぞれの層は独立していて別の層を知らないのが理想
actionはドメイン層とプレゼンテーション層の中間層かな？
だからactionは
プレゼンテーションからの入力（リクエストパラメータ）を受け取る
ドメインロジックを呼び出す
パラメータをドメインロジックに渡す
ドメインロジックでゴニョゴニョした結果をプレゼンテーションロジックに渡す
こんな流れがいいんじゃないかなぁ
結論、mojaviのModelクラスはｲﾗﾈ
818:nobodyさん
05/12/13 22:19:56
>>815
あぁ、激しく同意…
多分agaviも>>815みたいな思想があってああいう設計になってるんだと思う。
819:nobodyさん
05/12/13 22:23:54
>>817
それだとactionがちょっとややこしくなっちゃわない？
820:nobodyさん
05/12/13 22:33:04
>>815
>>817
おまいらユニットテストしないんですか？
>>819
むしろすっきりする
actionにロジック書くわけじゃないからね
あくまでAPIを呼び出して使うだけ
mojavi的にはこんな感じ
$id = $request->getParameter('id');
$service = new HogeService();
$hoge = $service->getHoge($id);
$request->setAttribute('hoge', $hoge);
821:nobodyさん
05/12/13 22:34:10
>>817
最後の結論だけ良く分からない
Model＝ドメインロジックで問題なくね？
822:nobodyさん
05/12/13 22:36:37
>>820
autoload.iniが大変なことになりそうだ。
823:nobodyさん
05/12/13 22:49:29
>>820
それってデータベースコネクションはどこでどうやって呼出してんの？
824:nobodyさん
05/12/13 23:00:01
autoload.iniの項目が多いとやっぱり遅くなるの？
おれはできるだけ使わんやつは消しとるよ。
825:nobodyさん
05/12/13 23:04:08
>>821
概念的にはその通りだけど
mojaviのModelクラスに依存したくないという意味でｲﾗﾈということです
>>822
それすごく悩んだけど
自前のクラスローダーで解決したお
>>823
DB接続用クラスをSingletonで作成してどこからでも呼び出せるようにしてるよ
DB::getConnection()みたいな感じで
といってもどこからでも呼び出してるわけじゃないけどね
826:nobodyさん
05/12/13 23:55:30
>>825
なんかもうそれ自分ルールだらけじゃん…
まぁ別にそれが悪いわけではないけど
827:nobodyさん
05/12/13 23:58:11
>>825
＞自前のクラスローダーで解決したお
それはautoload側をいじったのか、ロード関数みたいなのつくったのか
828:nobodyさん
05/12/14 00:01:27
結論
>>825のやってることは、agaviのmodelで解決。
無駄な作業乙
829:nobodyさん
05/12/14 00:34:57
もしかしてSingletonModelってクラス？
Singletonごときでなんであんなものに頼らなきゃいけないのか疑問・・・。
しかもグローバルに呼び出しできなくなるし
830:nobodyさん
05/12/14 00:41:56
PHPでシングルトンってほぼ無意味だよな。
831:nobodyさん
05/12/14 01:27:53
>>830
まあどちらかと言うと、インスタンス２つ以上作ろうとする方が頭どうかしてるもんな。
Controllerとか。
832:nobodyさん
05/12/14 01:43:05
>>830
リクエスト毎にオブジェクトが生成->破棄されるという意味では無意味だな。
ログとかＤＢコネクションとかでは使えるけど、それもグローバル変数に入れとけばいいみたいな。
833:nobodyさん
05/12/14 01:44:31
HTTPリクエスト単位で記憶が失われるPHPでは
シングルトンって「グローバル変数のオブジェクト指向版」みたいな意味しかない気がする
実際に役に立つのはDB接続みたいなリソース使いまわしくらいって印象が……
834:nobodyさん
05/12/14 01:46:05
>>824
クラスが必要なときのみ読みこむようにその設定があるんだし、そんなに気にしなくてもいいのでは。
まぁ少ないほうが早いに決まってるけど。
835:nobodyさん
05/12/14 03:49:22
>>825=>817
そこまで行くとMojaviの理念から外れてるし、それはもうmojaviから派生した>817のフレームワークであって、
とても「mojaviを使っている」とはいえないと思うが。
なのでmojavi(agavi)でMVCどうやるのか(requestをどう扱うか)っていう話においては参考にならない。
>>820
も同様
ただ、ユニットテストはMojaviの致命的な欠点だとおもう。
本題の"request"の扱いについてはModelはＣontrollerを知るべきではない、
そして"request"はControllerである。よって"request"は"Model"で扱うべきではない。
とおもうが。
実際はModelでしかたなくrequest呼び出したことありますごめんなさい。
設計が悪かった。反省してます。
836:nobodyさん
05/12/14 06:37:08
オブジェクトの依存性の話なのか設計上の規約も含めるのか判らん
837:nobodyさん
05/12/14 06:44:24
誰か両方の意見をまとめてくり
838:nobodyさん
05/12/14 07:15:24
いや、なんか感動。
疑問は晴れてないけど。
839:nobodyさん
05/12/14 10:23:55
図にしてみたぞ♥
Controller
↓
Request ⇔ Action ⇔ Model ⇔ User,Database
↓
Controller
↓
Request ⇔ View ⇔ Model
|
←｜→
プレゼンテー ｜ ドメイン層、データソース層
ション層 ｜
|
俺にとってActionとはControllerの一部であり、Requestの受付とModelの呼び出し以外のことはしない。
Action::executeすげーｼﾝﾌﾟﾙｳﾏｰ（AAry）。>>820、>>835と基本的に同じ。
俺にとってModelとはMojavi内で唯一ビジネスロジックを担当する部分である。
ちなみにModel以外はデータ層に触りません！
840:nobodyさん
05/12/14 11:25:24
Modelはどうまとめてる？
俺はOO的にうまいことまとまらない場合は
似たような関数をまとめてお茶を濁してる。
841:nobodyさん
05/12/14 11:38:43
>>839
Model にビジネスロジック入れたら駄目じゃん。話にならん。
842:nobodyさん
05/12/14 11:44:42
>>841
839じゃないけど
俺もModelはビジネスロジックを担当する部分という認識なんだが
きみのいうModelって何？
843:839
05/12/14 11:46:02
>>840
たしかに関数の入れ物に過ぎないModelができちゃうこともあるかもｗ
俺の場合はSean KerrのAction::executeのコメントで、
* Execute any application/business logic for this action.
*
* In a typical database-driven application, execute() handles application
* logic itself and then proceeds to create a model instance. Once the model
* instance is initialized it handles all business logic for the action.
*
* A model should represent an entity in your application. This could be a
* user account, a shopping cart, or even a something as simple as a
* single product.
っていうやつ（mojavi/action/Action.class.php）をけっこう意識しながらやってる。
Modelはentityを表すってのけっこうしっくりきてるかも。
つーか今読み返してみたら、Sean Kerr的にはActionでビジネスロジックもありっていうスタンスっぽいなｗ
ただ、基本はModel＝ビジネスロジックでしょ。
844:nobodyさん
05/12/14 12:08:56
訳：
Actionに対するアプリケーションロジック・ビジネスロジックの実行をします。
よくあるデータベースを用いたアプリケーションでは、execute()の中でアプリケーションロジックを扱い、続いてModelのインスタンスを生成します。
Modelの初期化をしたら後はその中で全てのビジネスロジックを扱います。
Modelはアプリケーション内のエンティティを表すようにすると良いでしょう。
例えば、ユーザーアカウント、ショッピングカートであったり、時には個々の製品といったシンプルなものであることもあるでしょう。
845:nobodyさん
05/12/14 12:12:22
>>844
そうそう。
やっぱり841はビジネスロジックの定義を勘違いしてないか？
エンティティーのメソッドはすなわちビジネスロジックだし。
Model＝ValueObjectと勘違いしてる気がする。
846:nobodyさん
05/12/14 14:28:05
みんな言葉の定義が微妙に違ってるだけだと思う。
というか、レイヤとモデルを微妙に混同してるのかも。
ドメイン層のレイヤにビジネスロジックがあって、
そこで操作されるものがドメインモデル（エンティティ）。
これをそのまま実装に反映させるなら、
ドメインモデルとビジネスロジックは別クラスにするのが自然。
だけどケースバイケースで、ドメインモデルのクラスが
ビジネスロジックのメソッドを持つ実装にするのもあり。
どちらがいいかは一概には言えないと思う。
>>845
それは違うよ。
ValueObjectはどちらかというとドメインモデルではなく
プレゼンテーションモデル。
ドメインモデルをそのままプレゼンテーション層まで引きずってくる
設計方針ならValueObjectぽっく見えるかもしれないけど、
プレゼンテーションモデルをきっちりわける設計方針なら
>>841の言ってるモデルはドメイン層で閉じてるはず。
847:nobodyさん
05/12/14 15:10:04
俺定義で議論してないでPoEAAを読め、ってことだ。
848:nobodyさん
05/12/14 16:18:44
高いから譲ってくれ
849:nobodyさん
05/12/14 16:45:40
O'ReillyのSafari Bookshelfに入れば$19.95で読めるよ。
850:nobodyさん
05/12/14 17:12:47
日本語訳本買ったけど読んでねーや
ValueObjectがプレゼンテーションモデルってどゆ意味？
単に値を持たせるオブジェクトだから
どんな層にでも入ってくる汎用的なパターンだと思うんだが
851:nobodyさん
05/12/14 21:59:44
> 単に値を持たせるオブジェクト
自説を立てるときはそれなりの手順を踏襲してほしい
852:nobodyさん
05/12/15 02:19:59
>>839
>>843を意識してるんなら、Actionはドメイン層、データソース層に入ることもあるだろ
853:nobodyさん
05/12/15 02:23:24
URLﾘﾝｸ(trac.agavi.org)
この公式サンプルも、全然>>839みたいな定義になってねぇし
854:839
05/12/15 03:13:21
>>852
たしかにそうだね。それが
> つーか今読み返してみたら、Sean Kerr的にはActionでビジネスロジックもありっていうスタンスっぽいなｗ
と言った理由なんだけど。
ただ、俺自身はドメイン層の処理はModelでやる方針でやってるって話。
Actionでドメイン層・データソース層に手を出すのも利点があるなら大いに結構だとは思うよ。
>>853
えーっと一応言っておくけど>>839は設計（or実装）方針の話ね。
（それまでの議論の内容も多少加味したつもりなんだが偏見もあるかも・・・）
あと、そこのサンプルは>>844の「ユーザーアカウント」にあたるものをModelとして抽出せずにActionで済ませちゃってるんだね。
だから839と違って見えるってのも無理はないかも。
まあロジックが複雑になってきたらそんなことは言ってられないので俺は認証用に作ったModelを再利用してるよ。
必要ならそのModelをもう一段継承してカスタマイズとかできるのでそこそこ便利だし。
855:nobodyさん
05/12/15 03:28:55
>>841に対して、はじめは何言ってるんだろうこの人…と、>>842と
同じ気持ちでしたが、
URLﾘﾝｸ(www.microsoft.com)
ここを読んでみて>>841の言ってることがよくわかりました。
MVCの図にあるとおり
＞ビューとコントローラの両方がモデルに依存していることに注意してください。ただし、モデルはビューとコントローラのどちらにも依存していません。
モデルは両方に依存していないものなんだね。
そう考えるとたしかに>>839の言ってる図は話にならない。
でも、それを言い出すとAgaviの設計自体がおかしいことになるね。
856:839
05/12/15 03:51:45
>>855
たぶんUMLを見慣れてる人が多いんだろうから誤解を与えたかもしれないけど、>>839は「依存関係」を表してるつもりじゃなかったんだなぁorz
Controller→Action→Controller→Viewってのは制御が移る順番。
他の⇔はデータの受け渡しであって、基本的にはメソッドの呼び出し＋リターンなので制御が移る順番としても解釈できるかも。
>>855が依存関係の話を持ってきてくれたのでそれも考慮すると、⇔の矢印をすべて外側向きに変えたら少しはましになるかな？
矢印の意味は
・依存してる側→依存されてる側
・呼び出し側→呼び出される側
という関係で。（唯一Action→Controllerの部分だけリターンなので矢印の色でも変えてくださいｗ）
「ビジネスロジック」って言葉は俺も再考する必要があるかも。
>>846をもうちょっと咀嚼してみる。
857:nobodyさん
05/12/15 03:53:25
URLﾘﾝｸ(forum.mojavi.org)
こういうの見るとますますわからんくなる…
858:nobodyさん
05/12/15 04:01:35
そこまでごちゃごちゃ深いこと考えなくても、
保守性の高いコードってWebアプリケーションなら結構つくれちゃうからなぁ…
ビジネスロジック云々より、ビジネスや運営自体について考えてたほうがよっぽど金になる
859:839
05/12/15 04:09:49
>>858
俺的もそう思う。どっちでもいーじゃんおまいらｗ、と
でも「間違っている」というつっこみをたくさんいただいたので、ヘコみつつ悪戦苦闘中であります。
860:nobodyさん
05/12/15 04:22:02
>>855
マジでAgaviのView周りってModelに依存性あるの?
ステートレスなWebアプリでは切り離されてるのが当たり前だと思ってたけど。
アクティブモデルにせよオブザーバはかませるっしょ
861:nobodyさん
05/12/15 04:40:08
View生成はクライアントリクエストのみを起点にしているから、
コントローラかアクションにぶらさげることは出来るね
前者はコントローラがMediator（と言ってもモデルかアクションから
データを受け渡すだけ）となり、後者ではアクションはコマンドオブジェクト
（ビジネスロジックとViewの呼び出しをカプセル化したもの）ということになる
どっちもパターンとしてはMVCとは呼ばないんだろうけど
URLﾘﾝｸ(www.martinfowler.com)
Viewがモデルに依存したほうがいいかアクションに依存したほうがいいか
まとまった見解ってある？
862:nobodyさん
05/12/15 04:43:36
>>860
Agavi自体の仕様では依存性は発生しないよ。Modelは一つもなくても動くし。
でもModelを使った時点で依存はゼロではないと思われ。
「切り離す」ってのはいわゆる疎結合にするって意味だとは思うけど、元々依存してしまうものだからせめて疎結合にしましょうって感じじゃなかったっけ？
>>855の言ってるのは、逆向きの依存はゼロってことでしょう。
「Viewを変更したらModelが動かなくなりました」とかしゃれになんないし。
でもModelを変更したらViewに支障が出るのは仕方ない。
それでも最小限にしましょうってのが疎結合だと思う。
オブザーバはContextのことでおｋかな？
863:nobodyさん
05/12/15 05:25:53
依存性＝オブジェクトをNewするかパラメータに取ってメンバにアクセスすること
結合の程度というようなファジーなものは存在しない
Framework界隈で依存性といったらこれのことだと思う
864:nobodyさん
05/12/15 05:52:18
> 結合の程度というようなファジーなものは存在しない
疎結合って結合の程度がゆるいことじゃないの？
つーかどのレスに対してなのか反論なのか何なのかわからんな。
865:863
05/12/15 06:11:06
直上に対するレス
結合にはもちろん程度があるよ
しかし依存性にはそういうものは無くゼロイチだということを言ってみた
>>860と>>862の愛でどうも考えている依存性が違って
かみ合ってないように見えたので
866:nobodyさん
05/12/15 06:12:18
× 愛で
○ 間で
すまん
間違ったものを芽生えさせた
867:nobodyさん
05/12/15 06:12:22
>>860
Modelにするにせよ別もんにしてつくるにしても、
初期のViewだけじゃなにもできんじゃん。
ごてごてタグとテンプレートと定数混ぜることになってしまう。
その辺のモデルもつくるでしょ？ふつう
868:nobodyさん
05/12/15 06:16:08
いや、Mojaviだとビジネスロジックの呼び出しはアクションあたりに集約するのが一般的だと思う
ビュー内でモデルは呼び出したくない
869:nobodyさん
05/12/15 06:20:08
>>868
MVCはもともとそういうものだけどな。View - -> Model
870:862
05/12/15 06:21:54
>>865
そかそか。曖昧な言い方ですまんかった。
基本的には「依存性はゼロイチ」ってのは同意だよ。
だから>>860への答えはViewからModelへの依存性は「あり」。
ただ「切り離されてるのが当たり前」って表現をしてたので、862で「それは疎結合のことであって≠依存性だよね」っていう意味で言った。
>>868
実際にはそうだよなｗ
871:nobodyさん
05/12/15 06:23:49
>>869
パッシブモデルね
872:nobodyさん
05/12/15 09:58:57
モデルをフレームワークから独立させる派は
モデルからUserにアクセスする必要がある時はどうやってるの？
873:nobodyさん
05/12/15 10:10:17
>>872
モデルはフレームワークに依存していない設計なので、
モデルから User にアクセスする必要がない。
874:nobodyさん
05/12/15 10:21:58
extends Modelすらしないってこと？
875:nobodyさん
05/12/15 10:26:14
>>873
DBはどうしてる？
876:nobodyさん
05/12/15 11:14:48
Mojavi系の場合DBみたいな下層にも入ってくるから
フレームワークに依存しない設計がいまいちイメージしにくいな
877:nobodyさん
05/12/15 11:38:55
というか、一度 Mojavi を頭から追い出して一般的な設計の話をしろよｗ
もうあんな設計は古いって…。
878:nobodyさん
05/12/15 11:43:23
話変えたいなら自分から話題を提供すればいいのに
879:nobodyさん
05/12/15 11:51:42
スルーしとけ
880:nobodyさん
05/12/15 11:55:01
Mojaviはたたき台としてまだ価値あるだろ
影響受けてるフレームワークいっぱいあるしな
881:nobodyさん
05/12/15 14:16:48
rails!rails!
882:nobodyさん
05/12/15 15:21:47
PHP on TRAXときたか
883:nobodyさん
05/12/15 21:48:05
S2Baseがいいと思うんだけど、どう？
ValidateやらFilterは自作になるけど、結構いいと思う。
884:nobodyさん
05/12/15 23:18:51
S2PandNで出席者が質問してたが､S2やMapleのDIはどこまでパフォーマンスが出るか疑問｡
プロダクトとしてリリースするなら､自分のところできちんと性能評価をやった方がいいよ｡
885:nobodyさん
05/12/16 00:48:04
もうMojaviでいいや。
886:nobodyさん
05/12/16 01:35:11
S2をそのままPHPに移植してるのかな
887:768
05/12/16 09:02:11
zend framework待とうよ！
888:nobodyさん
05/12/16 09:14:05
末広がりget, zuzaa
889:nobodyさん
05/12/16 18:13:50
Mojavi初心者なんですが
エスパー募集してもよろしいでしょか？
890:nobodyさん
05/12/16 18:41:40
>>889
ここは語るスレだ。質問はスレ違い。
891:889
05/12/16 18:51:08
>>890
そうですか、失礼しました。(´･ω･｀)
892:nobodyさん
05/12/17 00:42:49
POSTされたデータをDBへupdateする場合はmodelでするの？
893:nobodyさん
05/12/17 01:13:05
>>890
多少質問あったほうが盛り上がるからいいんで内科医？
>>892
基本的にvalidationはactionでやり、DBの扱いはmodelでやってるけど、このスレ読んでたらもしかしたらactionでやったほうがいいのかな？とも思えてきた。
894:nobodyさん
05/12/17 01:30:36
>>893
エスパー募集な質問でもか？
895:nobodyさん
05/12/17 01:39:26
あー、エスパー募集はよろしくない罠ｗ
896:nobodyさん
05/12/17 01:50:31
>>892
modelを作るほど複雑でなく(単なるログとか)、
また他のアクションで同じ機能を利用しないならアクションで済ませてしまってもいいとは思う。
897:nobodyさん
05/12/17 02:02:35
>>896
modelでDBに登録するとしたらサニタイズもmodelでやるってことになる？
でないとmodelがactionに依存してしまう気がするんだけど。
898:nobodyさん
05/12/17 09:32:09
そしたら
サニタイズはactionでやるべきだね。
899:nobodyさん
05/12/17 09:36:15
アクション前にフィルタ処理は済んでるはず
モデルは自身のためのサニタイズは自身で持つ
いずれも定義は括りだす
900:nobodyさん
05/12/17 09:39:35
インプットフィルター → アクションDeバリデーション → モデルサニタイズ
てことか。
実際どこで何をやるんだろ。
901:nobodyさん
05/12/17 10:04:30
つーかModelでDBに書き込む場合、フィルタでサニタイズするのもおかしいじゃん。
てことはActionでDBに書き込むのが正しい？
902:nobodyさん
05/12/17 10:55:36
ありえなす
903:nobodyさん
05/12/17 11:29:14
俺はmodelからdbクラスいじってやってるけど。
904:nobodyさん
05/12/17 12:05:30
mojaviの質問はどこですればいい？
905:nobodyさん
05/12/17 12:12:34
ここですればいいよ
答えが返ってくる時もあれば返ってこない時もあるけど
906:nobodyさん
05/12/17 13:19:27
>>904
あなたの質問がこのスレの命運を決めるかもしれません。
慎重に質問してください。
907:nobodyさん
05/12/17 13:24:57
何のプレッシャーだよw
908:nobodyさん
05/12/17 19:16:29
おい、agaviのサイトがエラーですよ！
URLﾘﾝｸ(www.agavi.org)
909:nobodyさん
05/12/17 20:58:41
>>908
多分5.1にしたんじゃないか
910:nobodyさん
05/12/17 21:00:06
>>908
多分PHP5.1に変えたんだろ
timezone関係の警告でてるし
911:nobodyさん
05/12/17 22:24:03
バージョン上げてからチェックしないとはアホもいいとこだなｗ
912:nobodyさん
05/12/18 03:06:20
>>911
逆だろ
チェックしてからバージョン上げないなんてアホもいいとこだなｗ
913:nobodyさん
05/12/18 03:09:01
まあフレームワークのサイトが
危機管理意識なしでエラーメッセージ垂れ流しっていうのは
あまりよろしくないよなぁ。
そもそも確認すらしないのかと。
914:nobodyさん
05/12/18 06:17:14
あれ、こんなエラー自分の環境じゃ出なかったのに
915:nobodyさん
05/12/18 09:07:58
isSecure()
return true
と
filters.iniで以下設定
[BasicSecurityFilter]
class = "BasicSecurityFilter"
param.comment = "On"
と挙動が違う。
filters.iniで設定すると、controllerの$this->loadModuleFilters($filterChain);
でBasicSecurityFilterがregistされ
BasicSecurityFilterクラスの$controller->forward(LOGIN_MODULE, LOGIN_ACTION);
でLOGIN_MODULEのフォワード無限ループになります。
URLﾘﾝｸ(ozaki.kyoichi.jp)
ここのサイトではちゃんとできているようだけど、
同じようなトラブルにあっている方はいますか？
916:nobodyさん
05/12/18 11:43:36
そのドキュメントは古いよ
BasicSecurityFilterの使用はsettings.iniのUSE_SECURITYで決定する
filters.iniに設定する必要はないよ
917:nobodyさん
05/12/18 14:07:02
o
918:nobodyさん
05/12/18 21:17:43
>>916
ちがうでしょ。
controllerでは下のように条件分岐している。
if (USE_SECURITY && $actionInstance->isSecure()) {
919:nobodyさん
05/12/18 21:42:33
>>911-912
それがPHPクオリティ
920:nobodyさん
05/12/18 22:12:04
>>918
なにが違うんだ？
USE_SECURITY && $actionInstance->isSecure()で
filterChainにSecurityFilterが登録されるわけだが。
なんでfilter.iniで再登録する必要がある？
$actionInstance->isSecure()の意味解ってないだろ
921:nobodyさん
05/12/18 22:48:36
>>920
申し訳ございません。
私が間違ってました。
922:nobodyさん
05/12/18 23:39:16
俺も間違ってた・・・。
再登録以前に、filters.iniにBasicSecurityFilterを登録したら
未認証時に遷移するはずのLoginAction自体にもBasicSecurityFilterが適用されて強制無限ループ。
正確には、forwardが20回再帰すると例外投げるから無限ループにはならないみたいだけど。
すみませんでした。
923:nobodyさん
05/12/18 23:54:26
それそれ！
BasicSecurityFilterは$this->loadModuleFilters($filterChain);
でregistすると、ループする。
（Default_LoginActionにisSecure ()適用したと同等の現象）
いちいちactionでisSecure ()をtrueに書き直すのめんどくさい。
何とかなりませんか
924:nobodyさん
05/12/19 17:48:44
mojaviでadodb+DB_Object使ってる香具師いる?
925:nobodyさん
05/12/19 18:34:07
その組み合わせってなんか変じゃね？
926:nobodyさん
05/12/19 21:25:50
headerを出力したいんだけど、viewにそのまま書いていい？
927:nobodyさん
05/12/19 21:49:37
>>925
変だからやってる香具師いるかなぁと
普通ならPEAR::DB+DB_Objectだろうけど、PEAR::DBってadodbより遅いって言うし。
928:nobodyさん
05/12/19 21:53:15
そこでPDOですよ。
929:nobodyさん
05/12/19 22:05:31
>>925
viewに書くのか。
新しい考えだけど俺はactionに書いてる。
だってviewじゃないし。
930:nobodyさん
05/12/19 22:08:30
>>927
DB_DataObjectは確かに内部でDBを使っているが、
基本的に抽象レイヤーと組み合わせて使うもんじゃないぞ
DB_DataObjectのソースに手を入れるなら別だけど
931:nobodyさん
05/12/19 22:42:40
DB_DataObjectつかうならFlexyもどうぞ。
932:nobodyさん
05/12/20 00:41:08
>>931
Alanさん早くDBDOをFixしてください
933:nobodyさん
05/12/20 02:33:17
というよりみんなは何を使ってるの?
PDO使いたいけどPHP5.1で動かないアプリがあるからムリポ
DB_DataObjectで楽するかadodbで早さを取るか迷い中
934:nobodyさん
05/12/20 12:06:31
agaviサイトまだエラー直ってないじゃん
やる気ねーーー
935:nobodyさん
05/12/20 14:49:28
Mojavi2は PHP5で動作しますか？
936:nobodyさん
05/12/20 15:07:17
>>933
そもそも PHP を使ってない(ﾟДﾟ)
937:nobodyさん
05/12/20 16:02:57
コスモを感じる
938:nobodyさん
05/12/21 09:02:46
agavi直りますた。
939:nobodyさん
05/12/21 10:14:48
Mojavi < agavi < 江角 < Maple ?
今、Mojavi勉強中なんです。 ながら気になってます。
940:nobodyさん
05/12/21 11:02:52
mojavi以外ならどれでも自分が使いやすいのを使えばいいと思う｡
941:nobodyさん
05/12/21 15:41:11
ありがとう。Mojavi以外を考えたほうがいいのか？ Mojaviを習得するか？
Mojavi覚えるの大変なんですが、何日くらいで慣れますかね？
942:nobodyさん
05/12/21 18:11:03
>>940
なぜmojavi以外?
943:nobodyさん
05/12/21 19:57:44
M3かagaviをすすめる。
オブジェクトを理解するのにちょうど良い。
944:nobodyさん
05/12/21 21:52:51
M3とは？
945:nobodyさん
05/12/21 22:03:21
mojavi3
946:nobodyさん
05/12/21 22:51:55
あれ？ひょっとしてagavi0.10.0が出た話題出てない？
947:nobodyさん
05/12/21 23:05:54
そういえば出てないねぇ。ってかagavi自体の話もあんまり無いような・・・
948:nobodyさん
05/12/22 00:27:18
おお！agavi0.10.0がほんとにでとる！
アップデートしてそのまま使えるんか
949:nobodyさん
05/12/22 12:52:20
agavi Mojavi3 Ethmi Makiko
結局Mojavi2で落ち着きました。 その後はまた考えます。
950:nobodyさん
05/12/22 18:28:57
php4つかってんの？
後々のこと考えるとphp5とm3の方がいい。
951:nobodyさん
05/12/23 02:00:04
フレームワークを使うならPHP5＋なんかだろうね。
php4使うぐらいならフレームワーク使わないでいいと思う。
どうせ将来性ないし。
952:nobodyさん
05/12/23 04:49:25
まだまだPHP4が使われつづけると思う。
今のようなPHPの使われ方なら、PHP4で問題ない。
953:nobodyさん
05/12/23 10:19:22
プロシージャ系を想定してるんだろうけど
開発者の一人がもうphp4固有のバグなんかは直さないよというような
ものは使わないほうがいいと思う
954:nobodyさん
05/12/23 10:20:08
というか非OOのフレームワークって見たこと無いや
955:nobodyさん
05/12/23 12:21:16
agavi0.10.0使ってる人、レポよろ
956:nobodyさん
05/12/23 14:01:08
ジングルベルってこういう歌だったの！？
一回目は普通のジングルベルで終わった後、もう一回ボタンをおしてリバースすると・・・
聞こえにくい場合は音を少し大きめに。
URLﾘﾝｸ(media.spikedhumor.com)
957:nobodyさん
05/12/23 14:05:43
>>956
このｽﾚにまでそんなコピペが貼られるご時世かよ
958:nobodyさん
05/12/23 15:07:39
>>957
冬休みだしね
959:nobodyさん
05/12/23 18:02:33
>>958
クリスマス寂しいな
960:nobodyさん
05/12/23 18:02:45
>>955
初ﾌﾚｰﾑﾜｰｸにAgaviを選択してみました。
英語がさっぱりなので、ドキュメントもなんとなくしか
わからないのですけど、すごく良い感じですね。
日本語情報がすごい少ない以外は今のところ不都合ないです。
ってﾚﾎﾟになってないですね・・・。
961:nobodyさん
05/12/23 20:44:59
>>956
そういうさ、途中で叫び声入るようなドッキリ系張る奴って、そんなに驚いたのか？
叫ばれてもお前に腹立つだけで、広めようとかまったく思わなかったんだが。
962:nobodyさん
05/12/23 21:33:46
ちょｗｗｗ
今PHPのサイトもエラ－になってる
URLﾘﾝｸ(www.php.net)
Fatal error: Call to a member function on a non-object in /local/Web/sites/phpweb/include/ip-to-country.inc on line 65
963:nobodyさん
05/12/24 01:48:59
直ってる…
964:nobodyさん
05/12/24 02:58:29
非SQL型のアプローチって
逆に手間増える場合も多いね。
抽象化レイヤ一枚かぶせただけみたいな形になって
しかもインターフェイスを憶えにくいからコーディングがﾉﾛﾉﾛになった。
965:nobodyさん
05/12/24 10:57:47
非SQLていうと、ldapとか、XMLで問い合わせるDBとか?
べつにそういう印象はないけど、慣れの問題じゃない?
966:nobodyさん
05/12/24 13:22:47
いや、ldapとかXMLじゃなくて、
RDMSに対して生SQLを書かずにアクセスできる
ラッパークラスのアプローチ。
たしかに慣れたら速く書けるんだろうけど
ガンガン進みたい時に「あーｳｾﾞｰ！」ってなる。
967:nobodyさん
05/12/24 14:29:17
>>966
わーい、仲間発見
可読性上がるし、エスケープ忘れ無くなるので、
がんばってるけど、SQL直書きに比べるとめんどいよね
968:nobodyさん
05/12/24 14:37:36
そういえばcakeとかのactiveredord実装は面白い。
インターフェイスがとても簡単なのもあるけど、生SQLはほとんどLEFT JOIN一本槍で
もう効率とかギリギリまで行く必要ないじゃん? みたいな思想に萌える。
findBySql()で、カスタムなsqlを飛ばしても、簡単なルールさえ守れば
スムーズにModelフレームワークに組み込むことは出来るし、
その気になれば複雑なjoin条件をモデルに指定する事もできるようだ。ドキュメント無いけど。
さて、そろそろ布団から出て宴会に行く支度するか。
969:nobodyさん
05/12/24 16:08:37
> LEFT JOIN一本槍
あれMysql5系でどーすんだろ
970:nobodyさん
05/12/24 16:22:33
>>969
mysqlのleft joinに何か問題あるの?
971:nobodyさん
05/12/24 16:43:14
問題ない
972:nobodyさん
05/12/24 17:02:10
>>969
いやINNERJOIN＋WHERE句で結合だから
973:nobodyさん
05/12/24 21:23:54
MySQL5関連はサポートレベルではみんな困ってるみたいね。
JOIN関係で修正が必要になるのはON句でこじゃれたことしてる場合だけでいいの？
974:nobodyさん
05/12/26 12:06:40
valueクラスつくって（下記）ユーザの情報を入れるんだけど、
DBからユーザ情報をたくさん取得してこのオブジェクトにセットした場合
オーバーヘッドがすごいですよね。
複数のユーザ情報をvalueクラスにセットする場合ってどうやってますか？
class userValue {
private $userId;
private $name;
private $mail;
function getUserId() {
return $this->userId;
}
}