【PHP】Phrameを使う【フレームワーク】

PHP用フレームワーク「Phrame」について語るスレ

※関連リンク

Phrame本家
http://phrame.sourceforge.net/

PHPでMVC第1回：前編
https://www.stackasterisk.jp/tech/php/phpMvc01_01.jsp

開発談義/FrameWorkはどれがいい？ - PukiWiki
http://w-project.org/pukiwiki/index.php?%B3%AB%C8%AF%C3%CC%B5%C1%2FFrameWork%A4%CF%A4%C9%A4%EC%A4%AC%A4%A4%A4%A4%A1%A9

Phrameとは何ですか？説明してください。

こことかいいね。
http://www.lyricfathom.com/pukiwiki/pukiwiki.php?plugin=attach&openfile=hello2.zip&refer=Phrame%B2%FE%C2%A4

こっちだったスマソ。
http://www.lyricfathom.com/pukiwiki/pukiwiki.php?Phrame%B2%FE%C2%A4

あとこれも。
Phrameを使ってみよう
http://www.lyricfathom.com/pukiwiki/pukiwiki.php?Phrame%A4%F2%BB%C8%A4%C3%A4%C6%A4%DF%A4%E8%A4%A6

>>2
楽して割と凝ったサイトを作れる雛形みたいなもんかな

Mojavi も語れるとよかったかな。

>>6
mojaviはExamplesやマニュアルが少ないので取っ掛かりにくいですね

>>7
なのでなおさら。

フレームワークってなんですか？

ググるなりしてから、出直そうな。

mojaviも入れておくれ

Mojavi 入れるとスレが乗っ取られるだろ。

もうすぐ出るムックにmojaviが載るんだろ？
そういう雑誌の影響は大きいから
日本ではmojavi一色になりそうだな。

もうPhrameはステ
これからはMojaviでしょ

Phrame スレで言うな

フレームワークはテンプレートだよ

>>16

処理の逆転が起きるのがフレームワークだから、それは違うと思うよ…。

>>17
えっ、テンプレートじゃないの??? テンプレートでしょ

おいおい、こんな糞スレみたことないぞ。
1st release から何年も更新されずにとっくに終わってるフレームワークじゃないか。

しかも >>5 と >>16 はアフォ

せっかく PHP フレームワークスレが出来たと思ったら、始める前から終わってる orz

>>19
とっくに終わっていようが便利なものは便利だからしょうがない。
なぜアフォなのかを説明もできない藻舞は（ｒｙ

>>19
ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

盛り上げてくれ。
期待はしてるyo!

そもそもスクリプト言語のフレームワークなんて重いだけだから流行らないんだよな。
PHP4まではOOがウンコだったし。

>>23
はっ？重いか？　って君はもしかしてネ申しゃま

>>23
（　´,_ゝ`）

Phrameでの開発手順

１．/viewのテンプレートHTMLを作成（WEBのデザイン）
２．/viewにPageクラスを拡張したHogePageクラスなどを作成
３．/modelsに処理系のクラスを追加
４．/actionにHogeAction.phpなどを作成
５．/formsにHogeForm.phpを作成（主にvalidate処理）
６．/include/mappings.phpを加工
７．/include/include.phpに1〜５までで新規に作成したファイルのパスを追加

>>26
(*´Д｀)ﾊｧﾊｧ

その流れ見てると Mojavi が Phrame パクってるってのがよく分かる。
DispatcherView パターンに該当する部分が include.php だったり、
binarycloud から受け継いだらしい (適当) ExecutionFilter/ActionChain が無いのが何なのかな。

（゜д゜（　：：：　ｌ　：：：　）　＝３　ブッ

>>27
ﾊｧ? （゜д゜ 知ったかMojavi厨は氏ね

パクッテルのだったら改良されているって事だから
Mojavi>>>Phrameってことだね。

改善とは限らないけどね。改悪かも。
どっちも知らんけど。

おい、ほまいら！
mojaviとphrameを比較するH頁作ってください！ホナガイスマス

PHPはJavaみたいに汎用言語じゃないんだからさ、
こういうフレームワークを仕様として取り込んでほしいよ。

>>33
いいこといった

>>33はphp-gtkの敵だ

>>33 は PHP+Parrot の敵だ

>>19 >>35 >>36 アフォだ

>>36 は ちょと違う。

未来少年って事か？

PHPは駄目だねJavaの真似ばっかしようとしてウンコ状態になってる。
オブジェクト指向を重視する部分は
ObjectivePHPみたいな派生言語にした方がいいのでは？

>>40
そうかなー
使いやすくなったけど。
ソースの使いまわしも楽になったし。

どなたかinclude/mappings.phpの説明について日本語で詳しく書かれてるサイトしりませんか

このまま dat 落ちでつか (´･ω･`)

mappings.php　って正直わかりずらい

Mojavi 厨で申し訳ないんだが、Phrame の方が優れてる/参考に出来る部分ってあります？
吸収できる物があるなら触ってみたいけど…

漏れはPhrameしか知らんからなんともいえん。。。＿|￣|○

>>45
ないです。一般的に、Mojavi が主流です。
Mojavi スレ　そろそろたてて。

>>46
ありがとう ＿|￣|◯
自分で… といっても Phrame の前に調べたいフレームワークも多いしな…

そのフレームワーク名ｷﾎﾞﾝﾇ

工エｴェｪ（´д｀）ｪェｴエ工工

まぁ色々ありますよ。
Phrameより後発だったり、それなりに開発動向がアクティブだったり、そういう部分が興味そそる。

でも今はMojaviでお腹一杯でつ。

だからその色々なフレームワーク名をｷﾎﾞﾝﾇと言っている。

うー

WACT, Seagull, HORDE, Popoon, binarycloud, Ambivalence, Ampoliros, PHITE,

BlueShoes はダメだった。

Mojaviサイトのトップに載っているやつで非XML系のヤツ

