【PHP】フレームワークについて語るスレ【総合】

【PHP】フレームワークについて語るスレ【総合】 at PHP

[前50を表示]
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＝ドメインロジックで問題なくね？

次ページ