+ Ambivalence (http://amb.sourceforge.net/)
0.9がJuly 16, 2002に出て以来開発が止まっている様子。評価下げ。

+ binarycloud (http://www.binarycloud.com/)
本格派MVCフレームワーク。
JavaのAntみたいなphingをサブプロジェクトで開発している。
Pharme, Mojaviと異なるのは認証、フォーム処理等の各種ライブラリを備えて
いることか。その分巨大なフレームワークになっているので、とっつきが悪い
感じ。テンプレートはSmartyとXSLTのアダプタがあるみたい。

+ Horde (http://www.horde.org/horde/)
Webアプリケーションフレームワークとしては最も巨大だと思う。
ライブラリの量が凄い。いくつかのライブラリはPEARにも寄贈されている。
現時点で最も人気がありそう。中身は知らない。

Web等で概要を追ってるだけでは似たようなものが多すぎて使ってみないとわ
からない部分が多い。しかしCMS系を入れると数ありすぎてなかなか評価する
のも大変です。

ポータル系ではeZ publishとMidgardが興味深いかなぁ。

>>53
ありがとうです。詳し杉…

Midgard 忘れてた orz
Horde は IMP を使いたいのでついでに手を染める予定。

>>54
Hordeを使ったアプリケーションいいもの多いよね。
誰かHello, Worldまでのチュートリアル書いて下さい。

VIEW系の処理をXMLに頼ってるフレームワークは使う気がしないのは漏れだけ？
XMLの方がデータの移植性はいいのかもしれないが。

Mojavi本っていつでるの？

>>56
おまえさんだけではない。俺も嫌い。

>>57
http://ns1.php.gr.jp/pipermail/php-users/2004-August/023573.html

皆様おひさしぶりです
一通りレスを見てみましたがmojaviユーザって結構いるんですね
マニュアルがあまり整ってないので使ってるヒトいるのか疑問でしたが。
この際mojaviの話もOKにしましょうか
その方がPhrameユーザにとっても有益な情報が得られるかもしれませんよね

いやです

どんな Phrame スレだよ (；´Д｀) どうせなら Phame じゃなくて Framework スレに変えて立て直しきぼん…

PHPフレームワーク全般スレまだぁ？

ねぇ、まだぁ？

必要なら自分で立てろよ

立てろよ

立てて

立てろよ （・∀・）

<?php
class 2chAction extends Action
{
function perform($actionMapping, $actionForm) {
$厨房 = $actionForm->get('MOJAVI')
//get ActionForward depending on if errors were generated
if ((!$厨房) || ($_SESSION[_ERRORS])) {
$actionForward = $actionMapping->get('PHRAME');
} else {
$actionForward = $actionMapping->get('イッテヨシ');
//put Person in the session
$_SESSION['厨房'] = $厨房;
}
return $actionForward;
}
}
?>

ﾎﾞｯｷｱｹﾞ

$Human->SetAnal( 'ｳﾎｯ' );
-----------------------
出力結果：いい男…

みんな自分オリジナルなフレームワークもってるよね？
似たり寄ったりになると思うけど

自分オリジナルに5000点

>>72
持っていない。フレームワークを自作するコストと利用するコストを比較する
となかなか自作はできないだろう。ましてや良質なフレームワークが出回って
いる現状ならなおさら。どちらにしてもスクラッチから書くのは習作を除けば、
現実的ではないと考えている。

>>72
持ってたけど早く捨てたかった。
一つはそんなに自分を高く見積もってないし楽したいので皆で作る方が良いと思ってた事。
もう一つはオープンになる事で外から入ってくる人間には習得の容易さを、外に出て行く人間には出て行った先でも使える物を持たせたかったから。

で、きっちり捨てれて今は幸せでつ。
まぁどうしても独自コードっぽくなるけど、それでもオープンなフレームワークや PEAR を編み込む事で出来るだけ閉鎖性は排除してる。

で、何かなし崩し的に総合スレになってきてるような。
価値高い方に転がるなら自分的には(ﾟдﾟ)ｳﾏ-ですけど。

そりゃあんたしだいさ

誰かケータイｻｲﾄのフレームワークもってないですか？
自分オリジナルなframeworkでいいんで。。。

自分オリジナル俺も保水　

>>76
禿同

PHP5フレームワークのOSCOMですよ

OSCOM ? なんか某カンファレンスっぽい響きだが。
http://www.oscom.org/events/oscom4/proposals/vida

これにある Vida の事？
https://sourceforge.net/projects/vida

http://phphp.net/man/mojavi/

phpdoc､ｵ､鬢ｵ､?､ﾆ､筍ｦ｡ｦ｡ｦ

bakeru...

･ﾆ･ｹ･ﾄ

>>85
･ﾆ･ｹ･ﾄ ？2ゲト？とっくに>>2は過ぎたぞ。

mojaviの使い方がわからん。おしえてよ。

config.phpを設定。
設定終わったらindex.phpのdieの部分を消す。
あとはモジュール内にclass呼び出したりして好きに書け。

mojaviビギナーのチュートリアルだ。
http://www.peterrobins.co.uk/it/mojavi/tutorial.htm

>>88
ありがとう。さーてconfig.phpを見てみるか。

mojaviってドキュメントないから
ソースを解読しなきゃなんないよね。
だったら自分でつくっちまったほうが
はえーじゃないかっておもうんだけど。

好きにしたらいい。

いや、実際使ってる人の意見を聞いてみたくて。
一般人では作れないようなスマートな実装をしているのかな。

モジャ公の日本語まぬあるﾏﾀﾞｰ？

もじゃの使い方を親切に教えてよ！

モハービってインディアンの部族名だっけ

オサマビンラディン　と　モジャビン　と　ガチャピン　
mojaviスレをそろそろ立ててください

>>90
自分で作ったほうがはやいにきまってるじゃん。
でも、複数人で開発するとき、しかも互いにコーティング方法が
違う人間達とやるときでも、自分たちでルール決めて作るほうが
速いといいきれるか？

そしてドキュメントはあるだろ。>>88にビギナーのチュートリアルだって
あるし

おまいら凄いな。
俺は独力＆浅いんで、あと１年やってても Mojavi の実装や考え方に至れたかどうか甚だ疑問だ。
便利に使わせても貰っているが、何より良い教材だよ、Mojavi は。

まぁそんなスキルの低いヤシにも Mojavi は優しいんでつよ (´･ω･`)

>>98
彼はライブラリと勘違いしてると思われ

･ﾕ･?｡ｼ･爭?｡ｼ･ｯ､ﾈ､ｷ､ﾆ､ﾏStruts､ﾊ､ｫ､隍熙ｺ､ﾃ､ﾈﾍ･､?､ﾆ､?､ｷ､ﾊ

チュートリアルって英語じゃねえか。使えね。
誰か俺様のために和訳して公開シル

釣りにマジレス ('A`

英語勉強するか、大人しく日本語圏に入ったものだけ使っておけ。
ドキュメント読める程度の英語ってもう必須だよな・・ でないとベースにアクセス出来ないんだし。

>>101
俺も、チュートリアル読んだけど、なんか微妙。　
誰か翻訳してほしい。　

>>102
君はかしこい。

それより日本語なら、あと２週間もせず待望のムックが発売ですよ はぁはぁ

ムックのもじゃびは、
ちょろっとだけだよ.

>>104
ガチャピンはあと何週間で発売ですか？

そろそろ>>101は人の役にたつべき時ですよ。
そのままじゃ一生本７ですよ

てか、高卒程度の英語勉強してきたならまず読めると思うんだが…。

>>108
高校にもいろいろあるから

普通の高校で英語は苦手、センターでも全科目中最低点。
そんな俺でも必要性に迫られてやってるウチに覚えていった。
今じゃ英語のニュース聞いて部分部分くらいは理解出来る程度になりますた。

まぁ必要なスキルと思えば何とかなる。
高校の頃覚えた基本構文は役だった。

>>110
お前の話はどうでもいいが、>>103とかはちゃんと学校行った方がいいと思う

>>108
正直英検1級の俺でも厳しいですがｗ

>>112
英検1級とるほどがんばったのに、なぜ英語を続けなかったのか。もったいない

>>112
脳内英検で厳しいのは当たり前じゃん

むしろ英語のままの方が良いこともある。
プログラム関連の書籍って訳が下手なの多すぎ。

>>112
なんの為に英検とったんですか？あなたほど愚かな人はなかなか探してもいませんよ

お前ら英語スレ立てて移動してくれ。

つーか、連休で暇な香具師も多いだろうし、>>101がまとめてみたらどうだ？
wiki形式で手軽に対訳を書けるようにしておけば捗るんじゃないかな？

Sourdoughはどうよ？PHP5のフレームワークみたいだけど

5自体まだ触ってないや

ちなみにPerlも5.00503止まり。

>>112
技術しらない英検1級より、技術しってる英検なしの方が、技術文書は読める。

>>122
釣りだと気づけ。

と魚がまた一匹。

>>123
日本語検定１級なのですが、気づきませんでした。

>>125
お前はNHKの小林克也の日本語講座でも見てろ

KONISHIKIのにほんごであそぼあたりから始めたほうがいいんじゃないか。

>>127
ある父親より

ちんぽまつりはおわらない

ちんぽであそぼ

あそんでいたら、なんかしるがでてきたよ。

PHPフレームワークが欲しい

【PHP】ガチャピン【フレームワーク】

バージョンアップで挙動が変わるPHPと、バージョンアップで挙動が変わるフレームワークと、バージョンアップで挙動が変わる周辺ライブラリのおかげでえらいことに。

>>134
って事は、枯れたライブラリを使うのが吉って事か？

PHPまわりの技術は枯れずに朽ちるからなぁ・・・
PHPLIBといい。

フレームワークとライブラリに関しては、他に納品したりもうメンテに落とし込む場合は
そのアプリケーション専用のライブラリとして他から切り離してバージョンも固定してるけど。

でないとやってられないべ。

バグ修正のときに仕様がかわるからねぇ。
やってられないべ。

Mojaviムック読んだ人感想希望

せっかくサンプルモジュールが見つかっても、ちょっとバージョンが違うだけで動かなかったりするもんな

（´,_ゝ｀）ﾌﾟｯ

>>137,138 とにかく同意。

PHP用MVCフレームワーク Mojavi第1回：フレームワークとMojavi
https://www.stackasterisk.jp/tech/php/mojavi01_01.jsp

>>143
何かネットで拾った話をつなぎ合わせただけみたいな。

スタックアスタリスクもあのまま京橋にいておけばもっと違う内容になったかな、とちょっと (´･ω･`) ｵﾓﾀ

mojavi3.0ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

DEV だね。正式リリースかとおもた。
もう実地投入してる人もいるようだけど。

そういや前にフォーラムに 3.0 が subversion から取得出来るような書き込みがあって見てみたけど無かな…
アレは何だったのか。

ていうかmojaviで完成されたアプリケーションつくったやつってどれだけ居るの？

>>147
会社でひとつ作りました。Webアプリケーション部分のコード行は4万くらい。
しかしその質問の仕方じゃ、基準がわからないので調べようがないよ。

>>148
どんなもの作ったの？

>>149
・顧客情報管理
・売上管理
・ワークフロー
・スケジューリング
等を備えた業務アプリケーションです。

詳しい内容はご容赦下さい。

俺だよ、俺、俺。


中堅小売業向けの顧客管理＆サービスアプリケーション作ったよ。
動いてるけど運営ダサすぎて 500 hit/day も出てないので晒すのは勘弁。

>>150
コード行は4万？
なんでそんなもん、わざわざ作ったの？

>>152
レガシーシステムのリプレースです。
そんなもんって、あの内容だけでよくわかるね(笑)
商用のERP/CRMパッケージを使えと？
規模的にERPの出番はなかったですよ。

でも、それならJavaでやったほうが楽だった気が・・・

>>151
そんなもん。むしろそこまであるだけマシ。

>>154
うん、その通りだと思う。
でも、自分がチャレンジできる立場だったのでやってみたんだよ。

JavaだとStrutsになると思うが、あのXMLをいちいちごちゃごちゃ弄くらなきゃいけない手間と
動作確認もさっとできないところがダメ。

>>150
＞会社でひとつ作りました。Webアプリケーション部分のコード行は4万くらい。

しかしそうとう無駄な行がありそうだな

>>157
はい、実際に重複部分はあります。メンテナンス機会があればリファクタリングしますが。

>>158
開発人数は？

雑誌「まるごとPHP」を買いましたが、
Mojaviについては数ページしか書かれていませんでした。
まったくMojaviの使い方がわからなかった自分には、それでもありがたかったですが。

>>156
定義ファイルはXDoclet使えばもうまんたい。
さっとできないというのがどういうことかわからんが、動作確認というか、テストはStrutsTestCaseでもうまんたい。

>>148
HTML含めて4万行だったら笑える。

mojaviは慣れると意外と使いやすい。

mojavi3.0はやく正式リリースしてくれ

mojavi3動かしてみたけど、同梱されてるモジュールは単にページ表示するだけだね

>>160
ぐぐれば情報発信してるありがたいサイトが生まれてますよ。

>>165
日本語のサイトはほぼ閲覧しましたが、詳しく解説しているサイトは少ない感じがしましたが。
お薦めのサイトはありますか？

ヌルい人大杉。
日本情報も充実して手がかりには十分だろう。

何だって最初は詳しい解説なんて無かった。
PEAR も、Mojavi も。
いつもソースがドキュメントだった。

人のアウトプットを待つって事はそれだけ遅れるって事だ。
人のアウトプットに頼り源泉に触れないって事はそこでフィルタされた情報があるって事だ。

やる気あるヤツぁ自分でよじ登れ。
労惜しむのなら落ちてくるまで待っとけ。

PEARは最後まで詳しい解説がなかったね。

>>167
まぁまぁ、そういわずに。皆が皆そうできるわけでもないよ。
いろいろな意見が出る方が参考になるし健全でいいと思う。

>>169
かなりネタ気味に書いたんで。

そろそろMojaviも次のステージかな。
誰か本出せばいいのに。
モジュールコレクションと、モジュールを組み立ててアプリケーションを作るパートとの２部構成くらいできぼん。

ぬるいフレームワークなんぞ使わずに、
自分で作れ。
そして再利用だ。

mojaviのドキュメント、英語でいいからないですかね。

つーか、mojaviスレ建てようぜいい加減。

>>173
じゃ、頼む。

あたしゃムックのmojavi記事では
さっぱり使い方が分からなかった。
Smartyの話と混ぜずに、もっと
シンプルに解説して欲しい。

アレ以上落としたら内容を削るしか無かったと思うのだけど。
良い記事だったと思うけどな。
>>175 の願望を落としたら俯瞰的なイントロダクションではなく、入門用の記事が必要となるのでは。

というかおまいら、誰かの書いた物に頼りすぎですよ。

switch (自分のポジション)
{
case '本職':
ムックを持てる分、先行者よりも良いコンディションでスタートしたのに理解出来ない自分に焦りを感じて根性で頑張る
break;

case 'webデザイナー':
case '趣味':
default:
もっと分かりやすい記事が出るまでムックの他のパートを読んだりしながらのほほ〜んと待つ
手元に Mojavi ネタをコレクションしては適当に取り組み、分かる部分だけ取り込んで少しづつ前身
break;
}

>>176
実際のところ、RendererはほとんどSmartyを使うことになると思うので、実利
を考慮して意図的に誘導しました。大多数の方は記事のままお使いになる場合
が多いので。気に入らなかった方はごめんなさい。

もし次回があれば、アプリケーション構築プロセスを追うチュートリアル的内
容になると思います。

いまのところ、ここの解説が一番詳しいかな？
http://mojavi.try-angle.biz/wiki/

おお、意欲あるな。
確か業務で使うのに勉強会か調査かやるって言ってた人の所か。

>>178-179
引用の範疇を越えているため、もちろん原著作者に許可を得ていると思うので
その旨、どこかに明記しておかないと、法人として信用をなくすような
あらぬ疑いを受けるかもしれないよね。
私は英語ができないから大変有用なんだけど
願わくば、翻訳の掲載（と今後増えるであろう既存情報の寄せ集め）のサイトからの
脱却を計ってもらえると意欲があると思えるよね。

どうでもいいけど、ソースコードのグラデーションがウザい。

ほんとにどうでもいいな

結局、このスレでPhrame使ってる人はどれくらいいるの？

>>183
俺は使ってるよ
といっても自分仕様に相当改造したけど

>>184
なんのためのフレームワークだよｗ

>>178
http://www.stackasterisk.jp/tech/php/mojavi01_01.jsp
http://mojavi.try-angle.biz/bbs/
こういうのもあるらしいよ。

改造したらフレームワークの意味がなくなるのだろうか

>>186
さんくゆー

もうムックいらなくなったよ。ガチャピンもめん。

ムックは今海の向こうでは旬だけど
日本語にはなっていないトピックが
たくさんちりばめられていて興味深いな。

>>187
いんじゃない？お前の趣味程度でしょ？

仕事でしょ。
３にんがかりくらいの大規模な。

大規模ってどれくらいなのかと常々思っていたけど、３人で大規模なのか。
漏れも Mojavi を微妙に拡張してるよ。Mojavi にはわざと詰めてないように思える部分があるし。
ただその前にそのフレームワークに従ったやり方を調べ、他のフレームワークに手を入れない方法を調べた上での事だけど。

PEAR のように細かくバージョンの上がるライブラリを改造するのは躊躇うが、
Mojavi のように安定している物であれば少し手を入れるのも有りかと思う。

フレームワークにバージョン毎の互換性ってあるの？
互換性が無い（乏しい）のなら、バージョン固定して
カスタマイズする方が賢いような気がするけど。

「フレームワークに」っていうくくりはどうかと思うが。
つか、バージョン毎の互換性にとぼしいフレームワークとか処理系って、怖くて使えない。

Mojavi は無い。>>193 の言い分が簡潔でステキ。

>>194
PEAR 相手なら言ってることは正しいが。>>193 のような場合はバージョンが違えば別物って考えるんだyo!
ドラクエみたいなもんだ。１と２では、１やってりゃ２の理解も早いが基本的に別物。

>>193
メジャーバージョンが上がる場合は互換性がある程度失われるのも許容範囲だと思うけど。
マイナーバージョンが上がって動かなくなるのは困るよね。
PHP本体でたまにあるけどね。

>>195
つまり、どうせバージョンがあがって使い方変わるんだから、必要もないのにあらかじめmojaviの勉強をしておく必要はない、ってことですね？

釣りにマジレス。

フレームワークでも言語でも何でも、優秀な物は実際に投入せずとも考え方をパクったり良い影響を受ける事が出来るので取り敢えず触れておくのは大事。
っていうか PHP 自体が、実運用には 早い、安い、旨い で適しているけど何か新しい物を生む土壌ではなくて多くの輸入物で成り立っていると思うんだけど。
なので PHP コーダーだからこそ新しい物への興味を高く保つべきと思う。
PHP/PEAR は特に Java に対しての後出しじゃんけんが多くて (ﾟдﾟ)ｳﾏ- な気がする。

mojavi officialで
使われてるwiki engineって
何でしょう。

mojaviをつかって
nucleus+XOOPS的な
blog作りたいな。

テンプレート/スキン
の実装に悩むね。

>>199
coWiki か wakka じゃなかったか？
超適当。ところてん脳ですまんなぁ…

>>198
旨いか？
Javaに対しての後出しじゃんけんっていっても、Javaがグー出してるの見てPHPがパー出したときには、すでにJavaがチョキ出したあとだし。

>>203
まぁソレはある。言い方悪かったかも。
Java より PHP でやる理由ってのはまた別で、もっと総合的な事が理由。
宗教論争に入りそうなのでパス。

http://www.geocities.com/pvstempvoort/phrame/

>>205
こういう試みもあるんだね。初めて知ったよ、ありがとう。

検索してて偶然みっけたけど、
まだサンプルが動作してない。

まだ、いまいちよくわかってないっす。
このフレームワークってやつ。

これからはmojaviかmapleになるだろうな。

関西オープンソース出たいな。ちきしょう。
誰かレポお願い。

その割に、mojaviのスレって
いつまで経っても立たないね。

ココ使い切ってからね

次スレは PHP フレームワーク総合でおながい。

とはいえMojaviしかみんな使わないんだから同じかと。

>>213
やっぱり、Mojavi が一番良いってこと？
Maple はどう？

Mojavi は鉄板だが、ケースバイケースで Mojavi 以外の選択肢も出てくる。
それに常に新しいフレームワークは評価していきたい。

っつーかさ、俺に Mojavi 教えてくれた人はもう「みんなやってるから興味無くした」って言って別のヤツやってる。

> 俺に Mojavi 教えてくれた人

いいね、そういう人がいて。

>>216
お前には俺がいるじゃないか。

>>216
念のために言っておくと、「使えるよ、いいよ」ってだけで誰も手取り足取りなんてやってない。
そっちのラインもお互いに得る物があっての事がまだ大きいと思うので、貰った分自分も何かを返さないとってプレッシャーの中で毎日やってるよ。

書き込んだ後に217の216への愛に打たれて殺伐とした自分に気付いた ・ﾟ･(ﾉД｀)･ﾟ･ 俺が悪かったよ

>>217
うほっ

>>215
＞っつーかさ、俺に Mojavi 教えてくれた人はもう「みんなやってるから興味無くした」って言って別のヤツやってる。

普通フレームワークってみんなが使ってこそ価値があるもんだと思うんだが…

mojaviってxsltと組む時はどうするの？
あと、ファイルの置き場所と名前がまるわかりなのにはどう対応してる？

所詮PHPなんだから、気にするな。

>>222
は？普通に変更効きますが？

所詮PHPなんだから、気にするな。

PHPは開発環境がへぼいからつらいな

うむ。へぼいからつらい。

ミカン箱環境(*´Д｀)ﾊｧﾊｧ

Mojavi の質問いいですか。

まるごと PHP の P199 リスト15 で

$request->setError('login', array( 'level' => 'warning', 'message' => 'ログインに失敗しました' ));
return VIEW_INPUT;

とあって、自分は setError は void setError (string $name, string $message) で使っていたので
配列でエラーレベルとメッセージをセットするアイデアに興味を覚えたのですが、
ではそのセットした情報を取り出す/使うときはどうやっているのかと思って探してみると…

まるごと付属 CD に該当コード無いし （つД｀） 記事をぱらぱらと見ても解説が無いんで… 誰か解決編お願いします…

誤認/見落としがあったらごめんなさい。

Mojaviは、ソースコードを解読していかないと使い物にならないという噂ですが

>230

そうかもしれない。
しかし量が少ないのですぐ読める。

ということは、機能が充実してソースが気軽に解読できる量じゃなくなったときには、使い物にならんってことだな。

>>229
まるごとPHP!の記事を書いた者です。
setError()メソッドで配列をセットする使い方は、Mojavi自体とはまったく関
係ありませんのでハンドリングは自前でやることになります。
エラーメッセージのレベルによってCSSのクラスを変更するという(アイコンや
メッセージのフォントサイズ、色等)ことを実現したいがために使っておりま
すが、混乱させて申し訳ありません。

レンダラオブジェクトでテンプレート変数として設定しておいて単純にSmarty
等の条件分岐で参照させるような使い方を意図しております。

例えばこんな感じです。

{section name=freeMessage loop=$freeMessages}
<tr>
<td
{if $freeMessages[freeMessage].level == "info"}
class="info"
{elseif $freeMessages[freeMessage].level == "warning"}
class="warning"
{elseif $freeMessages[freeMessage].level == "alert"}
class="alert"
{/if}
>
{$freeMessages[freeMessage].message}
</td>
</tr>
{/section}

>>233
納得しました。

実際に用いられている工夫を教えていただけるのは有り難いです。
多謝。

微妙に3.0が更新されてるな。
正式リリースはまだか…

mojavi2.0を展開すると拡張子newのファイルがあるのですが
これはなんですか？

>>236
どのファイルですか？

..new
lib.new
filter.new
logging.new
opt.new
auth.new
filters.new
等です。全部で23個もありました。
ちなみにnewファイルが存在したのはUnix Gzipのファイルです。
Windows Zipのファイルにはnewファイルがありませんでした。

3.0.0デブ更新上げ。

>>238
遅くなりましたが、調べてみました。
どうやら以前置かれたファイルと異なるようですね。

48513 Sep 2 00:34 mojavi-2.0.0.tar.gz
45779 Nov 30 17:38 mojavi-2.0.0.tar.gz.old

違いはそれらの空ディレクトリだけでした。
削除して構わないです。

>>240
質問に答えてくださって、ありがとうございました。
これで、安心して使用できます。

最近ここも大人しいね。
Ethna使ってみた？

Wikiに書いてある通りに確かに、同じコードを必要以上に記述しなくて良い雰囲気が実感出来た。その辺Mojavi2より優秀かも。
Mojavi3を見ない事には何とも言えないけど、選択的に使えるんじゃないかなと思った。
Mojaviクローンにあまり興味ないので更新状況以外は追いかける気は無いけど…

そろそろ誰か、PHPフレームワークの総合スレお願い。

Ethena、ちゃんと日本語でドキュメントが用意されている（つつある）だけ、
自分的には好感度はかなりいい。

「まるごと〜」には、あのくらいのチュートリアルを期待してたのだが……

Ethenaはちょっと試してみようと思う。情報ありがﾄﾝ > 242

ココ見るとけっこうあるね。

その他のフレームワーク
ttp://ethna.jp/ethna-related.html

Mojavi、Maple、Ethenaの比較をどなたか。

Maple少し触ったけど、サンプルのSmatyのテンプレートがSJIS・・・

スクリプトもSJISが交じってたり。SJISで開発してるの？

SJISのような過酷な環境でも動くってことだな！

文字化けして表示されるのを「動く」と評価するならね。

海外行くとMojaviクローンが鰯並に転がってる。
色々忙しくなってきたな。でもMojaviのやった後ばかり追いかけても楽しくないが。

Zendのコンペでもストラット系フレームワークで溢れてたね

1

>>245
SJISで開発してます。須磨と喪覇美で。

静かだな (´･ω･`)
ある程度行き渡って初期情報交換の役割が終わったのと、PHP4 -> PHP5 移行期で色々地下進行してるのかとか予想してみたり。


まぁ保守。

もうこれ以上使う人は増えないってことだな。

ていうより 3.0.0の正式リリース待ち。
今更2.0.0なんて使おうなんて間抜けなことはしない。

いや、使うのは使うじゃん？
今更リソース突っ込んで研究しないよ って事か。

早い人はもう 3.0 調べまくってるようだけど。

phrame-2.1RC1が出てるけど、
2.0系とどこが変わったのかよくわかんない。

そういえばここってphrameスレだったな。すっかり忘れていた。

これなんてどうすか？
http://www.guesswork.jp/

なんとなく簡単そうなのと、サイトのつくりがいい感じ。

Mojaviって読み方は「モジャビ」でいいの？

>>259
もはび・もはーび・もうはーび←この発音が一番近い
いずれにせよ「じゃ」じゃない。
ところで、フレームワークって解説なし、ソース嫁ってのが普通なの?
自分が使うために作り始めるんだろうから、そうならざるを得ないのかな。
作る人はいろいろこだわって思い入れを持って作るんだろうけど
正直、ユーザはフレームワークを使ってMVCを楽に分けたいと思って使うんで
ソースから読まなきゃ行けない手間がかかるんなら本末転倒じゃないか。
その辺のところどうなんよ。
Mapleに注目してるんだけど、
「○○という機能は、フィルタを作成すれば使えます。」
ってその作り方はソースみてねじゃ。使えねーって思うんだけどな。
結論、チュートリアル早く続きを書いてね。
せめて文字コード機能の修正版だけでも早くだしてね。
開発者のページに書き込むとひんしゅくかいそうなので、ここで遠慮がちに希望します。
文句つけながらも実は一番期待しています。

Visual C++にScribbleっていうチュートリアルがあって、少しずつ機能を
追加しながら、実用性のあるMFCやWindowsプログラミングを段階的に説明
していくのがあるけど、PHPのフレームワークでもそういう解説が欲しい。
いつまでもHello worldやって説明終わりで済んでいる段階じゃないでしょ。

文字コードはheaderを送ればいいんじゃないの？

チュートリアルも「Filterは既存のFilterのソース見て作ってね」ってなると思うけど。
でも細かなバグつぶしてこまめにリリースして欲しいと俺も遠慮がちに希望。

>>260
寧ろ PHP で普通。Mojavi なんて恵まれてると思うが。
サンプルアプリケーションあるし、Mojavi 使った成果物も転がってるし、ドキュメント拾い読みして解析していけば大体掴める。
あとは PhpDocumentor にかけて洗い出す。
どうせ何か書いてくれるならこの先が知りたい。Mojavi は使ってる人によってそれぞれ独自のノウハウが溜まっている事があって面白い。

導入コスト下げてくれ、ってのはまた別ベクトル。
ある会社は PHP でご飯三杯はいけるフェチな人を起用して Mojavi を軸にパッケージと導入プラン作らせてるし、
別のチームはそれぞれ分散して別々のフレームワークを調査し、持ち寄って比較検討して溜まったノウハウで導入に持ち込んだりしてる。
*やる所はやってる。*
ドキュメンテーションは非常に大事だと思うけど、Maple は知らんが、Ethna や Mojavi は開発リソースが足りているとは思えないので現状は仕方ない。
寧ろ足りないと思えば周辺で作れる部分は周辺でやっていくべきじゃないかと。

もしくはクレクレコールは出版社の方に放って、T.K, K.T, T,J, A.K 氏辺りのエラい人達をもっと酷使して記事書いてもらう。
Java兼業ライター専門は不要。PHP に頭から浸かってるヤツにノウハウも情報も吐き出して頂く。
PEAR なんて本家マニュアルの充実と平行してそうやって W+D に色々記事が載る事で大分楽させて貰った。

同じような不満を持っている方がいたのね。この意見伝わらないかな…。
>>262
Headerの送り方がわからんのよ。多分回答はHeaderを送れるよう
フィルターを改造してとかで、そのフィルタはソース見てね。の堂々めぐり。
つーかそれ以前でPHPの自動変換機能をonにするとダメな仕様なのよ。
>>263
PHPで普通と言われると確かにPEARとかそうなんだけど。
だからと言って良いと思えない。PEAR不便でしょ。未知の機能が多すぎて。
PEARのような呼び出されるプログラムは呼ばなきゃいいだけだけど
フレームワークって呼び出す側のプログラムだからある程度理解してないと
怖くて使えない（ようじゃ困るとホントはいいたいんだけどね）。
ドキュメントじゃなくても、よくある機能の（コメント付き）サンプルアプリ配布して欲しい。
全体の関係の説明がないからフィルタ単体のサンプルを見ても作れない。
（作れる人は作れるンだろうけど）。
function init() //初期化(実際はJavaDoc形式だけど)
とだけ書かれてその関数の改造はできんぞ。まぁソース嫁ということなんだろうけど。
面倒でもその中で何をしているかコメントして欲しいんだよな。
そうすると周辺での開発がもっと活発にできるようになるんじゃないかと。
Mapleの周りの人は極端な話、製作者としてもいけるくらいの理解度が
あると思う。それくらいでないとMapleは今のところ使えないのが残念です。

俺さ、これからPHPのフレームワークを解析して、
Perlに移植してみたいんだけど、
PerlでこういうStruts系で、シンプルなフレームワークって既出？

>>265
Sledgeが有名だね。
Struts系かどうか知らんけど一応MVCモデルとのこと。

ﾄﾝ
sledgeってちょっと調べたんだけど、ちょっと機能がありすぎな印象。
セッション、クッキーのモジュールなんかも自由に選べたり自作のものを用いられたりするような。
>>258のguessworkみたいなのをPerlで実現したいなあ。
それで、例外処理も楽にできちゃうようなやつ。
mojaviって例外処理どうなってんだろうか？
ちょっとコード覗いてみるかな。

『Mojavi で簡単Webアプリ』とか『Mapleで速攻Webアプリ』なんて
本出したら、意外に売れませんかね？

ま、個人的には、guessworkくらい軽量のフレームワークの方が
見通しが良くて好き。

一般的な価格(1ページ単価10円前後)の本って
何部売れればペイするんだろう...

「Phrameで簡単Webアプリ」だと
http://www.9-ten.co.jp/bookdata/0195.php
がそれっぽかった。

>>268
そーゆーのはサブタイトルにして
「サイト作成のMVC入門」とかにした方がいいんじゃないか。
PHP自体は初心者本ばかりだから初心者本を終わった人の次のテキストとして。
あるいは、オブジェクト指向とかの方法論はJava一色だからそうじゃないアプローチ
として、そこそこいけないかな。
「まるごとPHP」みたいなムックで、「まるごと」みたいに総括的じゃなく
「フレームワークPHPvol.2」や「PEARPHPvol.3」とかシリーズ化してくれると
いいな・・・

タイトルよか、やっぱり中身が大事かな。

>270の本は、なんであんなタイトルなんだろう？すなおに「Phrameで
簡単Webアプリ」で良いような気がする。

「まるごとPHP」は悪くはないと思ったけど、ちょっと幅広く詰め込んで
いたからなあ。Vol.1ってことは、Vol.2も出るんだよね？と期待Age。

>>272
Phrameってなに？というか、そのタイトルをみて、自分に関係あるとは思わない人がほとんどになるんじゃない？

(ちょっと強引に)包含関係を作り上げると、
Webサイト構築 > フレームワーク > MVC > Phrame
になるから、大きい方に振っちゃうのは仕方ないと思われ。
ｵｲﾗは Mojavi大全 とかいう名前の方に惹かれるがｗ

モジャビで遊ぼう！とかがいいな。

「アノ娘のモジャモジャビックリ」にすると購買層はグッと広がると思います。

Mojavi3も大分できあがってきたな。

maple の componentsディレクトリ ってどうやって使うんだ？
説明みたが
webapp/components/ DIするクラスを配置するディレクトリ
って書いてあるだけ。
DIContainer.class.php が絡んでくる気がするんだが、よく分からん。
そもそもDIするって何だ？って感じですが。
ソース嫁って話ですか？
orz

Mapleの中の人のblogを拝見しました。ここを見てたのね。
要望が伝わって良かった。すごく期待しています。ホントです。
失礼な物言いもあったと思うけどゆるしてね。
期待の裏返しということでひとつ大人の対応で。
>>278
さすがにDIコンテナの説明までMapleの人に求めるのは酷だと思うよ。
俺もわかってないけどさ。（とりあえずダミーで開発を進められるという認識。間違ってる?
依存性の解消ってのは今ひとつ腹に落ちてない。）
しかし、PHPを使ってる人にはDIコンテナなんて聞いたことない人もたくさん居ると
思うので、後々はMaple流のDIコンテナの利用法・Maple流の開発手法といった
コラム的なのがあるとすっげーうれしい。
ご本人じゃなくても、周りの人やりませんか?
Maple普及の決定打になると思うんですけど。

全部他人におまかせの>>279に萌え

１時間程調べてみたら説明あった・・・ orz

ttp://bobchin.ddo.jp/wiki/index.php?maple%2F%BB%C8%CD%D1%CA%FD%CB%A1#content_1_13

読んでみたがやっぱり良く分からなかったが
maple.ini の DIContainer セクションで設定ファイルの位置を定義して
設定ファイルから DIContainer フィルタを経由してオブジェクトがセットされると。
そん時に Request や Session からの値は ref: を使用すれば渡せますよ。
んで、 maple.ini からも ref: を使用してそのオブジェクトを取れますよと。

そんな感じであってるかね？

「maple の DI」という枠組みから始めようとしちゃイカンよ。
このアプローチの何が嬉しいのかをまず知るほうがいい。

http://www.kakutani.com/trans/fowler/injection.html

で、mapleが実現しようとしている目標として
DIContainerを使ったときの設計手法であるSeasarの「くーす」を
PHPでやろうとしてるわけですよ。

LLのなかでもwebアプリ構築のフットワークが比較的軽いPHPで
この手法が手軽に取り入れられるとなると、結構面白い事になりそ。

>>280
うん、十分自覚してる。推敲前は「他力本願」なんて言葉いれてた。
らしくないと思って消したけど。まっその突っ込みからは何も生まれないから
せめて持ち上げて人にやらせる口調の方が組織に受け入れられると自画自賛。
↑大人な人はうなづいてくれると思う。言い方には問題あるけど。
>>281
知ったかぶりになるんだけど、それであってるんだけど、本来はきっと
オブジェクトの内容をしらなくても（あとまわしにしてインターフェース定義
だけの状態で）受け取れますよ。当然、クラスの内容が変わっても同じインターフェース
なら問題なく動作しますよ。ということのための仕組みと思うのですが自信なし。
（だから説明が抽象的）
>>282
そうそうMapleの優位性ってそこにあると思う。軽いのや解り易いのは今も今後も
出てくるだろうけどDIコンテナを実装してるのはMapleが最初。
あとはMapleが軽く（これハード性能で解決できるからどうでもいいと思う）
わ・か・り・や・す・くなってくれれば…

楽・簡単だからPHPを選んでいるような層には「くーす」は
敷居が高すぎるような気がするんだけども、どうなんだろうね。

あと、DIはServletみたいにコンテナがずっと存在しつづける場合は
色々嬉しいけど、PHPでリクエストの度に依存関係をたどってオブジェクトの
親子関係を作って行くのはデメリットのほうが大きいような気もします。
まあ、Mapleの作者さんはこのあたり既にわかっていて対策を講じようとしている
ようにも見えるけど。

DIでくーすでってやるなら、結局Javaでやるほうが楽。

PHPのフレームワークって「ホントはJavaでやりたいんだけど」
って人向けが基本では？

>>287
共有鯖でJava使えるとこなんてほとんどねーだろ。
個人や低予算でなんか始めたいってときにJavaは悲しいほど不向き。

mapleなんかは中の人の日記読んでるとJAVAの思想を模倣しつつも
PHPでライトウェイトな新しいやり方を模索してる希ガス。

>mapleの中の人
間違ってたらごめん。

まったく理解しがたい発想をするやつと自明のことを思いついたことのように書くやつ

>>290
お前は後者だな

そして文脈ということばを知らない奴

同じ阿呆なら踊らにゃ損々。

>>289
ていうかお前は言ってることがむちゃくちゃだ。

少し前からPRADO使ってるんだけど、これけっこうイイな

テンプレートで独自タグ使いまくりなのは一長一短だけど、その代わり
PanelとかPlaceHolderみたいな使える機能が多い。

既存のコントロールを組み合わせて1つのコントロールとして扱うことも出来る。
独自フォーマットの妙な設定ファイルも無いし。

PHP5で作られているので、フレームワークと自分で書くコードとの違和感もない。

guessworkとは対極の、全部入りのフレームワークとしてこれから普及して
いくんじゃないかな。(もちろんguessworkも方向性としてはアリだとおもう）

ゲスはライブラリコンテナみたいなものに進化してくれ！
今のままじゃフレームワークというよりただの骨骨コントローラじゃないか。

ライブラリコンテナってなに？
ゲスはバコバコいろんなとこから手持ちのモジュールをくっつけられて、
簡単なものをサクッと作るのにイイ！

たしかにゲスはフレームワークというくくりで語るべきじゃないかもしれないな
ただのコントローラーともいえないが・・・

Mapleの中の傍らの人の説明見ました。お疲れ様です。
「自分で調べなさい」なら平行線だね。
ケチつけるだけで心苦しいんだけど
「わかってる人でないとわからない説明」というのが正直な感想。
ごめんね。（じゃ、どうしたらいいかというと説明は断片的でもいいから
動作するソースをダウンロードできるようにするだけで随分と違うような。
例えそれが自明のものであったとしてもね。）
まぁDIコンテナは使わなくてもMapleは使えるんだけど
フィルタは使わないとMapleは使えない。チュートリアル…

PRADOでつくられたCMSってことで、ENTITYを自分のPCに入れて走らせてるんだが、
激重だな…

>>296-298

ゲスのコンセプト自体、なんでもかんでも揃ってますとは対極にあるね。
土台として利用して、その上で好きなように積み上げて作っていけるのは
好きかも。ライブラリコンテナ的に利用できるってのは、ありがたい。

PHPの多機能なフレームワークって、俺様独自仕様が多すぎて、かえって
使いづらいからな。一度覚えて慣れてしまえば、そんなことないのか？

プロジェクトで使用するライブラリ群を一貫して統一できるなら
フレームワークにこだわる必要はないと思う

そんなことをするくらいなら、
フレームワークにこだわったほうが効率がいい

>>302標準以上の知能
>>303標準以下の知能

そして>>302=>>304

＞プロジェクトで使用するライブラリ群を一貫して統一できるなら
スタッフ増員とかのたびに、その統一基準についていちいち説明するんですか？
無駄が多くてしょうがないですね。

>>305と>>306は理解できてないようなので標準以下でいいと思うが
果たして>>304は基準として適当だろうか？

>>307
別に304が標準の基準というわけではないとオモッタ
名前にレス番入ってないけど、下っかわはどれとどれが同一人物なの？

>>302=>>304
−−−−−−−−−
>>303 >>305 >>306

>>307
まともに理解できてないのお前じゃんｗ

その統一仕様を定めるのにフレームワークをつかうわけだが

>>302が言ってるライブラリって、例えばサニタイズしてくれる便利関数群みたいな意味合いじゃないの？
プロジェクトで規定のライブラリがあるっつーのは結構ありえる状況だと思うんだが。

よ〜し、パパ(プロジェクトマネージャーか？)このフレームワーク使っちゃうぞ♥
って躊躇無く言い出せる状況ってのは、
メンバー全員がそのフレームワークを使った事がある時くらいじゃないかなぁ。

フレームワークの肯定・否定をするつもりはないよ。
話がずれていってる気がしたから突っ込みいれてみただけ。

いまどきフレームワークも使わずに
自称便利なライブラリ群で開発しちゃうような屑会社には
未来なんてあるわきゃーねぇ。もう業界辞めちまえよ。な？

フレームワーク使うことにすれば「サニタイズしてくれる便利関数群」
の仕様もおのずと決まって楽チンなんです。

>>302 >>304
−−−−−−−−−
>>303 >>305 >>306 >>310

かな。
>>309は敷居以下で

ちょっと煽られただけで自分と同じこと言ってる奴も敵判定して当てこすっちゃうナイーブ君に萌えたｗ

>>315
長い

なんか妙なフレームが起きとる・・・。
俺解釈のお遊びなんだから、ピンとこなくても深刻に取らないで呉。
>>302に比べて、>>303は素直な発想できるいい奴だし、
こんなんで知能はかれるわけもないからなー。

>>314は>>309以下で

>>311
＞プロジェクトで規定のライブラリがあるっつーのは結構ありえる状況だと思うんだが。
うん。確かに効率悪いことやってる会社や閉鎖的なとこでは結構あるね。

＞メンバー全員がそのフレームワークを使った事がある時くらいじゃないかなぁ。
使ったことなくても、まともな奴ならメジャーなフレームワークくらい覚えてくれる。
他のプロジェクトや、会社変えたときも使えたりするから。
もちろんPHPではまだそういう環境は整ってないけど。


あとは>>313に同意。それを理解できずに>>304達が標準以下な発言しだすから
話がずれてるように感じるんじゃない？

いや、俺が標準云々といったのと、フレームワークの効用を理解でき
ているか、ということは関係ないんだよ。

・俺に>>302のレスが標準以上に見えたのは、オールインワンな
多機能FWは面倒で、「好きなように積み上げて作りたい」という
>>301に対し、さりげに「プロジェクトで一貫して統一できるなら」
と皮肉っている産婆的な部分があったから。>>301にはチームで
開発するという視点が欠けていると感じていたから、ライブラリを
統一するようなチーム開発上のメリットをほのめかすやりかたが
上手いと思った。

・>>303をふざけて標準以下としたのは、「統一性を保障できるならFW
にこだわる必要はない=>FWはプロジェクトの統一性を保障する」という
>>302に対し、「ライブラリを統一するよりFWで統一する」と、ナンセ
ンスなレスを返してたから。俺は、>>303は>>302のレスを「ライ
ブラリ群をメンテして統一しろ（FW不要）」と読んでいると思う。だから、
「そんなことをするくらいなら」という言葉が出てきたんだと思うけど・・・。
まあ>>302と>>303はフレームワークの効用を理解しているかどうかで
言うとどっちもおんなじレベル・おんなじ知見だよ。

その後はいくつかのパターンがあるけど、FWを使うと仕様統一が楽
という当たり前のことを繰り返すレスと、誰かがFW使うメリットはない
と言ったかのように勘違いしてライブラリ開発否定して煽ってるよく
分からない人がいるって感じ。

フレーム起こしといて>>317だけじゃ無責任かと思って全部吐きま
すた。誤解がとけたかな？

どうでもいい。
おまえが煽ったせいでおかしな事になった”現実”を認識して、その”事実”を反省しろ。

フレームワークの利点を理解できていないという理解がレスを理解できていないということを理解していないという理解だと理解したｗ

↑翻訳ｷﾎﾞﾝﾇ

>322
ようするに>304はバカだと

>>321
こういう”どうでもいい”レスをする奴が低レベルな煽りを入れてんだろうなあ

結局文盲が勝手に煽られたと思って騒いでただけじゃん
真面目にフレームワークの話をしてくれた人が浮かばれねーですよ

PradoとMojavi3どっちがくると思いますか？
多分今後広く使われていきそうなのはこの2つだと思うんだけど。

>>320
だから誤解じゃなくて、お前が理解できてないんだって。
＞>>302に対し、「ライブラリを統一するよりFWで統一する」と、ナンセ
＞ンスなレスを返してたから。
>>313読んでから書け。

>>328
ためしに聞いてみるけど、俺が「何を」理解できてないと思ってるの？

>>329
もうこれ以上つまんないレスするなら消えてほしいんですが

ここで土管マン登場！

　　　 .L二二」
　　　　| 　 　|
　 　 ヽ|・∀・|ノ
　　　　| 　 　|
　　　 .L二二」







　　　 .L二二」
　　　、| 　 　|　/／
　　ヽ　　　　　　　∴
　　ゝ∴　　├¨力 ン
　−　　∵　　　　　∵
　　／/|＾＾”^lヽ　ヽ
　　 　.L二二」

>>329
＞ためしに聞いてみるけど、俺が「何を」理解できてないと思ってるの
君のせいで、まともなネタすら煽りレスに流されてしまっているということ。
そして、君がいなくなればそれらが全ておさまるということを、まったく理解できていない。

>>329
フレームワークのメリットが理解できてないと思われてんじゃないのｗ
お相手さんは目が真っ赤だから、何を言ってもフレームワークの話に聞こえんだよ

>>331
土管乙

>>304乙

>>332
たしかに土管マンも切ない限りだな。

目が真っ赤で土管マンの登場の意味すら理解できていない>>333

　　　　　　　　　　　　　　 　 　 　 　 ,ｲ　　　　│
　　　　　　　　　　　　　　　　　　　 //　　　 　 |:!
　 　 　　　　　　　　　　　 　 　 　 //,. -/r‐- ､| !
　　　　　　　　　　　　　　　　 　 /,/　./　|　　_」 ﾄ､
　　　　　　　　　　　　　　　　　/.＼`/　　|二...-┘ ヽ
.　　　　　　　　　　　　　 　 　 i　　 ,.>､;／ｰ- ､　　　 l
　　　　　　　　　　　　　　　　 ! ∠..＿;'＿＿＿_＼ 　 |
　　　　　　　　　　　　　　　　,!ｲ く二>,.、 <二＞｀＼.､ヽ.　　　　　
　　　　　　　　　　　　　　 ／'´レ--‐'ﾉ. `ｰ---- ､　|＼ ヽ、 　　　 >>304　いいんだぞ？俺の胸の中で好きなだけ泣け。
　　　　　　　　　　　　　　＼　 `l　　(!"　　　 　 Jfヽ!　 `''-;ゝ
　　　　　　　　　　　　　　　 `‐､jヽ　ヾﾆﾆ>　　 ﾞｲ" }_,,. ‐''´ 　　　　
　　　　　　　　　　　　　　 　 　 `´＼　 ｰ 　 ／ ,ィ_}
.　　　　　　　　　　　　　　　　　 　 |_ `ー ''´　＿｣'
　　　　　　　　　　 , ー‐-‐‐‐--''.‐''゛,,;,,...:　　　　゛''-､､,;,,
　　　　　　　　　,ｨ'゛　　　 　 　　　 　　 　゛゛""'　　　　　゛"'''-､
　　　　　　　　 /　　　　　　　　　　　　　　　　　　　　　　　　　 ヽ
　　　　　 　 　/　　 　　　 　　　　 　　　　　　　　　　　　　　　 　'、
　　　　　　 　l　　　　　　　　　　 　　　　　　　　　　　　　　　　　　l　
.　　　　　　　l 　 　 　 　 　　　 i. 　 　 　 　 　 　 　 　　　　　　　　l　
　　　　　　　 l 　 　　　　　　　 :i.　　　　　　　　　 ヽ.:.:...:.::　　　　 "'
.　　　　　　　 l　　　　　　　　　.:l 　 　 　 　　　　　　ヽ.:.::...　　　　　"''､
.　　　　　　　 l. 　 　　　　　　　.:l 　 　 　 　 　 　　　ヽ.:..:.　　　　　 　`'､
　　　　　　　　l　　　　　　　　　::l:　　　　　　　　　　　';.:.:.....　　　　　　ヽ
　　　　　　　　l　　　　 　 　　　.:l.:.. 　 　 .:ｨ.):.:. 　　　 l.:.:.:　　　　　　 .:.ヽ、
.　　　　　　　　l 　 　 　 　 　 　.:l..: 　 　 ''ー.:　　　　.:.:l.:.:..:..::　　　　　　.:i'゛

真っ赤に反応するのかｗ

>>304>>333が理解できてないといわれると反応するのと一緒だなｗ

まあ香ばしくなってきましたが、話の通じそうな>>328待ちということで。

流れそうなので先に「理解」について書くいておくと、俺は>>328が、
俺のことをフレームワークを云々している男だと思っていて、そのフレー
ムワークの「理解」に間違いがあると思っているので、>>313を読んで、
考えを改めなさいと言おうとしている、と思っている。

で俺は、>>328がいまだに、>>304（俺）がたんにレスの読解の仕方で
恣意的に分けただけ、ということを「理解」していないと思っている。

↑いまここ。

>>340
も一回、>>321読めよ。

> ＞>>302に対し、「ライブラリを統一するよりFWで統一する」と、ナンセ
> ＞ンスなレスを返してたから。

もしかしたらこの引用も、俺がFWで統一するのがナンセンス
だと思っていると「理解」されてるのかね。さすがにそこまでは
ないと思うけど、何か書いてくれないと分からないよ。

>>327
じゃあどっちもくるんじゃね?

>>342
>>330-332>>337を読め

　　　　　　　　　　,;r'"´;;;;;;;;;;;;;;;;;;;;;;;;;;｀ヽ、
　　　　　　　 　,r'";;;;:::::;彡-＝―-=:､;;;;;;ヽ、
　　　　　　　　/;;ィ''"´　 _,,,,....ﾆ、 ,.,_ ｀ヾ;;;;〉
　　　　　　　　 `i!::　,rﾆ彡三=､' ﾞ''ﾆ≧=､!´　　
　　　　　　　　r'ﾆヽ, 　 （　・ｿ,;　（､・')　　i'
　　　　　　 　 ll' 'ﾞ　,;:'''"´~~,f_,,j　　ヾ~`''ヾ.　　　　　
　　　　　　　　ヽ) , :　　　 ''"　`ー''^ﾍ　　 i! 　　　　標準以下の知能しかないから
　　　　　　　　ll`7´　　　 _,r''二ニヽ. 　 　 l　　 何か書いてくれないと分からないよ…
　　　　　　　　!:::　　　　 ^''"''ー-=ﾞゝ　 　 ﾘ
　　　　　　　　l;:::　　　　　 ヾﾞﾞ`^''ﾌ　　　 /
　　　　　　　　人、　　　　　 ｀ﾞ’ﾞ::.　　　ｲ

>>345
何にしてもボロボロすぎだ

消えろって言って消えるような奴は>>304みたいなレスしないよな。
ほっとけばそのうち他のスレにからみにいくだろう。

(ﾟДﾟ)ﾊｧ? これで終わりかよ？

おい>304、理屈こねてーでフレームワークの一つや二つ作って
公開してみろや。話はそれからだ。

>>350
このレスはさすがに>>304の自演くさいな…

意味分からん
ログ流そうとしてるようにしか見えないんだが

>>351-352
(･∀･)ｲｲﾖｰｲｲﾖ-

http://www6.big.or.jp/~beyond/bbsnews/2ch/top/php.html
スレッドランキングから記念真紀子

ﾜﾛｽｗ
大人気じゃんか

Mojavi3ってまだデータベース関係のクラスできあがってない？
とりあえずセッション関係はmysqlで動作することは確認できたんだけど。
だれか詳しい人いませんかー

良スレと思っていたら Mojavi や Maple の認知が上がるに従い質低下、挙げ句、自分以下探しで荒れる、と。
ここ最近は初期のスレ住民からの書き込みが絶えてるし。旬も終わったな。

>>356
釣り？

できてるよ。
コネクションしかサポートしてないけど

>>357
もっと具体的に言ってごらん？

Phramest

>>358
ごめん。コネクションまでは確認したんですよ。
その先の話。

>>357
そう思うのはかまわないけど、その連中にまじって一緒に質の低い書き込み
をするなよ。

フレームワークも知らずにWebプログラマを語るな。

>>363
誰がWebプログラマを語ってたの？

昨日突然錯乱した厨房！今日も期待してるぞｗｗ

夜を徹してprado使ってみたよ
phpmvcから乗り換えようと思ってて、とにかく開発スピードが異様に速かったこれが目に付いた
mojaviより魅力を感じたのはUIをコンポーネント化してる部分なんだが、先輩方にはおおむね不評ｗ
マクロメディアの製品みたいなどと言われた。よく分からん

html自体データを抽象化するものだから冗長という気もするが、俺はこのコンセプトに惚れた
テンプレートにはあれこれ書かないんだから、HTMLをパースしてオブジェクトにマッピングしてくれても
いいように思ったが、、、つかそういうのもうあるかも

青果関係のシステムを仮想目標に弄ってるんだけど、そのままだとオモイ
とにかく膨大なオブジェクトがにあるのでアクセスごとに初期化するのが苦しいようだ
JavaやASPに近づけ過ぎるとこうなるという典型のよう
あと、pearの目的に特化したライブラリに比べると機能的にはかなり薄い、DAOとか。他のフレームワークも
似たようなもんだが、バージョン2ならもうちょっと充実しててもいいんではなかろうか

書きなぐりで悪いけど第一印象はそんな感じ

コンポーネントベースなので、各部分について順に学ぶことができる。フレームワークって
なんぞやと思ってる人や、mojaviのチュートリアルじゃ覚わらんつー人なんかにはバッチリ
とりあえずさわってみて感想きぼん

>>366
別にMacromediaの専売じゃあなく、XMLでUI定義するのは流行り。
Java/Servletのゴタゴタしたカスタムタグよりだいぶマシだと思うが。

おまえらフレームワーク使いたいなら素直にJavaやれ

PRADOが良く見えるのはフレームワークとしての輪郭がはっきりしているからだろう。
概念化のレベルでの完成度が高く全体を単一の仕様で固められるので魅力的。
しかしLLとしてはMojaviが正解だと信じたいね。どちらが抜けていくか知らないけれども。

俺はmojavi3使ってる
mojavi2と比較してモジュールの設計が更に洗練されてるよ。
2ではrenderer、session、auth周りがごちゃごちゃしてる印象を
受けたけど、それが改善されてフレームワークとしての統一感が
強くなったように思う。
それに今までcontroller、request、userインスタンスをメソッドの引数として
受け渡ししてたけど、それらをContextクラスで管理するようなったから
かなりスマートになってる。
例えば、Actionクラスのメソッド内で
$request = $this->getContext->getRequest();
こんな感じで参照できるようになった。
あとActionChainがなくなってそれに変わる新しい機能が加わった。
Decoratorパターンを使ったグローバルテンプレートを作成する機能で
例えばメニューとメインコンテンツを表示する2つのActionがあったとして
それらを同時に表示したい場合に効果を発揮する。

まあmojaviのソースを追ってる人にとっては何を今さらと思うだろうけど。
pradoやmapleは使ったことないので、比較できないけど出来る人がいたら
レビューｷﾎﾞﾝ

>>370
mapleはPradoやMojavi3と比較できるもんじゃないな。
Mojavi3はまだデブなんでなんとも

久しぶりに公式見たらMojaviに曲まで付いててﾜﾛﾀ
こりゃMapleも対抗しないとダメだね勝てないね

・・・魔法少女リリカルめいぷる？

>>369
Javaユーザでプリミティブなものが好きな人間もいると思うが

>>370
じぶんで使ってみた方が早くない？

モハビって言いにくいよね。
モジャビでいいじゃん。

Mojavi3のマニュアルの
http://wiki.mojavi.org/143.html
このページで
$this->getContext()->databaseManager()->getDatabase($name)->getConnection()
$this->getContext()->databaseManager()->getDatabase($name)->getResource()
↑こう書いてあるけど

$this->getContext()->getDatabaseManager()->getDatabase($name)->getConnection()
$this->getContext()->getDatabaseManager()->getDatabase($name)->getResource()
↑
これの間違いじゃない？

>>365
結局お前が最後の錯乱厨だったみたいだな…

 Call to a member function on a non-object in /var/www/php/mojavi/mojavi/mojavi-all-classes.php on line 413
というエラーが出る。何でだろう？
一応、viewの方でvar_dump($request)してみたらDBからデータは来てたケド、
漏れは何か変な事してるんですかね？
コードは、
TestAction.class.php
<?php
class TestAction extends Action
{
    function execute (&$controller, &$request, &$user)
    {
        //DBからデータを取得
        require_once('adodb/adodb.inc.php');
        $db = &ADONewConnection('postgres');
        $server = 'localhost';
        $user = 'hoge';
        $password = 'password';
        $database = 'test';
        $db->PConnect($server, $user, $password, $database);
        $table = 'test';
        $res = $db->Execute("select * from $table order by id");
        $request->setAttribute('message',$res->GetRows());

        $res->free();
        return VIEW_SUCCESS;
    }
}
?>

続き
TestView_success.class.php
<?php
class TestView extends View
{
    function &execute (&$controller, &$request, &$user)
    {
        $renderer =& $request->getAttribute('SmartyRenderer');
        $renderer->setTemplate('Result2.html');

        $renderer->setAttribute('title','簡単なテスト');
        return $renderer;
    }
}
?>

長すぎと言われたので二回に分けました。

Actionのexecuteで$userに'hoge'を入れてる
$userにはMojaviのUserオブジェクトが入ってるから変数として使っちゃダメよ

>>380
ありがとう。とりあえず、一つ解決しました。

誰かMojaviの日本語マニュアル書けよ。

>>382
ｶﾞﾝｶﾞﾚ

期待してるぞ。

http://ozaki.kyoichi.jp/mojavi3/index.html
ここの人のPEARの組み込み方ってかなり変じゃない？

>>384
具体的にどう変かね。DAO経由でアクセスしようとしていると思うのだけれど、
それは好みでしょ。変とかじゃないと思うが。

おいお前等こんな貧乏臭いシェアなんか使うなよ。馬鹿にされんぞ？
プログラマなら秀丸なんかより便利で高機能なプラグインが充実してる
Eclipse使うべきだし、物書きならワープロソフト買えよ。
秀丸と言う選択はねーだろ。マジで。

>>386
誤爆？

>>386
多くの職業物書きがエディタで書いてることを知らない誤爆ｸﾝ。
まあ秀丸を使ってるかは別だが。

emacsのキーバインドが使えれば何でもええよ。
>>382 期待してるぞ

>>382は超がんがれ。

>>385
作者さんがそう思われるなら…もうなにもいうまい

>>391
おはよーございます。
ところで、作者さんじゃないんですが…。
コード見ても「ふーん」くらいにしか思わないんですけど
どこが変なの?

mojavi使おうと思ってるんだけど、template engineって何が良いだろうか？
smarty？、flexy？その他？

smartyスレで聞いたほうが良いかなぁ？

>>392
コードが変なんじゃなくて組み込み方が変なんです。
database.iniがあるのにconfig.phpにdefineしてる時点で
おかしいと思いませんか？
個人の好みでこんな書き方しちゃうなら、フレームワーク
使う必要ないと思うんですが。

>>394
それはmojavi3の新機能なの？
mojavi2しか使ってないからdatabase.iniなんて知らなかったよ。

mojavi3、もちっとドキュメントを・・・・・・・
天才mojaviマスターの方、日本語解説を・・・・・

ﾌｼﾞﾓﾄｾﾝｾ、Ethna Power"e"dだと思うのですが・・・

おっとすごいとこでツッコミをいただきましたね。ありがとうございます。
なおしときますー。

や、あのロゴとページつくったの僕じゃないんですょ...(一応いいわけ)

こんな過疎スレに即レスがあってビビってる漏れガイル
ちなみに前者のほうが好きな色合いなだ

ちょうどEthnaの時間だったので。だいぶ偶然ですねー。

mojaviであるアクションを別のアクションに遷移させるとき以下のようなコードを書きますよね？
//----HogeListAction.class.php-------
//前略
if($request->hasParameter('hoge')){
$controller->forward('Fuga','HogeAdd');
return VIEW_NONE;
}
//後略
で、何故かうまく遷移してくれません。上記コードのreturnの前にvar_dump($request);を仕込んだら
ちゃんと$requestの内容が表示されました。
やりたいことは、Index → HogeList → HogeAddのように遷移させることです。
なにか、「ここはチェックしろ」等あったら、教えてください。

>>401
GET | POSTがそのままforward先のActionに伝わるのを見落としてるとか

mojaviのすれはPhrameだったのか・・・

>>402
即レス感謝です。
それは、別の所で散々はまったので、ちゃんと
$request->removeAttribute()
$request->removeParameter()
しています。

実際は以下のように、いくつかの条件分岐があります。
if($request->hasParameter('hoge')){
$controller->forward('Fuga','HogeAdd');
return VIEW_NONE;
}elseif("別の条件"){
$controller->forward('Fuga','HogeEdit');
return VIEW_NONE;
}
ここで、念のためにHogeEditに飛べるかどうか試してみたところ、画面が切り替わり意図した表示となりました。

それで解決のためにログを取りたいのですが、遷移の様子を全てログに記録するには、どのようにすればいいのでしょうか？

>>404
んー、debug_backtrace()で取れるもんなのかね？使ったことないからよくわからん
ていうか処理は多分HogeAddに移ってると思うから、
HogeAdd内の処理を見直したほうがいいんじゃないだろうか

>>405
別のアクションを作りながら、色んな所にecho突っ込んでみたら、
HogeAddのinitialize()の中までは来てました。
同じようにexecuteとgetDefaultViewにもecho入れてみたら、
そいつらは表示されませんでした。

んー、HogeAdd内の処理ですか。特に何もしてないんですけどね。
長いと言われたので一旦切ります。

コードはこんな感じ。
class HogeAddAction extends Action
{
    function initialize (&$controller, &$request, &$user)
    {
        $form = new HTML_QuickForm('HogeAdd', 'post');
        //色々$form->addElement()とか$form->addRule()とかしてるけど長いので略
        $request->setAttribute("form", $form);
        echo 'これは表示された';
        return TRUE;
    }
    function validate(&$controller, &$request, &$user)
    {
        $form =& $request->getAttribute("form");
        return $form->validate();
    }
    function execute (&$controller, &$request, &$user)
    {
        echo 'これは表示されなかった';
        return VIEW_INDEX;
    }
    function getDefaultView (&$controller, &$request, &$user) {
        return VIEW_INDEX;
    }
    function getRequestMethods () {
        return REQ_POST;
    }
}

$request->hasParameter('hoge')はちゃんとtrueを返してる？

連投スマソ。

今、試しにvalidate()の返り値をtrueにしてみたら、ちゃんと表示したいモノが表示されました。
てことは、validate()の中で、場合分けしてやればいいんですね。
もしかしてコレが、>>402の
＞ GET | POSTがそのままforward先のActionに伝わるのを見落としてるとか
に関わってくるんでしょうか？

うーん、謎だ。

>>408
それは、何度もvar_dump()で確認しているので大丈夫です。
>>401の後半にも確認した方法が書いてありますです。

おおっと、これは失礼した

なんとか解決しました。
>>405のレスをヒントに内容を見直しました。
>>407で$form->addRule()してたヤツを全部Viewに移したら、
ちゃんと望み通りの動作になりました。

つまり、HogeList → HogeAddに遷移したときにinitializeに書いてある$form->addRule()に
反応して、validate()が意図しないところで働いてくれたため、というのが真相のようです。

＞レスしてくれた方々
どうもありがとうございました。

>412はちょっと嘘です。
Viewに鯖側の$form->addRule()を書いても利きませんです。
なので、>409の通りにvalidate()の中で、場合分けするのがいいみたいです。

一応、訂正だけ。

それもMojaviのActionFowardで陥りやすいミスだわな
リクエストがそのまま渡るから、getRequestMethods()で返されてるメソッドがきた場合に
Validatorが動作しちゃって、前のActionに渡したつもりのパラメータが検証されてしまう

そういうこともあってどうしてもController::redirect()を多用することになっちゃうんだよなー
何かうまい解決法はあるんだろうか

と思ってコード見てたらRequest::setMethod()があるのか
これ使えるんかな、でもActionForwardで呼びたいのは大抵execute()だろうしなぁ

>>414
漏れはQF使っているので<form>のhiddenでmoduleとactionを、変化させながら持ち回ろうとしたら、
上手くいかなくて困っています。$request->removeAttribute()とか$request->removeParameter()とかしても
moduleとaction(正確にはhiddenで廻してきた値)はうまく消えてくれない（遷移先のViewの<form>で復活してる）。
var_dump($reqest)してみたらなんか_submit=array()の中にhiddenで廻した値が入ってて、
$request->removeAttribute()とか$request->removeParameter()とかでmoduleやactionを消しても
そこに残っているのが廻ってくるらしい。

仕方がないので、$controller->forward()で
Index → HogeList → HogeAddという遷移の場合はexecute()内で
Indexに来たときに変数fugaを持ってたら、HogeListへ
HogeListで変数fugafugaを持っていたらHogeAddへという風なことをやって
見た目には動いているように出来たんですが、どこでsubmitしても、
必ずIndex経由で行こうとするので、処理を追っかけるのがしんどいです。

＃チラシの裏逝きかな？

>>415
Request::setMethod()ってGET使うかPOST使うか設定するものじゃないんですか？

>>416
なんか似たような事ではまったような記憶があるな
とりあえず遷移ステップを中継するhiddenの値は遷移後に
HTML_QuickFormのsetConstantsメソッドで指定し直すようにしてる
なんか全然違う事言ってたら申し訳

それはそうと入力の検証ってやっぱみんな
HTML_QuickFormのヴァリデータ機構でやってるんだろうか
mojaviのヴァリデータ機構もいい感じだと思うんだけど

>>417
例えばこんな感じですかね？
$form->setConstants(array('module' => 'Hoge', 'action' => 'HogeFuga'));

漏れは
$form = new HTML_QuickForm('HogeFuga', 'post', 'index.php?module=Hoge&action=HogeFuga');
でやってた。この方法の欠点は、アドレスバーに表示されるActionと遷移先のActionが一致しないこと
（場合によってはmoduleも一致しない）
>>417のやり方は良さそうなのであとで試してみます。

入力値の検証は今のところ、QFのを使ってる。
まあ、必要になったらmojaviのヤツも併用できそうな気がするので併用するつもりではあります。

>>417
結局、調べてみた結果こうするのが一番漏れのやりたいことに近かったもより。
$form->updateElementAttr('module', array('value'=>'Hoge));
$form->updateElementAttr('action', array('value'=>'HogeList'));
これで、hiddenでmoduleとactionを持ち回るのは完璧っぽいです。

結局mojaviとはあまり関係なくてQFの使い方って方向になってしまいました。
＃QFマニュアルの翻訳早く進まないかなー。

Linux上でMojavi2を使おうとしています。
最初の環境設定(のテスト?)でindex.phpのdie(...)行をコメントアウトすると
PHP4.3.3だと動作するのですが、PHP4.2.3だと
Notice: Array to string conversion in /path/to/mojavi/lib/mojavi-all-classes.php on line 355
となってしまいます。
ディストリの都合で4.2.3で使用したいのですが
対策をどなたかご存じないでしょうか。

>>420
355行目付近は次のようになっていて、
$logger =& LogManager::getLogger();
set_error_handler(array(&$logger, 'standard'));

set_error_handler()は
> 注意: 関数名の代わりにオブジェクトへのリファレンスとメソッド名を含む配列
> を指定することもできます。(PHP 4.3.0以降)

なので、コールバック関数名で呼び出すように書き換えるしか無いかと。
面倒なので 初っ端のerror_reporting()を E_ALLから変更するつーのもありですが。

>>421
E_ALLをE_WARNINGとかにしてもエラーが発生するとおかしくなるので
コールバック関数もどきを作ってみたところ、なんとか動いているようです。
ありがとうございました。

あの、ActionとかViewクラスのテストってどうしてます？
mojaviの掲示板に、testControllerとかあったけど、よくわからんかった。

mojaviの掲示板ってどこですかぁ

>>424
本家のフォーラムのことでしょう。
それ位汲んであげてもいいんジャマイカ？

多分これ。
ttp://forum.mojavi.org/lofiversion/index.php/t355.html

mojavi のテンプレートエンジンを
HTML_Template_Flexyにしようと思っています。

smartyを参考に作ったのですが、
ここの箇所が必要なのかわかりません。

// assign smarty variables
$this->setAttributeByRef('controller', $controller);
$this->setAttributeByRef('mojavi', $controller->getMojavi());
$this->setAttributeByRef('request', $request);
$this->setAttributeByRef('user', $user);

function setAttributeByRef ($name, &$value)
{
$this->engine->assign_by_ref($name, $value);
}
当然のことながらFlexyのソメッドにassign_by_refはなく、
controller,mojavi,request,userのオブジェクトを渡しても意味がない気がします。

FlexyにもSmartyのassign, assign_by_refに当たるメソッドがある。
Flexy.php見れ。

ttp://mojavi.try-angle.biz/wiki/index.php?Mojavi%A5%C1%A5%E5%A1%BC%A5%C8%A5%EA%A5%A2%A5%EB1#content_1_10
ttp://www.stackasterisk.jp/tech/php/mojavi04_01.jsp#2

これ両方とも間違ってるなぁ（情報が古いのかな？）

＞function validate (&$controller, &$request, &$user)
＞{
＞return TRUE;
＞}
＞これは「入力の検証を有効にする」というスイッチです。(もしvalidateメソッドを省略した場合はActionからFALSEで継承されます)

Actionクラスのメソッドは素で、TRUEを返すだけ（つまり、上の関数のまんま）
validateをオーバーライドするのは、カスタムでヴァリデータを書くときだなぁ。

ここで、TRUEが帰るのは、カスタムヴァリデータでのヴァリデーションに成功した。
FALSEは、同、失敗した。
だなぁ。

>>429
よくわかんないけど、自分がmojavi+Smarty+HTML_QuickForm+adodbでやってるヤツでは
こうなってるよ。
function validate(&$controller, &$request, &$user) {
    $form =& $request->getAttribute("form");
        return $form->validate();
}

だから、あなたの言ってることが正しいと思う。
＃ちなみに、一時的にvalidateをスルーさせたいときはreturn trueさせてまつ。

mojavi2で、あるモジュールから別のモジュールに$controller->foward()で飛ばすときに
元のアクションと、先のアクションが同じ名前だと、クラスを再定義した！errorをphpが吐いて
アボートするけど、仕様？

>>429
ほんとだ、変なこと書いてるね
正しくは「validate()でtrueを返すとexecute()、falseを返すとhandleError()を実行」

>>430
残念ながら仕様と思われ
上でも書いたがforward()ってば微妙に使えん
PHPにネームスペースがあればなぁ・・・

>>429
原文見てみたらその部分の記述がないね。
・原文は間違いに気づいて該当部分を削除したが、意訳はそのまま。
・単なる原文の意訳（著作権違反?）ではアレなので
　独自の見解を加筆して大失敗。
さて、どっちだろ。

>>432
＞正しくは「validate()でtrueを返すとexecute()、falseを返すとhandleError()を実行」
それもちょっと書き足らないかも。

ヴァリデータは２つある。
１つは、action::validate()
もう１つは、ValidatorManager（こっちが、action::registerValidators()で定義される奴）
でもって、両方ともTRUEを返したときにaction::execute()、以外はaction::handleError()

>>433
Mojavi2の古いヴァージョンじゃ、そういう仕組みだったんじゃなかろか。って思ったんだけどね。

昔は、実際にスイッチとして使ってた。
今は、常にヴァリデートしてる（ただし、デフォのヴァリデートルールが、なんでもOKになってる）

って感じかと思って書いたんだけどね。

>>434
書き手の方ですか。
２つあったとして、そのどちらも
＞これは「入力の検証を有効にする」というスイッチです。(もしvalidateメソッドを省略した場合はActionからFALSEで継承されます)
というのは間違ってませんか。
また、
＞Mojavi2の古いヴァージョンじゃ、そういう仕組みだったんじゃなかろか。って思ったんだけどね。
って想像で書いてどうすんの。

著作権に対する意見をお聴きしたのですがいかが。

PRADO 2.0出てるね
TContentPlaceHolderとTContentの組み合わせがかなり使いやすい

使える独自コンポーネントもいくつか出てきてて、コンポーネント指向の設計が
上手く生きてるなぁと思いますた

>>435
えーと、なんか勘違いされてます？
>>429 = >>434 です。

私が、推測したのは
mojavi2の仕様変更でもあったのではないか？
それに伴い、チュートリアルも書き直された。
が、日本語訳は変更前を元にしていた為昔のままの記述になった。（日本語訳の後に元が変更された）

みたいな事でもあったか？という程度の話です。

実際、今のmojavi2の実装とは、合わない記述なので、参考までに誤りを指摘しただけで、
別段、糾弾だのする気は毛頭ないですし（というか両サイトとも大いに参考にさせていただいてますし）

あと、wikiの方は、きちんと原作者に許可を得ている旨、書かれていたように思いますけど。

>>436
PRADOって重過ぎない？

Creole初めていぢった。
気に入った。
日本語解説してるとこ無いみたいなんで、つくります。
是非みんなもMojavi3 + Propel + Creole = Pure Heavenを体験してくれ

>>439
ADOdb＋Smartyでよくね？
っていうかPHP5だと仕事で使えないからｼｮﾝﾎﾞﾘなだけですが。

ｽﾏｿ。超適当な事言ってた。
モデリングツールなのか。

>>440
ADOdbだとわざわざ新しく作らなきゃいかんでしょ？
creoleはデフォで対応してる。
そしてPHP5が使える職場へ移動することをオススメします。

mojavi-all-classes.php
ってどこにいれてる？
漏れは/usr/local/lib/php/mojaviなんだが、
webappと同階層でもいい気がしてまつ。

>>443
好きにすればいい

別スレから誘導されました。マルチですみません。
php4.2.3,mojavi2を使ってデータ加工をするプログラムを作っているのですが、インスタンスの受け渡しが上手くいきません。
推移は A(aaction)->B(aview)->C(caction)->D(cview)
インスタンスをAからDまで持ち回したいのですが、B->Cへデータが渡りません。
状況は以下のとおりです。
A
$request->setAttribute('datalist', $datalist);
B
Bでは受け渡しは何もしていません。
print_r($request->getAttribute('datalist'));
は出力されます。
インスタンスのメソッドも実行可能でした。
C
$datalist = $request->getAttribute('datalist');
print_r($datalist);
出力されません。

何か、怪しいところ、解決のヒントをいただけないでしょうか。
よろしくお願いいたします。
（別スレで質問文をアドバイスいただいた方には感謝します。）

>>445
向こうでもレスしたが、頼むから最小限のコードを晒してくれ。
B(aview)->C(caction)に直接 $request の内容を渡すのは不可能（だったと思う）。

普通は（というか漏れのやり方では）、
A->B->A->C->D
という風にしてる。

とりあえず、BとCでそれぞれ別々にvar_dump($request)してみ。

>>446
レスありがとう。推移はB->Cですが、Bではこのデータについて何もしてません。
最小限のコードといわれてもどこまで書けばいいのか…改行が多すぎるといわれて蹴られたので
分けてアップします。
A.
class AAction extends Action {
//execute()が実行される動作は略
　function execute(&$controller, &$request, &$user)
　{
　　$datalist = new DataList()//クラス宣言等は省略
　　$request->setAttribute('datalist', $datalist);
　　return SUCCESS;
　}
}
B.
class AView extends View {
//特にdatalistについては何もしない
//Aの結果表示「完了しました」等の表示と次の処理をする「ボタン」の表示
//ボタンクリックでCへ
}

続きです。
C.
class CAction extends Action {
//execute()が実行される動作は略
　function execute(&$controller, &$request, &$user)
　{
　　$datalist = $request->getAttribute('datalist');
　　//$datalist は空。NGが表示される。
　　if (empty($datalist))
　　　print 'NG';
　　} else {
　　　print 'OK';
　　}
　　//念のため…
　　print_r($datalist);
　　//何も表示されない
　}
}
Ａのデータ処理->Ｂで結果表示と次への進行確認->Ｃで次のデータ処理->Ｄで結果表示
という流れでなんですがね。

var_dump($request)してみました。オブジェクトはＢでは存在しますが
Ｃでは存在しません。
Ａ->Ｃというのは、$controller->foword()でいいんでしょうか。
それだと$requestの内容を引き渡せるのでしょうか。

>>447-449
まず
× SUCCESS
○ VIEW_SUCCESS

> var_dump($request)してみました。オブジェクトはＢでは存在しますが
> Ｃでは存在しません。
当たり前。

> Ａ->Ｃというのは、$controller->foword()でいいんでしょうか。
その通り。

> それだと$requestの内容を引き渡せるのでしょうか。
多分いける。
漏れの場合、オブジェクトじゃなくて単なる数字とか文字列とかでやってたけど、確かいけた。
$datalistとやらが変化しないのであればいける。変化するのであれば無理。$_SESSION使え。

自信はないけどこんな感じでいいか？

自己レス。
最後のは嘘。
漏れの場合はformでhiddenしてRequest::getParameter()してた。

でも、$SESSION使うといけるのはホント。

>>451
A.
class AAction extends Action {
　function execute(&$controller, &$request, &$user)
　{
　　$datalist = new DataList()//クラス宣言等は省略
　　$_SESSION['datalist'] = $datalist;
　　return VIEW_SUCCESS;
　}
}
C.
class CAction extends Action {
//execute()が実行される動作は略
　function execute(&$controller, &$request, &$user)
　{
　　$datalist = $_SESSION['datalist'];
　　var_dump($datalist);
　}
}
で、
object(__PHP_Incomplete_Class)(2) { ["__PHP_Incomplete_Class_Name"]=>…
となってしまうのですが、session_start等はmojaviにやってもらってるので
どうしましょうか。

物ログって知ってる?
ブログ、ソーシャルネットワーキングに続く
次世代コミュニティーサービスのこと。
YOUTYでは無料でWEB上に自分のバーチャルな部屋を持って
書籍,CD,DVD,ゲーム等,趣味,生活に関する情報を
WEB上で公開する事ができるコミュニティーサービスのこと。
http://youty.jp/

>>452
session_start()の前にクラス定義を読み込んでおかないと
セッションでそのクラスをうまく渡せない
Mojaviのsession_start()はSessionContainerがload()されるタイミング（Controller::dispatch()内）
なので、その前にクラス定義を読み込むか、
インスタンスではなく必要なメンバ変数の中身をセッションに乗せるかすればいい
漏れは後者でやってるな

>>453
代表取締役の百田浩志さんは相当アホですねｗ

>>452

//AAction::execute()内
$datalist = new DataList()
$user->setAttribute( 'datalist', $datalist );


//CAction::execute()内
$datalist = $user->getAttribute( 'datealist' )

じゃダメ？

レスありがとうございます。解決しました。
>>454
最初は、デフォルトで添付されてるfilterを弄って動作させてて、(grepしました)
なんだかスマートさに書けるなぁと思っていたら、そんなことしなくてもよかったですね。
>>456
$userにもAttributeがあったのね（恥）。それでOKでした。
その方がmojaviらしいです。
正直、ViewからActionへAttributeは渡らないということについて
なぜソースソースと田舎の洋食屋のように言うのかわからなかったんですが
（渡ってない事実を質問してるのにvar_dumpさせるのもよくわからないんですけど）
こういうアドバイスにつながるんですね。
ありがとうございました。

>>457
よかったね。
でも、ソース晒すのは当たり前だよ。
100行の文章よりも10行のソースの方がわかりやすいからね。
ソース見た方が何してるかが一目瞭然だし。

mojaviでflexyを使うべく試行錯誤しています。

mojaviは各モジュールにテンプレートフォルダを持っています。またグローバルな
テンプレートフォルダも持っています。
flexyはinstance作成時に引数としてoptions(テンプレート、コンパイルフォルダ
の場所）を渡さなければなりません。

このような場合各モジュールにあるテンプレートフォルダを無視して
グローバルに統一したほうがflexyのラパークラスとしてすっきりしますか？

>>459
お好きなように。
自分がわかりやすい方法でやるのがいいんじゃないかな。

mojavi2って、ロガークラスで
E_USER_ERROR -> warning
E_USER_WARNING -> fatal
って逆になってるような気がするんだけど、なんか意味あんの？

mojaviテンプレート使用している場合のイメージはどうしていますか。
階層化されたサイトの場合
イメージは公開フォルダに入れないといけなくてパスの管理が面倒です。

index.phpから見えるようにすればいいだけだと思う。

>>462
階層化ってどういう意味でおっしゃられていますか？
ページコントローラモードを含む場合？
モジュール毎に画像ディレクトリやCSSディレクトリを変更したい場合は、
config.phpで定義されているWEB_MODULE_DIR定数をなんらかの形でテンプレー
ト変数に設定してやればいいと思います。

webapp/config.php:
/**
* An absolute web path where modules can store public information such as
* images and CSS documents.
*/
define('WEB_MODULE_DIR', '/modpub/');

階層化とはhtmlのフォルダ階層のことです。
例えば
/index
|
|/products/
|/info/

このような階層の場合products/層には製品の写真とか入ります。

>>465
申し訳ありませんが、意図が掴めません。

462の質問に回答するなら、Mojaviテンプレートを使用しようが、しまいが、
ディレクトリが階層化されていようが、いまいが、公開イメージファイルはド
キュメントルート以下に置きますし、非公開イメージファイルはドキュメント
ルート外に置きisSecure()がtrueなアクションから出力することになるでしょ
う。

パスの管理という意味ではSCRIPT_PATH環境変数やMojaviが提供する定数を駆
使してなんらかのテンプレート変数化を行えば良いと思います。

やっぱみんな mod_rewriteつかってるのか？

ところでPhrameってなんて読みますか？
ぴーふれいむ？

>>468
フレームって読む。
フレーズとかのスペル知ってる？phrase って書くでしょ

中学で習うよな・・・

GNOME や GNU があるからと思ったのかな

PHPによる自作のMVCモデルのフレームワークを考えているのですが、
モデルとビューを分けるメリットが分かりません。
コントローラーとその他を分けるのはとても分かりやすいのですが、
モデルとビューは密接に関わっているのでわざわざ分けてしまうと
面倒ではないですか？

メリットがわからないなら分けなければいいだけじゃねえの？

>>472
モデルとビューが密接に関わっている、って具体的にどういうこと？
例えば、モデルが保持している情報を出力する際にユーザーエージェントに応じて
HTML/XHTML/CHTMLのいずれかで出力する必要がある、という場合には普通モデルと
ビューを分けると思うんだけど。

>>472
＞モデルとビューは密接に関わっているので

はぁ？密接に関わるような作り方してんの？基礎からやりなおしたほうがいいよ。

>>475
お前はホントアホだな。
モデルとビューは密接に関わってんだろうが。
デザインとロジックの話じゃねーぞ？

475じゃないけどとりあえず具体的に書いてもらわきゃわからんな
モデルとビューを分離しないなら
似たようなビジネスロジックのコードを何度も書く事にならないかい？

つか、デザインとロジック分離するために、MVCフレームワーク使うんじゃないのか？
つか、MVを分離する利点がわからないのに、なんで、MVCフレームワーク作るんだ！とか思うわけ？

理解できない。

472はMVCが理解できてない、ということでFA?

>>472
モデル＝数値データだとすると、ビューは折れ線グラフ、棒グラフ、ヒストグラム、スプレッドシートなんかにできるわけです。
ビューとモデルが密接になっていると上のような「単一モデルに対して複数ビューを持つ」というのが作りにくくなります。
よって、きちんと分割してしまった方が良いのです。

>>476はまずオブジェクト指向の入門本でも読んだら？

>>476
やっぱりあなたは基礎から勉強するべきです。
テンプレートも含めて『View』ですよ？

自作フレームワークを作成中、同僚に手伝ってもらったときに、
ライブラリ用のディレクトリを置く場所について嘘をついてしまいました。
本当はhtdocs以下になくていいのに、なきゃいけないと嘘を教えてしまった
のですが、どうしたら気づかれずにhtdocsより上の階層に置き換えて
しらばっくれることができるでしょうか。

>>483
シンボリックリンクで外のフォルダとくっつけて、
ほ〜ら、コンテンツの維持が楽だよ〜と
ふんで Apache の設定でリンク不許可
こーすれば安心！

って違うよね・・

相手の立場で考えれば、
小細工されるより正しいやり方の指示を受け その上で謝罪もあれば尚良し、
だろうねぇ。
「だから最初にhtdocs以下じゃなくてもいいんじゃないの？って聞いたじゃん」
って言われる事くらい覚悟すれ。
つーか今でもその疑惑を持っていると思われ。早い方がいいよ。

>>483
あまりにしょうもない質問だな。
強いて言うなら「open_basedirの設定変えたから置けるようになったよ！」とか…。
しかしどのみち無知を晒す結果にしかならないだろうから、
素直に謝りなさい。

>>483
ワロタ　こういうのほのぼのしていいね。
丸く収まることを祈ります。

昨日からmojavi公式に繋がらないんだが
落ちてるのか

ｵｲﾗは繋がるよ。
ttp://69.61.21.69/ は？
Moving to a new server
April 11th, 2005
We're schedule to move to our new server tonight.
DNS will be updated tomorrow. While the DNS propogates, you may see an outage.
Have no fret, once your DNS cache is updated, all will be working well.
Outages may start occuring tomorrow.

>>489
ｻﾝｸｽ!
そっちは繋がったよ。
なるほど新しい鯖に引っ越したのね
まだwww.mojavi.orgは引けないけど
DNSキャッシュの更新待ちなのかな
田舎のISPだとこんなものか

mojaviでユーザの登録、編集、削除とかの一連の処理をするときって、
ユーザ登録Action、ユーザ編集Action、ユーザ削除Actionって別々でつくるのがいいのか、
ユーザActionつくってそのなかに登録、編集、削除メソッドつくるのがいいかどっちでしょう。
それとも別のいいやりかたありますか？

>>491
ケースバイケース。
大体は一枚でやってます。

>>491
私見ですが、

前者のメリット
o Mojaviの権限管理機構を使って機能毎に細かく制御可能。
o execute()内のケースがシンプルになる。

前者のデメリット
o そのままでは登録・編集のバリデーションコードが重複するためメンテナン
スしにくい。

後者のメリット
o 登録・編集のバリデーションコードが重複しないためメンテナンスしやすい。

後者のデメリット
o Mojaviの権限管理機構を登録・編集等の機能毎の制御に使えない。
o execute()内のケースが複雑になる。

といったところです。バリデーションコードを重複しないように工夫できれば
前者がお勧めです。

>>492>>493
ありがとうございます。

>後者のメリット
>o 登録・編集のバリデーションコードが重複しないためメンテナンスしやすい。
これに関してですが、後者の場合はデメリットになりえます。
削除処理でも登録、編集のバリデーションが発動してしまうので、M3なんかだと手の施しようがないんですよね…
権限については、hasCredentialなんかもあるので、それでやりくりは可能だと思います。
個人的には後者のメリットは、素人考えですがよりオブジェクトっぽくなるかなというところだと思ってます。

＞o execute()内のケースが複雑になる。
これも、登録、編集のクエリをそのままメソッド名に使っちゃえばいいのでそんなに複雑にはならないのではないでしょうか？

バリデーションの重複については、M2では共通の親Actionで継承できたのに、M3ではAction名のバリデーションファイル
を作らなければいけなくなったので、重複しちゃうんですよね。

複雑というか饒舌な感じになってしまいますが
登録/編集/削除フラグを立ててValidateメソッド内で条件分岐しております。

>>495
M2の話だよね？

http://fandc.co.jp/
↑エロゲサイトにまで使われるmojavi

http://ozaki.kyoichi.jp/mojavi3/quickform.html
↑
ここのひとって、

$form =& $request->getAttribute('form');

ってやってるけど、php5ってオブジェクトはデフォルトで参照渡しになるんじゃなかったっけ？
&いらないんじゃね？

>>497
そのサイトのどこにMojavi使われてるの？
まさか「majo2」がURLにあったからなんて言わないよね。

でもって釣られた俺、南無。

>>498
明示しちゃ駄目な訳でもなし。

>>499
ｸﾏｰだがあえて釣られてみる。

色んなコンテンツにアクセスしてみればすぐわかる。

>>499
はぁ？
エラー画面に思いっきりmojavi関連のものが出てるだろｗ

色々クリックしてみたけど、エラー画面なんて出ないな。

>>503
TOPからいける商品情報リンクでいきなりこんなんでますが？
Fatal error: Call to undefined function: setfetchmode() in /usr/local/share/pear/MDB/QueryTool/Query.php on line 325
Call Stack
#FunctionLocation
1{main}()/home/wwwchroot/www/htdocs/engine:0
2customcontroller->dispatch()/home/wwwchroot/www/htdocs/engine:136
3customcontroller->forward()/home/wwwchroot/www/lib/mojavi/mojavi-all-classes.php:412
4filterchain->execute()/home/wwwchroot/www/lib/mojavi/mojavi-all-classes.php:481
5outputbufferingfilter->execute()/home/wwwchroot/www/lib/mojavi/mojavi-all-classes.php:163
6filterchain->execute()/home/wwwchroot/www/webapp/lib/OutputBufferingFilter.class.php:14
7mappingrequestvarsfilter->execute()/home/wwwchroot/www/lib/mojavi/mojavi-all-classes.php:163
8filterchain->execute()/home/wwwchroot/www/webapp/lib/MappingRequestVarsFilter.class.php:21
9db_dataobjectfilter->execute()/home/wwwchroot/www/lib/mojavi/mojavi-all-classes.php:163
10filterchain->execute()/home/wwwchroot/www/webapp/opt/filters/DB_DataObjectFilter.class.php:22
11executionfilter->execute()/home/wwwchroot/www/lib/mojavi/mojavi-all-classes.php:163
12listaction->execute()/home/wwwchroot/www/lib/mojavi/mojavi-all-classes.php:97
13customquerytool->customquerytool()/home/wwwchroot/www/webapp/modules/catalog/actions/listAction.class.php:61
14customquerytool->setdbinstance()/home/wwwchroot/www/webapp/lib/CustomQueryTool.class.php:16

googleで探せば1番目に出てくるような内容を、メーリングリストで延々と質問するようなタイプの人がいる

499が
仕事中だからあちこちクリックできねーんだよニート共が！
みたいに逆切れするに100Mojavi

商品情報、普通にクリックして普通に表示されるんだが・・・

>>507
URL見るだけでもわかりそうなもんだが…

http://fandc.co.jp/engine/module/catalog/action/list/
↑ほら入ってみなさい

毎度思うんだが。

PEAR も Mojavi もいいけど、display_errors = off とか、まず最初に普通の事を普通にやろうぜ、と。

デバッグ中に　display_errors = off 　の何処が普通のことなんだか

アンチ・パターンかのぅ。

>>504 の事。
これに限らず、よく見かけるので。

>>512
ちなみに、あのサイトはデバッグ中というか試験公開中って書いてあるよ。

>>513
ごめん（;´Д`）全然見てなかった… 正直すまんかった。

>>510
いつまでがデバッグ中なんだか

>>515
そんなこともわかんないのか

Seasar2 for PHP5。
ttp://cgi39.plala.or.jp/klove/w/k.cgi?page=Seasar2%A4%F2%BB%B2%B9%CD%A4%CBphp%A4%C7DI%A5%B3%A5%F3%A5%C6%A5%CA%A4%F2%BC%C2%C1%F5%A4%B9%A4%EB

うちの会社はPHP4環境ですががががが。

Mojaviについてググっても出てこないので分かる人いたら教えてください。
認証していない状態で、isSecure(return TRUE)が設定されているモジュールを呼び出すと
AUTH_MODULE、AUTH_ACTIONで指定されたモジュールにフォワードされますが、そのモジュールで
認証後に元のページに戻るにはどうしたらいいのでしょうか？
複数の場所から認証モジュールにジャンプするので、戻る場所が１箇所ではありません。
引数のmoduleとactionから判断するのがいいのかな？

>>518
$controller->forward('originalModule','originalAction');
かな? Mojavi使ったこと無いけど、まるごとにあった。

From:
Mail: sage
----------------
>>518
次のようなフィルターを経由してRendererで設定し使っています。

class NextActionFilter extends Filter {
function execute(&$filterChain, &$controller, &$request, &$user) {
static $loaded;
if ($loaded === null) {
$loaded = true;
$nextModule = $request->getParameter('nextModule');
if ($nextModule === null) {
$nextModule = $controller->getRequestModule();
}
$nextAction = $request->getParameter('nextAction');
if ($nextAction === null) {
$nextAction = $controller->getRequestAction();
}
if ($nextModule === 'Default' && ($nextAction === 'Login' || $nextAction === 'Logout')) {
$nextModule = DEFAULT_MODULE;
$nextAction = DEFAULT_ACTION;
}
$request->setParameter('nextModule', $nextModule);
$request->setParameter('nextAction', $nextAction);
$filterChain->execute($controller, $request, $user);
} else {
$filterChain->execute($controller, $request, $user);
}
}
}

変になってすみません。続きです。

ここではフォワードされた場合( $loaded !=== null )にはスルーにしています。

例えば、Smartyテンプレートでは次のようにして使います。

{if $nextModule != "" && $nextAction != ""}
<input type="hidden" name="nextModule" value="{$nextModule|escape:"html"}">
<input type="hidden" name="nextAction" value="{$nextAction|escape:"html"}">
{/if}

まるごとのoriginalModuleとoriginalActionにnextModuleとnextActionで対応します。

以上、参考になれば。

たびたびすみません。

ここではフォワードされた場合( $loaded !=== null )にはスルーにしています。
!== の間違いです。

レスありがとうございます。

>>519
まるごとは私も持っています。
$controller->forward('originalModule','originalAction');
だと、index.php?module=originalModule&action=originalActionが
呼ばれるだけで元には戻れませんでした。
なので、まるごとで書かれているコメントは間違い(というより、
そこは自分で置き換えろということ)みたいです。

>>520
参考にさせて頂きました。
input type="hidden"の項目を置くのは認証モジュールのフォームで、
認証後にここにセットされているModuleとActionにフォワードする
ということでよろしいでしょうか？
やはり認証モジュール内で呼び出し元を保持して画面遷移しないと
無理っぽいですね。

>>518
それで問題ありません。

>>524
了解です！
素早い回答ありがとうございました。
本当に助かりました。

521のソースを参考に作ってみて無事にできました。
ただ、少し問題点もありました。
複数ある認証モジュールの呼び出し元の引数がそれぞれ異なる場合に
認証モジュール内でそれを全て引き継いでいかなかればいけないという
のが一つ。
もう一つは認証モジュールの呼び出し元がGETとPOSTでVIEWを切り替えて
いる場合で、<A>タグから呼び出し元がGETで呼ばれた後に認証モジュールに
ジャンプして認証画面でsubmitでログインして戻ってくるとPOSTで認証元
が呼ばれてしまうためVIEWの切替がうまくいきません。
なので、認証モジュールの呼び出し元はGETとPOSTで両方同じ処理にしておく
必要がありそうです。

俺はforwardじゃなくてredirect使ってる。

とりあえず、getで回せば？

$request->setMethod(REQ_GET);
$controller->forward( NEXT, NEXT);

getで回すのもスマートじゃない気もする。
ログイン画面に来た時にリファラを取得しておいて、
外部サイトからだったら、indexのページ、
内部からだったら、そのリファラに飛ばせば良いんじゃないの？

スマートさには欠けるかもしれんけど、次のようなのはどうですか？
1.認証モジュール内でgetMethodしてGETかPOSTかを取得してセッションに保存。
2.getParametersで引数をすべてセッションに保存。
3.ユーザ認証
4.ユーザ認証OKならセッションに保存した引数を全てsetParameterする。
5.上記1で取得したのがGETならredirect、POSTならforwardする。

実際に作ってないのでホントに動くか分かりませんがｗ

フレームワークはやっぱり自作に限りますな。
小回り聞くし、使い勝っても良いし。
ちなみに俺のフレームワークは↓ここのサイトのを
http://www.stackasterisk.jp/tech/php/phpMvc01_01.jsp
参考に作りました。

>>531
ぷ

>>531
実は俺も。
VOとかDAOの概念が役に立った

よっぽど小さいプロジェクトしかやったことないんだな

よっぽどプロジェクトやったことないんですね

ひとりで仕事したことしかないんだろ

>>533
DB_DataObjectやPropelとかのo/rマッパがあるのに今更DAOの概念て…
お前もう少しがんばった方がいいよ

お前よりはがんばってると思うよ

そういえばPropelって細かい解説サイト英語のみ？

>>537
そうか…
しかし別に職業プログラマじゃないしな

>540
とりあえずメンテナの一番多いだろうmojaviの大半の機能を使うくらいのプログラムを組んで
流通してるフレームワークの強さを体感したらいいよ。
一部しか使わないから覚えるのマンドクセ、自作マンセーになる。

>>538
自覚症状なしですか…もう救いようないですね。

まぁ>>540みたいなケースなら問題ないけど。

>>534-537
おいおいおい、mojavi信者が必死だなｗ
お前らみたいなフレームワークも自作できないような屑は
プログラマを語るなよ。な？

>>543
＞お前らみたいなフレームワークも自作できないような屑は

という事はお前さんは自作してるんだろうから公開してみたら？
それが出来ない限り、お前さんもフレームワーク自作できるとの証明にはならないから、
お前さんの理論でお前さん自信が『屑』である。

車輪の最発明とか、メンテナの数とか、イロイロありすぎて
フレームワーク自分で作る意味がわからんのだが。
教えてplz
つーかフレームワーク自作するやつは当然Pearなんて使わないんだよね？

>>545
既存のフレームワークで満足すればそれでよし。
満足しなくても、改造して満足できるならそれでよし。
それでも満足できないなら自作するのもよし。

ぶっちゃけ、フレームワーク使わなくたってどうでもいい。
使いたい奴が使いたいものを使う、または自作すればいい。

つうか、どうしてプログラマの大部分ってこういった話題好きなのかね・・・
使いたいものを使いたいように使えばいいじゃん。
もうちょっと、プログラミング自体を楽しもうぜ。

>545
趣味でやってるなら楽しもうぜ、とか言えるだろうが
仕事なんで効率と保守のコスト考えると、そんな理由では自作なんてありえない。
フレームワーク自体の有用性は揺ぎ無いわけだから
自作フレームワークのメンテに時間がさけて、なおかつ仕事も効率よくこなせるとなると
そこそこ大きいプロジェクトしか自作フレームワークなんて無理じゃないの？

547は546宛て。アンカーミスった

>>547
だから、全員が仕事で使ってるわけでもないし、逆に趣味でもやってる訳でもない。
だから、自作だからとか既存とかどうでもいいでしょ？って事。

少なくても、色々な人間が居る中で、自作だからといって見下した態度とたり、
既存のつかってたら信者だの煽ったりと、どうでもいい。

もっと単純に情報交換がしたいよ・・・
例えば、○○のフレームワークはこういった部分が面倒だから、
俺は既存の△△の部分を□□のように書き換えて☆☆のようにして使ってる。

とかさ・・・
なんというか、こういった板見てると、必ず○○使ってる奴はダメとか
そんな意見ばかりじゃん。

そういう意味でも、『楽しもう』と言っただけ。

あのさ、フレームワークの自作なんか大したことではないだろ？
何が車輪の再発明だよ。ただの骨組みだろうが。馬鹿か？
もう一度言うが、フレームワークの自作すらできないような奴が
プログラマを名乗るなよ。な？

と、フレームワークも作れない奴が語っております。

>>529さん
>ログイン画面に来た時にリファラを取得しておいて、
>外部サイトからだったら、indexのページ、
>内部からだったら、そのリファラに飛ばせば良いんじゃないの？

これって何でですか

>549
自作だから見下すわけではないが、既存のものより悪いものを作って自己満足しました、なら
チラシの裏にでも書いててくれよ。
それこそ自分が作ったって公開してるのなんてMapleほかいくつかくらいだろ？
評価しようがないよ。

>550
これほどまでウェブアプリが一般的になった現在でも
ＸＳＳ脆弱性やＳＱＬインジェクションのような単純ミスが残ってるのは
人の作業にミスが付き物だからだろ？
俺はメンテナが多いほうがそういうミスも減るだろうし
オープンソースならミス見つかるのも早いだろう、っていう考え方。

>>550の糞フレームワークマダー？

これで、>>550が物凄ぐ使いやすいFWだしてきたら、凄いだろうな・・・

>>555
今でもものすごく使いやすいフレームワークあるんだし、別に凄くはないと思う。

>>556
だから、今まで出てきたようなFWより使いやすいとかそういった意味だろ。

>>557
別にそんなこと>>555では書いてないだろ。

なんかフレームワークすら自作できない屑が多いのね。
程度低いな。

ぶっちゃけ自作できない奴なんてこのスレには居ないだろ。
やる価値が無いと判ってて放ってる奴と、作ってから既成でいいことに気づいた奴。
俺は後者。
煽りならもう少し程度を上げてくれよ？

既製品を超える品を作ってる/作ろうとしてる方々を馬鹿にしているわけではない。
今のフレームワークが完璧などと言うつもりは毛頭ない。
念のため。

俺は面倒くさがりだから手を加えるにしても１から作らずにメンテナに加わるだろうけど。

効率を考えない馬鹿が>>559みたいな結論に達するんだろうな

ぶっちゃけ、サイトを構成する手段として使ってるだけで、
基本さえわかれば、フレームワークそのものには大して興味ない。

ってのは、いけませんか？

>>562
簡単なアクセスカウンターから巨大プロジェクトまで
すべて同じフレームワークを使うんだな。
馬鹿の一つ覚えのように。程度低いねぇ。死ねば？

>>564
よく落ち着け。
＞簡単なアクセスカウンターから巨大プロジェクトまで
＞すべて同じフレームワークを使うんだな。
>>562のどこでそんなこと言っている？
冷静になって考えろ。そうすれば、取り乱してアホなレスしてる
自分が死ぬべきだと気付くはずだ。

>>565
フレームワークの自作もできないような低レベルな人間である
あんたが死ぬべきだと思うよ？

お前は病院病院行った方がいいね

かわいそう

>>566
＞フレームワークの自作もできないような低レベルな人間である
興奮しすぎだ。だれがどこで自作できないなんて言ったの？
それにお前の論法だと、
＞簡単なアクセスカウンターから巨大プロジェクトまで
＞すべて同じフレームワークを使うんだな。
アクセスカウンターにまでフレームワークの自作するの？ってことになるんだが…

＞「屑」「死ねば？」「死ぬべきだと思うよ」
なにがおまえの心を蝕んでいるんだ？
http://www.nisseikyo.or.jp/
とりあえずここで治療先探した方がいいよ。
なんか知り合いの職場で、突然発狂しだして、それから顔出さなくなった奴とか
いたらしいし。

おまいら、荒れすぎ （　´,_ゝ`）y-~~~

フレームワークを自作すると勉強にはなる。

で、俺がフレームワークを使う理由はテコの原理が働くから。
フレームワークの習得コストを投資するだけでその何倍ものリターン、即ちアイデアや技法を核に、コーディングやテストに時間や人をかけた良質のコードが利用できる。
なので俺がフレームワークを選定する判断基準は
1. 核となるアイデア、技法の価値
2. それがどの程度の品質でテスト、実装されているかの質
3. 情報
自作＆クローズドだと 2 と 3 が劣るので苦しくなる。
このスレが賑わったのも Mojavi のような強力なオープンソースフレームワークが評価されたからじゃないの。少なくともフレームワークの DIY で賑わってるワケではない。

自作はがんがんやれ。でも押しつけんな。
オープンソースフレームワークはがんがん使え。でも うひょー、俺進んでるー！とか使ってないヤツは吊れというのも間違い。

フレームワークで非生産的なフレームすんなと。

今、>>570がいいこと言った！

別にいいことじゃないだろ…

>>572
>>571 は
> フレームワークで .. フレーム
ここの事だろ。

>>573
いや、>>571は>>570だろ。

>>570
＞おまいら、荒れすぎ （　´,_ゝ`）y-~~~
荒れてるのは>>559だけだよ

以下、何事も無かったかのように。

ところで、いまだにM2-PHP4な俺様なんだが
M3-PHP5に移行するに当たっての注意点みたいのあるかい？
なんかiniファイルとかあって軽くビビってるんだけど。
DB接続周りはProple&Creoleがいいらしいね。

Hibernate誰かポートしてねえかなと思ってpHibernateでググったら出てきたよｗ

>>576
＞M3-PHP5に移行するに当たっての注意点みたいのあるかい？
言い出したらキリが無いな…

Propel&Creoleに限らず複数＆多種のDB接続ができるんで、DB周り自体かなり便利にはなってるけどね。
俺の場合比較的速度を求めない部分ではPropel+Creoleで、速度重視の部分ではADODBって感じでやってるけど。

所詮はCGIだろ、そんなに熱く語るものでもないだろが。
使えて当り前のレベルの話だろが、突っ込んだ話しても
先が見えてる内容だから、掘り下げて話す方が恥ずかしくなるよ(w

>>578
＞所詮はCGIだろ
え…？CGIじゃないよ？
せめて最低限の知識持ってから書き込まないと恥ずかしいよ？

578ではないが、
PHPはCGIとしてもインストールできるのですよ。
ただ、あまり一般的じゃないけど。

>>580
＞PHPはCGIとしてもインストールできるのですよ。
この表現は正しくない。

CGIとしても動くけど、誰もそんな風に使わないよね。
誰もCGIについて語ってないし。苦し紛れに無知な>>559が
発したレスなんだろうけどね。

DBを使うような事って、仕事以外に無いだろ。

>>583
えぇぇぇ。
さぶっ！

>>581
じゃぁ正しい表現を教えてね。
もっと建設的に行きましょ。

>585
調べろ。だからお前は屑なんだ。

そもそも最初から知ったかぶるな。

藻前ら税印しんじゃえ
うぜ

結局PHPにおけるフレームワークはMojaviが定番と考えて良い？

そろそろPHPフレームワークの本出してほしいよな〜
でも既存フレームワークは
「多機能すぎる」んで、速度がネックになるかな。
オリジナルフレームワークは機能のｼｮﾎﾞさが
逆に強みになると思う

>>589
既存フレームワークで本必要？
ソースコードの量も大した事無いし、別に本が必要とは思わないんだけど？

それと、たしかもうちょっとでMojavi3を扱った日本で最初の書籍が出るはず。

いちいちソース読むのは面倒
楽したいからフレームワーク使うんだからさ
ﾓﾊﾋﾞ本には期待

mojaviはステップそれほど多くないし
ソースがきれいだからすぐ読める希ガス

別にソース読まなくても公式のマニュアルとフォーラムの記事検索すりゃ
いくらでも出てくるし。

>>586
そんなこと言うんだったら
最初からPHPはCGIではないなんて言うなよ。

おまえが問題にしたのは文章の正確さではなく
その「表現」なんだから、マニュアルを調べたって出てきそうもないしな。
正確な文章を書けないやつがしゃしゃり出てくるんじゃない。

>594
俺は多分お前が思ってる奴とは別人だぞ。
日が浅いだろうに、奈々氏の区別が付いている振りをするものじゃない。

一般的に教えてｸｿと呼ばれるものは屑だし
585もその類の遠吠えにしか見えない、ということを言ったまでだ。

ちなみに、さっき詳細な用語はさっき3分ほどで調べてみたんだが
CLI版のPHPをインストールすることで、CGI機能を実装したサーバーの
cgiスクリプトとしてPHP言語が動作可能となる。
つまり、581が言ってるのはCGiとしてインストール、というのがそもそもおかしい話だということだろ多分。
調べたら出てくるんだから調べてから話せ、ってことだ糞餓鬼。

>>596の言うとおり。

>>596
正確にはCLI版はCGI Spec.を満たしていないので、CGI版じゃないと駄目。

とりあえずスレ違いなんでCGI厨は消えてください。

と思ったが、CLIでもCGI Spec.を満たしたスクリプトは書けるな。
前に何か足らなくなってて難しい/出来ないと思ったんだが...記憶違いか

>598
ttp://ns1.php.gr.jp/pipermail/php-users/2003-January/012701.html
これか。おみそれした。

>>600>>601
秒数まで同じなんてお前ら…

>>601
そのHTTPヘッダのくだりなんだけど、出力しないだけで
CGIのインターフェース的には繋がってたと思うんだよね。

ああ、スレに関係ない話ですまん。

ｹｺｰﾝするか？>>586
つか秒が同じになるのってどういう条件なんだ？

>>596
http://www.php.net/manual/ja/security.cgi-bin.php
じゃぁこの翻訳は間違っているのだね。

>605
わざわざ「バイナリ」と付けている意味もわからんのか。そもそも異なる訳だ。
つーか俺が書いたのは調べてる例なのだし、明らかに間違ってるなら自信を持ってその箇所を指摘しろ。
そういう中途半端な話がしたいのか？
580はともかく、578は明らかに事実誤認だし581は調べもせずに書き込む香具師だ。
勝手に誰かと勘違いしないでもらえる？

>598
ヘッダ自分で書かなきゃいけないならスクリプト書き直し…
秒はこれコンマ以下切捨てなのね。

レス番ミスった…
＞580はともかく、578は明らかに事実誤認だし581は調べもせずに書き込む香具師だ。
580はともかく、578は明らかに事実誤認だし585は調べもせずに書き込む香具師だ。

どんどんスレの主旨からずれてくな…これ以上PHP-CGIの質問するんだったらPHP初心者板でお願い。
一両日中には相手してあげるから。

>>590
どこの情報？

>609
これのことだと思う
ttp://www.amazon.co.jp/exec/obidos/ASIN/4798108766/250-2538785-1872250

1章 PHPプログラミングをはじめよう！
○PHPで広がるWeb開発
○レンタルサーバーでPHPを使おう！
○WindowsでPHPを使おう！
○使える！ アプリケーション〜一般編〜（XOOPS / ppBlog）
○使える！ アプリケーション〜開発編〜（phpMyAdmin / mantis）
○PHP超入門
○TruStudioで快適な開発環境を作ろう！

第2章 PHPのプログラム構築手法
○Smarty入門
○Smartyを使いこなす
○PHP5＋MojaviによるMVC入門
○PukiWikiでSEOにチャレンジ

第3章 ライブラリを活用する
○JpGraphでグラフもすいすい
○PEAR:Mime_Mailを使用したHTMLメール送信
○PHPのセキュリティ対策
○パフォーマンス向上大作戦！
○WYSIWYGな編集をしよう！

第4章 最新情報
○PHP5の新機能
○PHP4とPHP5の共存

↑これみるかぎり期待できなさげな気がする

まず581で「表現」が正しくないと言われたので、
「言っていること」は正しいが「言い方」が正しくないのだろう
と思って585と聞いたわけだ。
ただ表現が正しくないと言われてもどこが正しくないのかよく分からなかったしな。

それを586でいきなり屑呼ばわりされたので、
ついカッとなって594で複数人の名無しを一人だと勘違いした書き込みをしてしまった。
そこは悪かった。
ただ、見ず知らずの他人を屑だの糞餓鬼だの呼ぶのはどうかと思う。
少なくとも自分はそういう言い方はしなかったし、するつもりもない。

あと、自分も「明らかに間違っている点」を指摘されてないし、
「表現が正しくない」と言うのは「事実ではない」とは意味が違うので、
まだ釈然としないのだ。

でも、こんな言葉のあやみたいなことでグチグチ言ってもしょうがないな。
またROMに戻る。
すまなかった。

別スレで教えて君を、このスレで煽りがスレ流すのをみてイラついてた影響が出てるな。
俺も悪かった。すまん。
ただ、匿名掲示板は煽ったら煽り帰される、というのはもう少し慣れておいたほうがいいよ。
いちいち煽られて腹立ててても仕方が無い。
結果として俺がスレ流しまくって無為になってるし、教えて君や煽り荒らしも次からはなるだけスルーするよ。

>>610
見るべきは
> 坂井 恵 (著), 上鍵 忠志 (著), 田中 正裕 (著), 月宮 紀柳 (著), 森川 穣 (著)

ここ。
業界一ネタがマニアックな月宮氏の名前がある。
上鍵氏と田中氏の名前は分かるが後は知らないな… 坂井氏って、Pukiwiki の坂井氏かな。

まぁどっちにしろ、PHP で本や雑誌一冊使うと部数を作るために初心者フレンドリーな振りにしなければ成り立たないんじゃないか。
ここの住人が満足するようなインデックスで固めたら大量の返本は確実。
それ含めて眺めたら、結構期待していいと俺は思うが。

>>609
表紙にMojaviとでかでかと書いてるわりに
割いてる章が少ない気がするな

>>614
そうそう。つーかほとんどがmojaviに関係ないのにタイトルでMojaviとか言って騙してる方が
返本確実だろｗ

確かにソレはなぁ… ('A` まぁ量より密度に期待しようや…

つううか、Mojaviの何についてが何が知りたいのだろう？
サンプルやチュートリアルで使い方はほぼ網羅されていいる。

あとは、更に効率良く使うために自分でクラス作ったりって感じだけど、
何が疑問なんだろう・・・

そして、こういった板があるんだから、ちょっとした疑問でも質問すれば良いのに。
でもって、質疑応答をどこかのサイトにまとめればそれだけで貴重な情報源になる気がする。

>>617
突然なに言い出してるんだこいつは？

>>617
まぁそこまで考える段階では無い気もする。今は取り敢えず記事出して認知上げようぜ、みたいな。

本当に需要が出てきたら切り口は幾つか見つかるんじゃない？

1. 事例紹介
2. Mojavi で作ろう -Mojavi を解説しつつアプリケーション一つをまるまる開発- (初心者向け)
3. Tips
　-- View を拡張
　-- エラーハンドリング
　-- Model の導入
　-- Propel でゴー
4. コードリーディングの手引き -Mojavi コードのガイダンスと読むべきポイント-
5. Mojavi に役立つツール群 (アクセラレータとか)
6. 情報源

こんな所か？ Tips にはエラい人がごまんと抱え込んでいるであろう技や活用術を載せて欲しいな。

そろそろフレームのすれから独立しようぜ。

Smartyのキャッシュ機能実装法が結構悩みどころなんだよなぁ

つーか、お前らフレームワーク一つ作れやしないくせに
フレームワークを知った風な顔で語るなよ。雑魚どもが。

俺もそれで悩んだ
結局smartyのインスタンスをfilter側で生成して
actionクラスでもインスタンスを呼び出せるようにしてる。
それでis_cachedメソッドでキャッシュの有無を判定して
DB処理等の実行の判断をしてるんだけど、もっと良い方法あったらｷﾎﾞﾝﾇ
ちなみにmojavi3でのお話

>>623
俺も似たような感じ。
まずConfigクラス作って、smarty_アクション名.iniに、グローバルテンプレ、メインテンプレ、スロットテンプレの
ファイル名、キャッシュ時間を設定して、それをフィルタで読み込んで判定してる。
んで、キャッシュされてなかったらView側で表示＆キャッシュ生成処理みたいな感じで。

まぁでもそのうち公式でサポートされそうな気がしなくもないけど。

mojavi2の認証機能・承認機能のネームスペースって何ですか。権限名は勝手に
名づけてよさそうに思えるのですが、ネームスペースというのが何なのかわかりません。
どなたか教えてもらえないでしょうか。
addPrivilege()と一致していれば何と名づけようと関係ないのでしょうか。

<?php
class AAction extends Action
{
　//認証機能を利用する
　function isSecure()
　{
　　return true;
　}
　//ExecuteExampleは権限名として自由につけらる?
　//いくつかの解説で出てくるExampleNamespaceというのは何でしょうか?
　//突然、今まで出てこなかったExampleNamespaceとか、$GLOBALS['_EXAMPLE_USER_PRIVILEGE_NAMESPACE']とか
　//tutorialとかになってて混乱してます。
　function getPrivilege()
　{
　　return array('ExecuteExample', 'ExampleNamespace');
　}
?>

>>625
勝手に名づけていいよ。空にするとたしかmojavi.orgかなんかが入るんだっけ？

でも、例えばネームスペースにホスト名やユーザエージェントとかの
ユーザごとに違う値を入れてやれば、セッションハイジャック対策になる。

>>626
さんくす
えっと、ユーザエージェント毎の違う値というのが思っていたのと違うんだけど
それはテストコード書いて試してみます。
・・・そのネームスペース（？）毎に権限設定ができると思ってた。
例えば、userはuserでの権限でできること、adminはuserとadminと両方の
権限を持ってアクセスできるとか・・・。できるのかなぁ。

>>627
そういうのは権限の付与時にきめることで、そこは関係ない。
例えば>>625での
AAactionにadminだけをアクセスさせたい場合、
認証時にadminだけ、ExecuteExampleをaddPrivilegeしてやればいい。

>>628
そういった意味じゃないんじゃない？

adminとかuserって例だと俺は例え難いから別な例えとすると、

ある画面は営業部と品質管理部がアクセス出来るようにするといった場合じゃないのか？
つまり、複数の権限でアクセスできるページが作りたいって意味じゃ？

>>629
だから、そのロジックを認証時に書けといってるんだが。

例えば
AAction、BActionがあったとしよう。
AActionにExecuteExampleA、BActionにExecuteExampleBをgetPrivilegeしておく。
認証時、adminユーザExecuteExampleA、ExecuteExampleBを付与、
userならExecuteExampleAを付与してやればいい。
AAction内でさらに細かく設定したければhasPrivilegeで直接問い合わせる。
if($user->hasPrivilege('ExecuteExampleA-1')){
ExecuteExampleA-1が与えられたユーザだけの処理
}

つまり、権限は複数つけることが出来るって事でOK？

>>632
お前の言ってることは曖昧すぎだ馬鹿

ていうかソースの該当部分みりゃわかる話しだろ…

>625=>629=>632
自演乙

>>634
せめてポインタ示せ。どのファイルの何行目あたりとかさ。
できなきゃ黙ってろ。使えねぇヤツ。

>>636
使えない奴というのは、何も出来ない君のこと

>>636
PHPEclipseやTrustudioでも使えばすぐ見つかるだろ…
そんなこともできんのか

>>638
ZendStudioしか持っていません。
どうにかなりますか？

>>639
PHPEclipseもTrustudioもフリー
持ってなきゃ落とせ。

>>626
これは飛び道具的な使い方。本来ネームスペースというからには、
return array('ExecuteExample', 'ExampleA');
return array('ExecuteExample', 'ExampleB');
みたいな使い方をするもんだ。

>>639
宝の持ち腐れ。どうにかなるよ

>>640
その飛び道具的な使い方をもう少し具体的に！！

ソースと格闘していたｵｲﾗがやってきましたよっと。
参考にできるドキュメントがあんまりないのがmojaviの辛いところだね。
間違っている部分があれば指摘よろ。

[ユーザ認証を使う場合]
　index.phpの
　　require_once(AUTH_DIR . 'PrivilegeAuthorizationHandler.class.php');
　　$authHandler =& new PrivilegeAuthorizationHandler;
　　$controller->setAuthorizationHandler($authHandler);
　を有効化する
　認証したいActionに、function isSecure(){ return TRUE; } を追加する

　認証済みにする時は、User::setAuthenticated(TRUE); を実行する

[ユーザ特権を使う場合]
　index.phpの
　　require_once(AUTH_DIR . 'PrivilegeAuthorizationHandler.class.php');
　　require_once(USER_DIR . 'PrivilegeUser.class.php');
　　$authHandler =& new PrivilegeAuthorizationHandler;
　　$user =& new PrivilegeUser; -(3)
　　$controller->setAuthorizationHandler($authHandler);
　　$controller->setUser($user);
　を有効化する
　特権を扱いたいActionに、function isSecure(){ return TRUE; }を追加する
　Actionに特権を設定する
　　function getPrivilege (&$controller, &$request, &$user){
　　　return array(name,namespace);
　　}

　User::addPrivilege(name,namespace)を使って、そのユーザの持つ特権(s)を設定する

[捕捉]
あるActionに必要な特権は1つだけ設定できる(getPrivilege)。namespaceを指定しない場合はorg.mojaviになる。
あるユーザの持つ特権はPrivilegeUserクラス内で、secure[namespace][name] = TRUE|NULL の形で格納される。
またUser::addPrivilegeを複数回使うことで、複数の特権をユーザに付加することができる。
nameとnamespace(省略時はorg.mojavi)の2つが完全に一致しないと、特権が許可されない。
アカウント管理のグループ・ユーザのような「ものではない」つーことやね。ここ引っ掛け問題で出ます。

>>644の書き込み見ると、今までの流れで言われてた事と
矛盾するんだが、どっちが正しいの？

>>645
まぁここでわかるわけだ。能無しソース嫁厨←実は読んでないと
ほんとに読んだ人と。例え644が間違っていたとしても
こう書いてあるから違うといえる人間と違うとしかいえない人間と。
あ、俺は読んでないからなんともいえない。先人の知恵をありがたく使わせて
いただく。感謝の気持ちはあるつもり。クソにもならんコメントという意味では
俺も嫁厨と変わらない…。

>>646
＞俺も嫁厨と変わらない…。
変わらなくない。それ以下。

>>645
＞>>644の書き込み見ると、今までの流れで言われてた事と
＞矛盾するんだが、どっちが正しいの？
べつに何も矛盾しない。

>>644
＞アカウント管理のグループ・ユーザのような「ものではない」つーことやね。ここ引っ掛け問題で出ます。
これは具体的にどういう意味で言ってるの？
namespace・nameがイコールグループ・ユーザというものではないって意味？
それともグループ・ユーザに相当する処理で使うものでは無いという意味？
後者なら違うと思うんだが。実際グループの権限照会処理で俺使ってるんで。

>>647
>>648
あんたアホです。
いいかげん結論だけいってそれでよしと主張するのやめませんか。

またまたｵｲﾗがきましたよっと。
>>645
矛盾はしないですよ。というか、矛盾していたらネチネチと煽ってるっす。
>>649
最後の一行は余計だったかなぁ。。その上の行の捕捉みたいなつもりだったのだけど。
namespace = グループとした時に、グループに対してactionの利用がon|offされるわけではなく、
あくまでnameまで含めた物が判定に使われるってことです。
上の方で出ていた単語(そのレスでの意味合いは置いておいて)を使うと、
namespace = adminグループ、営業部 って感じ。
グループ・ユーザ機能をどう実装するかってのはまた別の話っす。

>>650
>>648はそれ以上なにを言えばいいんだ？
お前は少しは頭働かせろよ

>>651
＞最後の一行は余計だったかなぁ。。その上の行の捕捉みたいなつもりだったのだけど。
別に真意を知りたかっただけ。特に余計とかは思ってない。
namespaceはユーザのグループというよりは、権限のカテゴリと考えるのが妥当だね。

眠れぬ夜を過ごすｵｲﾗがまたまたきましたよっと。
認証・特権に関係する部分を読んでいた時のメモっす。@mojavi2
追試しようとする人は参考にしてちょ。
mojavi全体の処理ダイアグラムも参照。
ttp://www.mojavi.org/images/diagrams/2.0/action_sequence.png

段組は関数呼び出し・if文等処理の区切り。関数名の後ろの::はその関数のクラス名。
index.php
require_once(AUTH_DIR . 'PrivilegeAuthorizationHandler.class.php'); -(1)
require_once(USER_DIR . 'PrivilegeUser.class.php'); -(2)
$authHandler =& new PrivilegeAuthorizationHandler;
$user =& new PrivilegeUser; -(3)
$controller->setAuthorizationHandler($authHandler);
$controller->setUser($user);
$controller->dispatch()

mojavi-all-classes.php
function dispatch()
　$this->forward($modName, $actName);
function forward($modName, $actName)
　$filterChain =& new FilterChain;
　$filterChain->register(new ExecutionFilter);
　$filterChain->execute($this, $this->request, $this->user);
function execute(&$filterChain, &$controller, &$request, &$user)::ExecutionFilter
　if($action->isSecure()) -(4)
　　$authHandler =& $controller->getAuthorizationHandler();
　　$authHandler->execute($controller, $request, $user, $action)
function execute (&$controller, &$request, &$user, &$action)::PrivilegeAuthorizationHander
　if(!$user->isAuthenticated()) -(5)
　　$controller->forward(AUTH_MODULE, AUTH_ACTION);
　$privilege = $action->getPrivilege($controller, $request, $user); -(6)
　if ($privilege != NULL && !isset($privilege[1])){ $privilege[] = 'org.mojavi'; } -(7)
　if ($privilege != NULL && !$user->hasPrivilege($privilege[0], $privilege[1])){ return FALSE; } -(8)
　return TRUE; -(9)

(1) ユーザ認証を使う場合は、index.phpのコメントアウトから有効化
(2) ユーザ特権を使う場合は、index.phpのコメントアウトから有効化
(3) Userクラスの代わりにPrivilegeUserクラスを使う。opt/user/PrivilegeUser.class.php
(4) Action内でisSecure()がtrueを返すようにオーバーライドしておくと、認証/権限が実行される。オーバーライド前は、return FALSE。(9)も参照。
(5) User::setAuthenticated(true)されていれば認証済み。(9)も参照。
(6) Action内でgetPrivilegeが特権名/名前空間の配列を返すようにオーバーライドしておく。オーバーライド前はreturn NULL。(9)も参照。
(7) 名前空間が設定されていない場合は、org.mojaviと名前空間に使う。
(8) User::addPrivilege(name,namespace)したものの中に、(6)の特権名/名前空間を満たすものが無ければ、特権無しと判断する
(9) 認証が成功した場合や、特権有りまたは特権不要の場合に、trueを返す

mojavi + smarty を使っているのですが、
動的にXMLを作成しようとすると、1行目に改行が入ってしまいます。

以下view
$renderer->setTemplate('recentXml.xml');
$renderer->setAttribute('result' , $request->getAttribute('result') );

以下template
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<data>
<result>{$result}</result>
</data>

以下compileの中身
<?php /* Smarty version 2.6.9, created on 2005-06-14 05:18:37
compiled from recentXml.xml */ ?>
<?php echo '<?xml'; ?>
version="1.0" encoding="UTF-8" standalone="yes"<?php echo '?>'; ?>
<data>
<result><?php echo $this->_tpl_vars['result']; ?>
</result>
</data>

以下アクセスした結果

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<data>
<result>1</result>
</data>
<!-- Page was processed in 0.0412 seconds -->

この1行目の改行をなくすためにはどうすればよろしいでしょうか？

俺のsmartyだと入らないから、君のソースコードのどっかで
?>

とかになってるんじゃないのかな多分。

今気づきましたが、特定のモジュール内の全てのファイルに
ブラウザでアクセスした際、1行目に改行が入っていました。
原因はわかりません。

>>660
だから >>659 なんでしょ。PHPタグ閉じた後に改行が付いてる

UTF-8のファイルにBOMが入ってるんでは？

フィルターって何に使えばいいの？と悩むｵｲﾗがやってきましたよっと。
検索してもGlobalフィルタのおざなりな説明しかないなぁ。。

フィルターには2種類あり、全てのmodule/actionで呼び出されるもの(globalフィルタ)と
特定のモジュールで呼び出されるもの(moduleフィルタ)からなる。

個々のフィルタには前処理・後処理という2段階の実行順序があり、
登録した順に前処理が全て実行されてから、今度は逆順に後処理が実行される。
Actionの実行部分もフィルタの一種として扱われていて(ExecutionFilter)、
全てのフィルタの登録後に自動的に登録されている。
結果、登録順に1,2...の番号を付けた時に、
1. GlobalFilterのpre-filter1,pre-filter2...を実行
2. moduleFilterのpre-filter1,pre-filter2...を実行
3. ExecutionFilterを実行(認証や特権の判定、action処理)
4. moduleFilterの...post-filter2,post-filter1を実行
5. GlobalFilterの...post-filter2,post-filter1を実行
という順番で処理されることになる。

フィルタ機能の実現には3つのクラスが関係していて、
FilterChain - フィルタを実際に行う仕組み
FilterList - フィルタの順序リスト
Filter - 実際の処理内容
このうち、FilterList、Filterを書くことになる。

以下、実際に使う時にどう書けばいいかの説明。

グローバルフィルタ
BASE_DIR/GlobalFilterList.class.phpを作成

BASE_DIR/GlobalFilterList.class.php
class GlobalFilterList extends FilterList{
　function registerFilters(&$filterChain,&$controller,&$request,&$user){
　　require_once(<filter-file-path>); // 利用するfilter分だけ繰り返し
　　$filterChain->register(new <filter名>); // 利用するfilter分だけ繰り返し
　}
}

モジュールフィルタ
BASE_DIR/modules/<module名>/<module名>FilterList.class.phpを作成

<module名>FilterList.class.php
class <module名>Filterlist extends FilterList{
　function registerFilters(&$filterChain,&$controller,&$request,&$user){
　　require_once(<filter-file-path>); // 利用するfilter分だけ繰り返し
　　$filterChain->register(new <filter名>); // 利用するfilter分だけ繰り返し
　}
}

フィルタ
<Global|module名>FilterList.class.phpの中でrequire_onceする時にパスを書くので、
そのパスと合ってさえいれば適当な場所でよい。

<filter>.class.php
class <filter名> extends Filter{
　function execute(&$filterChain,&$controller,&$request,&$user){
　　static $loaded;
　　// ActionChainやAction::forwardを使った時にフィルタが複数回適用されるのを防ぐ
　　if($loaded == NULL){
　　　$loaded = TRUE;
　　　// 前処理フィルタ
　　　...
　　　// filter chain の次のフィルタを実行
　　　// pre-filterとpost-filterの分岐点
　　　$filterChain->execute($controller,$request,$user);
　　　// 後処理フィルタ
　　　...
　　}else{
　　　$filterChain->execute($controller,$request,$user);
}}}

[捕捉]
上の <Global|module名>FilterListは FilterListのregisterFiltersをオーバーライドして
Filterの読み込みと登録をしているが、コンストラクタで読み込む方法もありっぽい。
その場合は、
class <Global|module名>FilterList extends FilterList{
　function & FilterList(){
　　require_once(<filter-file-path>); // 必要な分だけ
　　$this->filters[] = new <filter名>; // 必要な分だけ
}}
となる。元のregisterFiltersは$this->filtersをカウントしてregisterしてくれる。

mojavi公式サイト落ちてね？

ドライブ失敗の、少なくとももう1日間、mojavi.orgはためでしょう。
by ショーン・カー

>664
やって来なくていい。

ﾓｼﾞｬﾋﾞﾝｻｲﾄ落ちてるなー
>>667
ドライブ失敗って何？

>>669
ハードディスクがぶっ壊れた

>>664
俺は見ている、役立っている。わかんないヤツがgoogleで検索して
みにくるトキもあると思う。
へこまずに気がむいたらまた来てくれよな。
いろんな意見があることに甘えるやつもいるだろう。
俺はあんなこと言われたらヘコミまくるからさ。じゃね。

つうか公式のforumにしっかり書いてあるけどな。
今落ちてるけど

ﾓｼﾞｬ早く復活しないかなぁ
つかミラーもねーのかよ
ダウンロードしたいのに〜

なんかもじゃもじゃしてきた

もしかしてこのままmojavi終了なんじゃないだろうか？

たかがHDDクラッシュでこのていたらく…
こんなレベルの管理しかされていないものを組み込むのは
結構リスキーなんじゃないかと思えて来た…

Sleipnirみたいにソースがなくなってたりして。

>>676
オープンソースにリスクも糞もないだろｗ
使うなら一通り中身チェックするだろうし

なにか事件に巻き込まれたのでは。

最近まれにみる落ちっぱなしだな

復活！

既存フレームワーク使うことで
節約できるリソースってざっくばらんに言って何％くらい？

復活したんでダウンロードしてみたけど
Mojavi3の資料すくねー！
「極めるPHP」は本当に「さわり」だけだし
ネット渉猟しても2用だったりで
全体像が見えるチュートリアルが見あたらない。
日本でMojavi使ってる奴って100人くらいじゃないかと思えてくるよ。
楽をしたいのに、楽をするための苦労がやけに多い…

俺のまわりでもMojavi3を使ってる人は実際少ない。

ほとんどが実験レベルなので､情報も外に出さないし｡

http://mojavi.p0t.jp/
ﾓｼﾞｬﾋﾞｼﾞｬﾊﾟﾝ発見！
しかし3の資料はほとんどない
興味ある人は多そうなのに資料がやけに少ない
ﾈｯﾄ時代にふさわしくないこの状況はいかに。

>>683-685
実際の話、PHP5って普及してるの?
先行して一儲けをたくらむ輩（出版社とか）がお盛んなだけな気がするんですが。

最近majaviのMLもできたよ。
mojavi-users
ttp://ethna.jp/mailman/listinfo/mojavi-users

>>684
＞ほとんどが実験レベルなので､情報も外に出さないし｡
いやいやほとんど実用レベルだから…

>>686
まぁ、"普及している"とは到底思えない。

しかたねーからソース読み始めた
読みやすいコードだけど
クラスの数が多いな…

>688
すまん俺が言ったのはPHP5やMojavi3のことではなくて､
実験的に使ってみているだけだから､という意味｡

>>691の周りが実験でって意味ね。
でもなんでそれが情報を外に出さない理由になんの？？

691じゃないけど
実験的な、確定的でない情報は
なかなか外に出しにくいのはごく自然なことだと思うが…。

>>693
実験内容の公開は有効なことだと思うが…。

有効かもしれんがそれが目的ではないなら、
わざわざリソース投じてまで公開しようとはあまり思わないだろう。

>>695
＞わざわざリソース投じてまで公開しようとはあまり思わないだろう。
そりゃ単にお前の価値観なだけじゃん。

あのね。
目的があるから実験するわけよ。
目の前にやることがあるのに、成果が定かでない目的外作業に
エネルギーを向けたりはなかなかしないんだよ、
ぼくちゃん。

主語が足りねーな。「俺たちは」を付けろよｵｯｻﾝ。

共有のイデオロギー持ってるって言う幻想もってる世代だから。

俺もオッサンに同意だがｗ

Mojaviについて、
WaWaWaに採用が決まったので今後期待できそう、みたいな文章をどこかで読んだが
WaWaWa自体がぱっとしないよな。

ぱっとする為には何が必要か

人気じゃね？

http://mojavi.try-angle.biz/wiki/index.php?Mojavi%A5%C1%A5%E5%A1%BC%A5%C8%A5%EA%A5%A2%A5%EB1
ここのチュートリアル見ながらﾓｼﾞｬ3を見て行ってるんだけど
ﾓｼﾞｬってActionからViewへのデータコンテナは
Requestを使うのが普通なん？
Request＝Post/Getのコンテナという感覚なので
若干違和感を感じたんだけども。

getErrorメソッドも実装されてるし
標準で各層間のデータコンテナとして使ってるんやね

ﾓｼﾞｬ3、ChoiseValidatorがなくなってるじゃん。
なんでだろ？

ﾓｼﾞｬ3ユーザ多いのか？

とゆうことはみんなphp5なのか？

今からやる新ｻｰﾋﾞｽを4で作りだそうとは思わないな。

fetiがフォーラムで「M3は仕様変更もありえるし、stableになるには時間かかるからM2で開発しとけ」って言ってたな。
設定ファイル関連の仕様が変わるっぽい。「iniわかりづれーし、xmlパーサーおせえから独自のにする」とかなんとか。

>>708
マジかよ！
まあでも独自フレームワークにするかMojaviにするか迷ってたんでふんぎりついたわ。
Mojaviを参考にしながら必要十分程度の軽さのやつつくろ。

と思ったけど一度まともなフレームワーク見たら
今更自作できねぇなw
FilterChainやActionChainの発想なんて自分で思い付くのに一体何年かかるやら
mojavi2+php4+アクセラレータでがんがるか…

>>710
Ethnaとかどうよ？
後発だけに割と練られてるんじゃないかと思われる。パッと見だが。

Pear::DBに依存してそうな感じだからスルーしてる。

define('URL_FORMAT', 2)の設定で
これを
http://localhost/index.php/module/???/
このように
http://localhost/system/module/???/
にしたいんですがどうやってやるんでしょうか。

>>712

define('URL_FORMAT', 2)にしたら、

http://localhost/index.php/module/モジュール名/action/アクション名

でアクセスできると思うけど、

http://localhost/system/module/???/
これはどれがモジュール名でどれがアクション名？

>>712
mod_rewriteを用いるか、

いつものindex.phpをsystemとリネームしておいて
ForceTypeディレクティブまたはSetHandlerディレクティブ（PHP5)でsystemをphpとして実行してあげる。
具体的には
<Location /system>
ForceType application/x-httpd-php
</Location>
てしてあげる。

>>711
なかなかよさげだなー
Mojaviを参考にしたって言ってるから移行もしやすそう
日本人が開発してるからドキュメントが読みやすい（当たり前）
機能的にもかゆいところに手を届かせる意志を感じるし
まだ変化の途上っぽいから実働サービスに組み込むのは怖いけど
追いかけておいてもいいかもね

Mojaviで、
他のActionから呼び出すためだけのActionって別に作っても変じゃないよね？
メインActionが各サブActionに仕事を発注し、Requestをこめこめして
View氏に渡すって流れなんですが。

>>713
ttp://fandc.co.jp/engine/module/catalog/action/list/
このサイトみたいにやりたいんです。
ここはindex.phpないですよね。

このサイト、エロ系だけどDB_DataObject とか使って
すげぇなーと思う。

714が言ってるけどmod_rewrite使うのが定石と思う

>>716
昨日作った。

MojaviJapan落ちてるくさい。

Mojavi本家でもMojavi2.0のダウンロードが出来ないのは
どういう了見なんだろう？
MojaviJapanで出来たから助かったが。

>>720
本家のsvnレポジトリからダウンロードできますよ

>>721
意味が分からなかったのでググったところ
svnレポジトリは
ソースのサブバージョンを格納しているデータベースみたいなもんのようですが
どうやってアクセスするのですか？

Subversionをいれれ。
WINならGUIソフトもいれれ

>>716
以前、そういう感じでやってみたが、フレームワークの中にフレームワークを作ってるんじゃなかろうか？
という疑問が沸いて、結局サイトの構成やらクラスの設計やらを大幅に見直してやめた事がある。

果たしてMojavi3.0の時代は来るのだろうか？

>>723
分かりました
ありがとうございます

3.0でConfigHandler.class.phpで
Strict Standards: Only variable references should be returned by reference
ってのが出まくるんですけど
これなんですか

iniファイルのどれかが問題とみた。

[databases]

default = "Default"

; conn2 = "MySQL"

[Default]

class = "PostgreSQLDatabase"

ここもこんな風にしたんですけどね。

mojavi/config/ConfigHandler.class.php on line 179
↑これが多いです

>>717
Apacheを使ってるという前提で書くけど、httpd.confにMultiViewsを追加すればできるよ。
こんな感じで、ドキュメントルート以下でMultiViewsが有効になるようにする。

<Directory "ドキュメントルートのパス}">
Options Indexes FollowSymLinks MultiViews
・・・ 省略 ・・・
</Directory>

これなら、
ttp://localhost/index.phpがある場合、
ttp://localhost/indexでもアクセスできるようになるので、
ttp://localhost/module/catalog/action/list
というURLでアクセスできる。

define('MO_ERROR_REPORTING', E_ALL | E_STRICT);
を
define('MO_ERROR_REPORTING', E_ALL | E_ALL);
にしたらできました。

>>730
>ttp://localhost/indexでもアクセスできるようになるので、
ここから、どのように
>ttp://localhost/module/catalog/action/listというURLでアクセスできる。
へつながるの?
実際試したの？

>>732

だいたいの意味が分かればいいと思ったから、試してなかった。

×ttp://localhost/module/catalog/action/list
○ttp://localhost/index/module/catalog/action/list

>>733
それなら>714の方が、余計なところに影響及ばなくてよさげだな

>>734
そうだね。

PHP5使いたかったんでMojavi参考にして自前フレームワーク作った
（3はまだDEVなのでパス）
Mojavi式は
MとVがぶっちり断絶するから頭が整理しやすいな

>>736
EthnaとかMapleを選ばなかった理由は?
んで、Mojavi3より良いものできたのなら公開頼む。

>712
URL_FORMATを2にすると、CSSやら画像やらへの相対リンクがおかしくなるから気をつけて｡

>>737
国産フレームワークはまだ進化の道程というか枯れ感がないので
今まさに開発中のサービスに組み込むのは抵抗ある。

>>738さんどうもです。
1にしてmod_reqriteされてるんですか。

>740
いえ、わたしは1で使ってます｡

mod_rewriteを併せて使うなら問題ないと思うのですが､
714さんの紹介されているディレクティブを変更する方法「だけ」だとハマるかもしれません｡

はまればいいじゃない。
そういう経験は重要。

>>716
ActionChainの事？
イマイチ使いどころがわからん。
DIモドキな使い道があるらしいけど。

>>737
＞Mojavi3より良いものできたのなら
無理言うなよｗ

Mojavi3なんか遅くない？
Smarty組み込んでテスト表示だけさせてみたけど
なんかもっさりしてる気がする

>>745
2回目以降の表示はそう遅くない

Mojaviのdecorateを詳細に紹介してるページねーかな
ｻﾌﾞﾃﾝﾌﾟﾚｰﾄを実現するみたいだが。
今作ってるなんちゃってﾓｼﾞｬﾋﾞではViewResultContainerに
各ViewResultをRENDER_VARでぶちこんで、
ボスViewがそいつらを使ってRENDER_CLIENTするようにしたが。
decorateに仕組みがわからん。

>>744
Mojaviやその他既存のフレームワーク切り捨てて作るんだから
それらを越えるもの、少なくとも同等のもの作れるんでは？

もし業務でやってるならなおさらに。

mojavi3とphp5で開発してるんだけど、
isSecure()で認証かけたページのみ全部表示されない。
ページの下の方が欠けてしまう。
こんな現象にあった方いないですか？

>>749
なんだ！？ページの下の方って！！？HTML間違って書いてるんじゃないの？
同じページでisSecureをfalseにしたらちゃんと表示されるわけ？

>>750
そうそう。falseにしたら表示される。
htmlが途中までしか表示されないんです。

a.途切れる場所がランダム
認証処理に時間かかりすぎて、出力中にちょうどタイムアウト

b.決まった場所で途切れる
テンプレートで変数みていて、認証処理でその辺数になんかしちゃってる

でどうよ

mojaviって自分で作ったクラスはどこに入れるのが一番いいんですか？

lib

libに入れたからってautoloadされたりはしないみたいですね

おまいらもう3で作ってるの？
3って実用レベルなん？

>>752
b.ですな。
了解、当たってみます。

セッションハンドラにオブジェクトのメソッドを設定するには
配列で設定すればよいと
ﾓｼﾞｬﾋﾞのソース見てはじめて知ったよ。
勉強になるなあ。

>>758
PHPのドキュメントにもちゃんと載ってまっせ。
http://jp.php.net/manual/ja/language.pseudo-types.php

>>759
うぉ！俺も勉強になった！

>// Type 3: Object method call
>$obj = new MyClass();
>call_user_func(array(&$obj, 'myCallbackMethod'));
ってPHP5だと参照渡しじゃなくていいんだよな?

>>755
もじゃび３/webapp/config/autoload.ini
の下のほうをよく見てみましょう。

>759
ほんとだ、ちゃんとマニュアルに載ってんだね(^^;

俺はQuickFormのcallbackルールを追っかけてたときに知ったよ｡

MojaviのAPI見てはじめて
registerが動詞で
registなんて言葉は存在しないと知ったw
勉強になるわ

そんなこと言ってくと del なんかもﾔﾊﾞｽ

アクションチェーンとか言うやつ使ってる人いるの？
あれってどうなのよ

>>766
2.0ではあると便利だが、3.0では洋梨

>>767
むしろ３では$controller->forward()

>>768
modelがあるだろ

3ではDecoratorを使う。が、いかんせんサンプル不足。

>>770
decorator使い方わかったら教えてください

Mojavi Builderってどうやってダウンロードすんの？
記事ばかりでダウンロード出来るリンクがわからねー

なんかPhrameスレのはずがMojaviスレになりつつあるな。
いちおう↓のスレでもMojaviネタ蔓延ってますよっと

PHPでオブジェクト指向プログラミング
http://pc8.2ch.net/test/read.cgi/php/1113724557/

むしろ誰かMojaviスレ立てたら？
漏れはまだ低脳なんでやめときます。

リリースXはダウンロード出来たけど
これが現在の最新バージョン？ベータっぽい名前なので気になる

Mojavi2ではクラスのコンストラクタが参照返しになってますが
これはどういう意味があるんですか？

>>775
クラスだから。

つうかMojavi2じゃなくてPHP4の仕様。

コンストラクタを参照返しにして
$a =& new Class()
にしないと、
インスタンスが内部的には2つ作られてしまうということですか？
普通に$a = new Class()を多用してた…orz

ちなみにPHP5では改善されてる。
とりあえずマニュアル嫁

http://www.stackasterisk.jp/tech/php/mojavi05_03.jsp
ここのCustomSmartyRendererクラス、
コンストラクタの引数$controller, $request, $userに
&が抜けてるので注意のこと。

こういうミスを見るとPHP5がすばらしく思える。

たしかに、動かしていても気づかないからかなり気を遣うな。

ﾓｳﾊｰﾋﾞでモジュールの遷移を記録するにはどうすればいいですか？
企図したとおりに処理が流れてないので
流れを知りたいのですが…

>>782
ソースを読む

>>780
PHP4でもプロパティを書き換えない限り内部的にはインスタンスのコピーは行われないと聞いたことがあるけど、デマかな？
値を書き換えようとしたときに自動的に適切なコピーが作られる・・・みたいな。

>>784
確かそういう動作だったハズ
ただ779の場合はそれぞれSingleton的なインスタンスなので
コピー渡しはよろしくないよね

M2で
AUTH_MODULE・AUTH_ACTIONてモジュールごとに設定したいなぁ
モジュール固有の設定ファイルあればいいのに

ページ名ってViewで設定してる？
Actionで設定してる？
DBアクセスあるならActionで設定するけど
半固定的なページ名の場合はViewかな？

モジュールフィルタのパス指定は
BASE_DIRからちまちま書いていくもん？

と思ったらMODULE_DIRもあった
どっちにしろなんか面倒くさいな

>>782
Mojavi3なら適当に例外投げるとスタックトレースがグラフィカルに

>>790
残念ながら2なのれす

ﾓｳﾊｰﾋﾞと星のカービって似てね？

似てるのはお前の体形だけじゃん

お前どこ中だコラ？

ピカ中

時代は かみちゅ！

$action = $controller->getControllerPath(
$controller->getCurrentModule(),
$controller->getCurrentAction()
);

途中で投稿してしまった
M2で今いるURLを取得するにはこういう風にするしかないですか？
一発で取得できるメソッドもないようだし…

>>797でいいんで内科？
もしリクエスト元が欲しい場合にはgetCurrentModuleとかgetCurrentActionではなく、getRequestModuleやgetRequestActionで。

あとは
$mojavi = $controller->getMojavi();
$action = $mojavi['current_action_path']; // 又は $mojavi['request_action_path']
なんていう裏技もあったりしてｗ

もしくは
$action = $_SERVER['PHP_SELF'] . '?' . $_SERVER['QUERY_STRING'];
とかｗ

>>799
なるほど
getMojaviって何だと思ってたらMojavi内環境変数だったんですね
いろいろありがとうございます

PHP_SELFとQUERY_STRINGつなげるならREQUEST_URIでええやん

特にサーバーサイド処理がなく、
ただﾃﾝﾌﾟﾚだけを表示したい場合でも
ActionとViewを書かないといけないのでしょうか？
なんだか無駄なような気が…

こういうのが出てくるから困る

>802
アクション名を指定して､Action・View・Templateをまとめて自動生成するようなスクリプトを自分で書けば済む話。

>>802
mojaviを使わなければよい。つかphpすら不要。geocitiesでも使っていなさい。

>>804
やっぱりそういうの作ってるんですか
Ethnaに付いてるスケルトン生成スクリプトみたいなもんですね
>>805
意味が不明ですが

>ただﾃﾝﾌﾟﾚだけを表示したい場合でも

hoge.tplがただのテンプレートとして
index.php?module=Default&action=Static&page=hoge
とかで、
Staticアクションクラスで、
hogeのパスをViewに渡せばいいんじゃない？
それか、静的なhtmlっつうなら、リダイレクトさせるとか。

とりあえず、１つ書いとけば使い回せるんじゃない？

>>806
>>805 ではないが、サーバーサイドの処理が必要ないならなぜ
phpを使いたいの?

>>802
> 特にサーバーサイド処理がなく、
> ただﾃﾝﾌﾟﾚだけを表示したい場合でも
> ActionとViewを書かないといけないのでしょうか？

いいえ。

>>802
> 特にサーバーサイド処理がなく、
> ただﾃﾝﾌﾟﾚだけを表示したい場合でも
> ActionとViewを書かないといけないのでしょうか？

はい。

>>802
> 特にサーバーサイド処理がなく、
> ただﾃﾝﾌﾟﾚだけを表示したい場合でも
> ActionとViewを書かないといけないのでしょうか？

ごめんなさい。

>>802
それならコピペ程度。

>>802
発想が貧困すぎ

>>807
ありがとうございます。シンプルにリダイレクトしておきました。
>>808
イレギュラーな静的ページも
Mojaviのモジュール内に収めた方がすっきりするかなと思ったんですよ。
>>809-813
えーと、基地外の方ですよね？

>>802
そもそも静的ページでサーバサイドスクリプトを使うこと自体が無駄だと気付かない
おまえが基地外

>>815
想像力が異常に欠如したお前には
動的システムの中にイレギュラー的に静的ページが発生するという経過的事態が
理解できないんですね？

まず>>802の日本語が稚拙なことに気付け。
藻前から見た基地外がこれだけ発生したということは、藻前自身が基地外である可能性について胸に手を当てて考え直せ。

>>817
同一人物じゃねえのかよw
片言で意味不明な煽りをする奴が何人もいるとしたら痛すぎだな

> 同一人物じゃねえのかよw

いいえ。

>>819
イエス・ ノー枕なみの言語能力ですね
日常生活でも二進法をおつかいですか？

> 同一人物じゃねえのかよw

いいえ。
…こんどは意見があったね。>809

たぶん、こんな質問をするヤツには
809が正解。
フレームワークを使う意味や、何人か共同で作業する場合は
810の方がいい。理由がわからないならフレームワークを使うことは
効率が悪いのでよしたほうがいい。
動けばいいなら好きにすればいい。
正解を誰かに決めてもらえないと進めないのか。もっと自由でいいと思う。

>イレギュラー的に静的ページが発生する
イレギュラー的ってどういうこと？バグ？
想定できるのであれば、そのように作ればいいだけのこと。
「そのように」というのも決めてもらいたいのか。

自分が理解できない次元を基地外とカテゴライズするのはやめたほうがいい。
教育を受けた人間はそういうもんじゃない。
若造のために年寄りからまじめな助言だ。

最後の一言は余計かもしれないが、想像力のない阿呆へのレスはこれで最後にしておく。
じゃね。

ごめん、810でした。なんだか802みたいなのがいると思うと
悲しくなってきた。いや802の発言はいいんだがその後がさ。
多分「初心者です。勉強しようと思っています。」
って子なんだろうけど。…チラシの裏ご容赦。

M2にHTML_QuickFormを組み込んで使ってますが、
http://iteman.typepad.jp/blog/files/hustling-mojavi.html
ここにあるようなフィルタはかけてないです。
それで特に問題なく動作しているようですが、
このフィルタがいるようなケースってどんな場合が考えられますか？

静的ページでも認証は通したいとか前段のフィルタは通したいとか
そらいろいろあるわな

>>824
>>802が元質問なのだが…。違うことへのレスかな。

>>823
このフィルタさあ、HTML_QuickFormと合わせて使うとさ、
magic_quotesが1の時ってリクエストパラメータに2回
stripslashesがかかるような気がするんだが、、、
mojaviのリクエスト処理時と、HTML_QuickFormのリクエスト処理時にも
同じようにstripslashesしてるところがある。
俺のやり方が間違ってんのかなぁ、、、

>>823
使ってる人いるの？

>>823-827
おまいら、話の流れがさっぱりわかりませんよ。
>>823の言わんとしてるのは

if ($_SERVER['REQUEST_METHOD'] === 'GET') {
  $_GET = array();
  $_GET = &$request->getParameters();
} else {
  $_POST = array();
  $_POST = &$request->getParameters();
}

をやる必要あるの？って話じゃないの？
そこの解説ページにのってるフィルタの主な処理はコレ↑だけだしね。
とりあえず、Mojaviの他の部分で$request->setParameter()した場合の整合性合わせる用でしょ。

で、>>824は>>823へのレスだろうか？イマイチ意味がつかめなかった。
そこへ>>825==>>802(?)が再登場？（だとしたらｳｻﾞｲです）
何がなんだかわからん。

>>826はレスしてるように見えて、実は関係ない話くさいです。
ﾊｲﾊｲそうですね。stripslashes２回呼ばれちゃいますね。
でもフィルタは関係ないですよ。Mojaviの中でstripslashesしてるのはController様です。
このことから考えてMojavi2とQuickFormは仲悪そうだね。互換性に関して問題ありと。
現状での解決策としてはmagic_quotes変えるか、ﾊﾟｯｹｰｼﾞのソースを適宜書き換えるしかなさそうな悪寒。

>>827さん、俺も使ってないのでわかりません。
というわけで以上、チラシの裏でした。

setParameterを使った場合には必要になるってことですね。
外からのパラメータのコンテナを書き換えるなんて
かなりお行儀が悪いと思うけどどうなんだろう。

>>828
URL_FORMAT 定数を PATH フォーマットにした時の為のフィルタじゃないかな？
Action に偏移する前に一度だけ実行するような書き方になってるし、
Request::setParameter については関係ない or 考えてない気がする。

>>828
802の名誉のためにいうけど810です。
わからないならいちいちレスしなくていいよ。
ウザイって漢字で書けるかい？
たいていこの言葉をつかう人は馬鹿っぽいのだが…。

>830
823のフィルタがPATHフォーマットの場合にどういう効果をもたらすの?

ソースを見る限り、サブミット変数とRequestのパラメータを一致させてる以外に何をしてるようにも見えないんだけど｡

でも一回しか実行してないから
setParameterの整合性が目的ならおかしいな…

setしたもんはgetでとればいいんじゃないの？
なんか誌面（まるごとにも載ってる）さくほど、便利とはおもわないけど。

なんか、Mapleいいかなぁ。テストしやすそう。

いちいちゲッターセッター書くのと、いちいちnewするのとどっちか好き？
いや、どっちでもいいんだけど、、、（本質的な問題じゃないし）

>>832
Request が持つパラメータの生みの親は Controller::parseParameters()

1. HTTP GET 変数の内容を取得。
2. URL_FORMAT が 2 なら、環境変数なりサーバ変数から
　 PATH_INFO を手に入れて適当に分解、1 の結果へ上書き。
3. HTTP POST 変数で 2 の結果を上書き。
4. 仕上げに magic_quotes_gpc が有効になってればアンエスケープ処理。

>>823 のフィルタはこれをもう一度 HTTP GET/POST 変数に戻してる。
…という事だろう。書いてて不安になってきたぜ。

>>835
Mapleマジお勧め

クラス内で、newなんてしないで
DIコンテナ使って依存性排除した方が良いよ

コンポーネント主体の開発にするとテストが楽なのも確か

DAO・DTO・Logic作って
ActionはLogicの呼び出しとViewへの値返却だけ
って感じにすると開発も楽だよ

>>837
やっぱ、注入っすか？

>>834
Mojavi内ならそうだけど
QF側ではリクエストパラメータ直見してるから、
フック的にリクエストパラメータを再設定してからQFに渡したりは出来ないじゃん。
setParameterの存在意義、いまいちわかんね。

>>839
いや、mojavi内部に保持してる
リクエストパラメータへのリファレンスを
$_GET、$_POSTに割り当ててるから
QFを生成する前にsetParameterしてやって
かつQFのリクエストメソッドと一致していれば
QFにそのsetPrameterの反映はできるよ

ただQF自体のリクエストの保持の仕方が
生成時に$_GETか$_POSTを単純にコピーしてるだけみたいなんで
生成してからは無理っぽい

ていうかsetParameter自体いらないけどな

Mojavi使われてる有名なサイトってどこ？
本当に使われてるのかよ…外から見ても分からないだけか？

ｻﾌﾞﾃﾝﾌﾟﾚｰﾄ生成のためのActionは外からの呼び出しを禁止したいのですが
何か良い方法はないでしょうか？
Attributeにフラグをセットして、それで判断しても出来ますが
Mojavi2に既に実装されている機能のみで出来ないかなぁと。

なんでMojaviってmodelのことをActionって呼ぶの？
MVCだろ？

ActionはModelとViewの橋渡しだろ？

>>838
遅レスですが・・・
依存性注入（この言葉には賛否両論あるみたいですが）っす

setter/getter書くの面倒ですが
それなりの対価は得られると思います

DIContainer2使うとPear使えるようになったり
factoryメソッドに注入とか出来るので
お勧めっす

そう呼びたいからさ。
お前だってあるだろう、そういう時。

＞ActionはModelとViewの橋渡し
煽りじゃなくて意味不明なんだけど。
じゃあMVCじゃなくてMAVCじゃん。

ModelとActionはイコールじゃないよ

>>847
MVCパターン(?)とそのフレームワークと同一視してないかい？
たまたまコントローラ・ビューという言葉が同じだからといって
残りのアクションがモデルと同じと勝手に解釈しちゃだめだよ。

M2のSmartyRendererの
setArrayByRefメソッドおかしくない？
Smartyクラスを　assign_by_ref($array);
で呼んでるんだけどassign_by_refは以下の通り。
function assign_by_ref($tpl_var, &$value)
{
if ($tpl_var != '')
$this->_tpl_vars[$tpl_var] = &$value;
}
引数が2つあるから
Missing argument 2 for assign_by_ref()
が出るんだよ。

取り急ぎオーバーライド用のメソッド書いてみた。
Smartyが仕様変更したんかな？

function setArrayByRef(&$array) {
$keyArray = array_keys($array);
for ($i = 0; $i < sizeof($keyArray); $i++) {
$key = $keyArray[$i];
$this->engine->assign_by_ref($key,$array[$key]);
}
}

PHP4.4で仕様変更されてるがどうよ

>>852
かなり素敵な変更なので、4.4.0は残念ながら見送り決定。
正しい仕様になったというが、なんか納得できない。

Mapleで教えて欲しいのですが、以下の設定でエラーがでます。
スペルミスとかの可能性大ですが、Mapleの使い方がよくわかってないため設定が正しいのか知りたいです。
どなたかよろしくお願いします。DIContainer2を使ってます。
ちょっと略してますので、以下の設定であっているのなら他の部分を当たってみます。
■Menu.class.php（アクション）
class Menu {
var $logic; var $dto;
function execute(){
　$this->logic->makeMenuArray($this->dto);//<--この行でエラー
//Fatal error: Call to a member function on a non-object in PATH TO FILE line XX
　中略
　return "success";
}
以下セッタ・ゲッタ
}
■Menu_Logic.class.php
class Menu_Logic {
var $menuDao;
function makeMenuArray(&$dto){
　$this->menuDao->makeMenuArray($dto);
}
以下セッタ・ゲッタ
}
■Menu_Dto.class.php
class Menu_Dto {
var $result;
var $a;//リクエストパラメータ
以下セッタ・ゲッタ
}

■Dao_MenuDao.class.php
class Dao_MenuDao {
function makeMenuArray(&$dto){
　return true;
}
■maple.ini
[DIContainer2]
filename = dicon.ini
[InjectRequest]
menuDto =
[Action]
logic = ref:menuLogic
dto = ref:menuDto
[View]
success="menu.html"
■dicon.ini
[DIContainer]
menuLogic = "component://menu.logic"
menuDto = "component://menu.dto"
menuDao = "component://dao.menudao"
[menuDao]

[menuLogic]
menuDao = ref:menuDao

[menuDto]
a = 1
どなたかよろしくお願いします。

エラーの内容は、
おしえてあげません♥

>>856
すみません。コメントだけいれてそのままでした。
Fatal error: Call to a member function on a non-object in PATH TO Menu.class.php line XX

エラーメッセージの通りDao_MenuDaoがインスタンス化されてないようです。
(Mockで確認しました。)設定の仕方が拙そうなのですが
どなたか
前記のAction Logic DTO DAO を使用した設定ファイルmaple.ini, daicon.iniの
書き方を教えていただけないでしょうか。
よろしくお願いいたします。

>>852
呼出側のリファレンス渡しが駄目になったんだっけ？
PHP5はもともとそうだったような。

確かエラーでるね
でないかも。

>>855
DIContainer2のdicon.iniで
コンテナ内のコンポーネントを参照するには

dicon://ComponentKey

と書きます。つまり

[menuLogic]
menuDao = "dicon://menuDao"

こうなります。

>>844
M3ではな

>>861
動作確認できました。長々とした文を読むのも大変だったと思います。
ありがとうございました。

>>862
もっと詳しく教えて

Mojaviでさー
セッション使わないページの閲覧でも、ﾓｼﾞｬ内部でユーザコンテナの初期設定してるから
セッションリソースが消費されてくじゃん。
数十万アクセス/日程度になると、
そんな実トランザクションの伴わないリソース消費も半端じゃなくなると思う。
ハンドラ書き換えて、ﾓｼﾞｬ内初期設定しかされていなければ
DBへの書き込みは行わない等の処理を行えば防げそうだけど、
そんなことしてる人いる？
もっとキレイに出来ないものかとも思うけど。

こっちでノータッチの時は
authenticated|b:0;attributes|a:0:{}secure|a:0:{}
がセッションハンドラのwriteメソッドに渡ってくるから、
それならDBへのinsertは無視するの。
かなり無理矢理感あるけどどうでっしゃろ。

>>865
むしろセッションいらないから何もしないstorage作った。

>>865
factories.iniに
[storage]
param.auto_start="Off"
って書けばいいんじゃないの？
もしくは>>867のようにStorage自分で書くか。

>>867-868
ストレージってM3だよね？
使ってるのM2なんだｽﾏｿ。
M2でもセッション使わない設定できるけど、
ログインユーザにはセッション使いたいから、
一括で使用禁止にはできない。
とはいえ、
ゲストユーザ（おそらく大多数）のアクセスのたびに
セッションがいちいち作られちゃうのは、リソースがもったいない。
だからセッション変数を読むだけの時は、
たとえsession_startしていてもリソースを保存しないように
しようってことです。

M2で4.4にしたらNotice出まくりじゃん！
こりゃ使えんなぁ…

M3ならだいじょぶ

Viewでやることって己に対応したテンプレートに
Actionの成果物を渡すだけだから
ほとんど書くことないよなー
もっとシンプルにできねーもんかな

>>872
例えばテンプレートがテーブルとかで形成されててそのセルに
html的なのを差し替えて入れなきゃならない場合なんか
Actionでデータを入手してViewで整形したり結構するんだけど
普通はActionとかでやっちゃうのかな。

>>872はテンプレートにプレゼンテーションロジックが
入っちゃってるパターン。

>>873はテンプレートとプレゼンテーションロジックを
キッチリ分けてるパターン。

俺は>>873派。

Ajaxのためにレスポンス重視でフレームワーク経由しないphp書いたらどえらい速かった。
フレームワーク導入に疑問がわいてきた…
導入の過程で学ぶ部分は多かったけど…

>>875
君、そもそもプログラミングとか向いて無いと思う。

>>876
そんなことを憶測で語られてもw
まあ色んな意味で標準的なﾓﾉ作るのには有用だと思うけどね。
ポータル級のアクセスを前提とした場合、
既存フレームワークを使うのは違うと思う、たぶん。