【PHP】Phrameを使う【フレームワーク】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
04/08/23 14:15ID:???※関連リンク
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
0238nobodyさん
04/11/26 21:02:43ID:???lib.new
filter.new
logging.new
opt.new
auth.new
filters.new
等です。全部で23個もありました。
ちなみにnewファイルが存在したのはUnix Gzipのファイルです。
Windows Zipのファイルにはnewファイルがありませんでした。
0239nobodyさん
04/11/30 09:34:43ID:???0240nobodyさん
04/11/30 17:42:49ID:???遅くなりましたが、調べてみました。
どうやら以前置かれたファイルと異なるようですね。
48513 Sep 2 00:34 mojavi-2.0.0.tar.gz
45779 Nov 30 17:38 mojavi-2.0.0.tar.gz.old
違いはそれらの空ディレクトリだけでした。
削除して構わないです。
0242nobodyさん
04/12/15 10:10:17ID:???Ethna使ってみた？
Wikiに書いてある通りに確かに、同じコードを必要以上に記述しなくて良い雰囲気が実感出来た。その辺Mojavi2より優秀かも。
Mojavi3を見ない事には何とも言えないけど、選択的に使えるんじゃないかなと思った。
Mojaviクローンにあまり興味ないので更新状況以外は追いかける気は無いけど…
そろそろ誰か、PHPフレームワークの総合スレお願い。
0243nobodyさん
04/12/15 11:16:35ID:???自分的には好感度はかなりいい。
「まるごと〜」には、あのくらいのチュートリアルを期待してたのだが……
Ethenaはちょっと試してみようと思う。情報ありがﾄﾝ > 242
0244nobodyさん
04/12/17 15:22:09ID:???その他のフレームワーク
ttp://ethna.jp/ethna-related.html
Mojavi、Maple、Ethenaの比較をどなたか。
0245nobodyさん
04/12/17 16:10:02ID:???スクリプトもSJISが交じってたり。SJISで開発してるの？
0246nobodyさん
04/12/17 16:23:58ID:???0247nobodyさん
04/12/17 16:32:54ID:???0248nobodyさん
04/12/17 22:42:09ID:???色々忙しくなってきたな。でもMojaviのやった後ばかり追いかけても楽しくないが。
0249nobodyさん
04/12/21 13:52:01ID:???0250nobodyさん
04/12/21 15:51:24ID:/whrBEG+0252nobodyさん
05/01/08 01:45:21ID:???ある程度行き渡って初期情報交換の役割が終わったのと、PHP4 -> PHP5 移行期で色々地下進行してるのかとか予想してみたり。
まぁ保守。
0253nobodyさん
05/01/08 02:28:15ID:???0254nobodyさん
05/01/09 20:55:31ID:???今更2.0.0なんて使おうなんて間抜けなことはしない。
0255nobodyさん
05/01/11 02:04:20ID:???今更リソース突っ込んで研究しないよ って事か。
早い人はもう 3.0 調べまくってるようだけど。
0256nobodyさん
05/01/11 23:01:04ID:???2.0系とどこが変わったのかよくわかんない。
0257nobodyさん
05/01/12 02:26:04ID:???0258nobodyさん
05/01/12 11:44:30ID:???http://www.guesswork.jp/
なんとなく簡単そうなのと、サイトのつくりがいい感じ。
0259nobodyさん
05/02/04 02:14:28ID:???0260nobodyさん
05/02/04 11:17:54ID:???もはび・もはーび・もうはーび←この発音が一番近い
いずれにせよ「じゃ」じゃない。
ところで、フレームワークって解説なし、ソース嫁ってのが普通なの?
自分が使うために作り始めるんだろうから、そうならざるを得ないのかな。
作る人はいろいろこだわって思い入れを持って作るんだろうけど
正直、ユーザはフレームワークを使ってMVCを楽に分けたいと思って使うんで
ソースから読まなきゃ行けない手間がかかるんなら本末転倒じゃないか。
その辺のところどうなんよ。
Mapleに注目してるんだけど、
「○○という機能は、フィルタを作成すれば使えます。」
ってその作り方はソースみてねじゃ。使えねーって思うんだけどな。
結論、チュートリアル早く続きを書いてね。
せめて文字コード機能の修正版だけでも早くだしてね。
開発者のページに書き込むとひんしゅくかいそうなので、ここで遠慮がちに希望します。
文句つけながらも実は一番期待しています。
0261nobodyさん
05/02/04 12:28:50ID:???追加しながら、実用性のあるMFCやWindowsプログラミングを段階的に説明
していくのがあるけど、PHPのフレームワークでもそういう解説が欲しい。
いつまでもHello worldやって説明終わりで済んでいる段階じゃないでしょ。
0262nobodyさん
05/02/04 12:39:47ID:???チュートリアルも「Filterは既存のFilterのソース見て作ってね」ってなると思うけど。
でも細かなバグつぶしてこまめにリリースして欲しいと俺も遠慮がちに希望。
0263nobodyさん
05/02/04 14:14:43ID:???寧ろ PHP で普通。Mojavi なんて恵まれてると思うが。
サンプルアプリケーションあるし、Mojavi 使った成果物も転がってるし、ドキュメント拾い読みして解析していけば大体掴める。
あとは PhpDocumentor にかけて洗い出す。
どうせ何か書いてくれるならこの先が知りたい。Mojavi は使ってる人によってそれぞれ独自のノウハウが溜まっている事があって面白い。
導入コスト下げてくれ、ってのはまた別ベクトル。
ある会社は PHP でご飯三杯はいけるフェチな人を起用して Mojavi を軸にパッケージと導入プラン作らせてるし、
別のチームはそれぞれ分散して別々のフレームワークを調査し、持ち寄って比較検討して溜まったノウハウで導入に持ち込んだりしてる。
*やる所はやってる。*
ドキュメンテーションは非常に大事だと思うけど、Maple は知らんが、Ethna や Mojavi は開発リソースが足りているとは思えないので現状は仕方ない。
寧ろ足りないと思えば周辺で作れる部分は周辺でやっていくべきじゃないかと。
もしくはクレクレコールは出版社の方に放って、T.K, K.T, T,J, A.K 氏辺りのエラい人達をもっと酷使して記事書いてもらう。
Java兼業ライター専門は不要。PHP に頭から浸かってるヤツにノウハウも情報も吐き出して頂く。
PEAR なんて本家マニュアルの充実と平行してそうやって W+D に色々記事が載る事で大分楽させて貰った。
0264260
05/02/04 15:59:36ID:???>>262
Headerの送り方がわからんのよ。多分回答はHeaderを送れるよう
フィルターを改造してとかで、そのフィルタはソース見てね。の堂々めぐり。
つーかそれ以前でPHPの自動変換機能をonにするとダメな仕様なのよ。
>>263
PHPで普通と言われると確かにPEARとかそうなんだけど。
だからと言って良いと思えない。PEAR不便でしょ。未知の機能が多すぎて。
PEARのような呼び出されるプログラムは呼ばなきゃいいだけだけど
フレームワークって呼び出す側のプログラムだからある程度理解してないと
怖くて使えない（ようじゃ困るとホントはいいたいんだけどね）。
ドキュメントじゃなくても、よくある機能の（コメント付き）サンプルアプリ配布して欲しい。
全体の関係の説明がないからフィルタ単体のサンプルを見ても作れない。
（作れる人は作れるンだろうけど）。
function init() //初期化(実際はJavaDoc形式だけど)
とだけ書かれてその関数の改造はできんぞ。まぁソース嫁ということなんだろうけど。
面倒でもその中で何をしているかコメントして欲しいんだよな。
そうすると周辺での開発がもっと活発にできるようになるんじゃないかと。
Mapleの周りの人は極端な話、製作者としてもいけるくらいの理解度が
あると思う。それくらいでないとMapleは今のところ使えないのが残念です。
0265nobodyさん
05/02/05 03:22:13ID:zCz2jx5JPerlに移植してみたいんだけど、
PerlでこういうStruts系で、シンプルなフレームワークって既出？
0267nobodyさん
05/02/05 04:19:44ID:???sledgeってちょっと調べたんだけど、ちょっと機能がありすぎな印象。
セッション、クッキーのモジュールなんかも自由に選べたり自作のものを用いられたりするような。
>>258のguessworkみたいなのをPerlで実現したいなあ。
それで、例外処理も楽にできちゃうようなやつ。
mojaviって例外処理どうなってんだろうか？
ちょっとコード覗いてみるかな。
0268nobodyさん
05/02/07 04:12:26ID:???本出したら、意外に売れませんかね？
ま、個人的には、guessworkくらい軽量のフレームワークの方が
見通しが良くて好き。
0269nobodyさん
05/02/07 04:35:07ID:???何部売れればペイするんだろう...
0270nobodyさん
05/02/07 04:57:34ID:???http://www.9-ten.co.jp/bookdata/0195.php
がそれっぽかった。
0271nobodyさん
05/02/07 10:17:33ID:???そーゆーのはサブタイトルにして
「サイト作成のMVC入門」とかにした方がいいんじゃないか。
PHP自体は初心者本ばかりだから初心者本を終わった人の次のテキストとして。
あるいは、オブジェクト指向とかの方法論はJava一色だからそうじゃないアプローチ
として、そこそこいけないかな。
「まるごとPHP」みたいなムックで、「まるごと」みたいに総括的じゃなく
「フレームワークPHPvol.2」や「PEARPHPvol.3」とかシリーズ化してくれると
いいな・・・
0272nobodyさん
05/02/08 09:25:09ID:cnHDtWyr>270の本は、なんであんなタイトルなんだろう？すなおに「Phrameで
簡単Webアプリ」で良いような気がする。
「まるごとPHP」は悪くはないと思ったけど、ちょっと幅広く詰め込んで
いたからなあ。Vol.1ってことは、Vol.2も出るんだよね？と期待Age。
0274nobodyさん
05/02/08 19:09:37ID:???Webサイト構築 > フレームワーク > MVC > Phrame
になるから、大きい方に振っちゃうのは仕方ないと思われ。
ｵｲﾗは Mojavi大全 とかいう名前の方に惹かれるがｗ
0275nobodyさん
05/02/08 22:24:44ID:???0276nobodyさん
05/02/09 11:09:49ID:???0277nobodyさん
05/02/09 13:02:02ID:???0278nobodyさん
05/02/09 16:22:05ID:???説明みたが
webapp/components/ DIするクラスを配置するディレクトリ
って書いてあるだけ。
DIContainer.class.php が絡んでくる気がするんだが、よく分からん。
そもそもDIするって何だ？って感じですが。
ソース嫁って話ですか？
orz
0279260
05/02/09 17:34:47ID:???要望が伝わって良かった。すごく期待しています。ホントです。
失礼な物言いもあったと思うけどゆるしてね。
期待の裏返しということでひとつ大人の対応で。
>>278
さすがにDIコンテナの説明までMapleの人に求めるのは酷だと思うよ。
俺もわかってないけどさ。（とりあえずダミーで開発を進められるという認識。間違ってる?
依存性の解消ってのは今ひとつ腹に落ちてない。）
しかし、PHPを使ってる人にはDIコンテナなんて聞いたことない人もたくさん居ると
思うので、後々はMaple流のDIコンテナの利用法・Maple流の開発手法といった
コラム的なのがあるとすっげーうれしい。
ご本人じゃなくても、周りの人やりませんか?
Maple普及の決定打になると思うんですけど。
0281278
05/02/09 18:54:07ID:???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: を使用してそのオブジェクトを取れますよと。
そんな感じであってるかね？
0282nobodyさん
05/02/09 19:36:04ID:???このアプローチの何が嬉しいのかをまず知るほうがいい。
http://www.kakutani.com/trans/fowler/injection.html
で、mapleが実現しようとしている目標として
DIContainerを使ったときの設計手法であるSeasarの「くーす」を
PHPでやろうとしてるわけですよ。
LLのなかでもwebアプリ構築のフットワークが比較的軽いPHPで
この手法が手軽に取り入れられるとなると、結構面白い事になりそ。
0283260
05/02/09 22:37:56ID:???うん、十分自覚してる。推敲前は「他力本願」なんて言葉いれてた。
らしくないと思って消したけど。まっその突っ込みからは何も生まれないから
せめて持ち上げて人にやらせる口調の方が組織に受け入れられると自画自賛。
↑大人な人はうなづいてくれると思う。言い方には問題あるけど。
>>281
知ったかぶりになるんだけど、それであってるんだけど、本来はきっと
オブジェクトの内容をしらなくても（あとまわしにしてインターフェース定義
だけの状態で）受け取れますよ。当然、クラスの内容が変わっても同じインターフェース
なら問題なく動作しますよ。ということのための仕組みと思うのですが自信なし。
（だから説明が抽象的）
>>282
そうそうMapleの優位性ってそこにあると思う。軽いのや解り易いのは今も今後も
出てくるだろうけどDIコンテナを実装してるのはMapleが最初。
あとはMapleが軽く（これハード性能で解決できるからどうでもいいと思う）
わ・か・り・や・す・くなってくれれば…
0284nobodyさん
05/02/10 03:14:38ID:???敷居が高すぎるような気がするんだけども、どうなんだろうね。
0285nobodyさん
05/02/10 03:16:22ID:???色々嬉しいけど、PHPでリクエストの度に依存関係をたどってオブジェクトの
親子関係を作って行くのはデメリットのほうが大きいような気もします。
まあ、Mapleの作者さんはこのあたり既にわかっていて対策を講じようとしている
ようにも見えるけど。
0286nobodyさん
05/02/10 04:07:23ID:???0287nobodyさん
05/02/10 11:07:13ID:???って人向けが基本では？
0288nobodyさん
05/02/10 14:50:05ID:???共有鯖でJava使えるとこなんてほとんどねーだろ。
個人や低予算でなんか始めたいってときにJavaは悲しいほど不向き。
0289nobodyさん
05/02/10 15:41:03ID:???PHPでライトウェイトな新しいやり方を模索してる希ガス。
>mapleの中の人
間違ってたらごめん。
0290nobodyさん
05/02/10 15:52:29ID:???0292nobodyさん
05/02/10 17:51:46ID:???0293nobodyさん
05/02/10 20:56:31ID:???0295nobodyさん
05/02/14 18:03:38ID:???テンプレートで独自タグ使いまくりなのは一長一短だけど、その代わり
PanelとかPlaceHolderみたいな使える機能が多い。
既存のコントロールを組み合わせて1つのコントロールとして扱うことも出来る。
独自フォーマットの妙な設定ファイルも無いし。
PHP5で作られているので、フレームワークと自分で書くコードとの違和感もない。
guessworkとは対極の、全部入りのフレームワークとしてこれから普及して
いくんじゃないかな。(もちろんguessworkも方向性としてはアリだとおもう）
0296nobodyさん
05/02/15 02:57:34ID:???今のままじゃフレームワークというよりただの骨骨コントローラじゃないか。
0297nobodyさん
05/02/15 03:03:39ID:EH186VHTゲスはバコバコいろんなとこから手持ちのモジュールをくっつけられて、
簡単なものをサクッと作るのにイイ！
0298nobodyさん
05/02/15 06:08:49ID:Kt+6ObGYただのコントローラーともいえないが・・・
0299nobodyさん
05/02/16 09:21:50ID:???「自分で調べなさい」なら平行線だね。
ケチつけるだけで心苦しいんだけど
「わかってる人でないとわからない説明」というのが正直な感想。
ごめんね。（じゃ、どうしたらいいかというと説明は断片的でもいいから
動作するソースをダウンロードできるようにするだけで随分と違うような。
例えそれが自明のものであったとしてもね。）
まぁDIコンテナは使わなくてもMapleは使えるんだけど
フィルタは使わないとMapleは使えない。チュートリアル…
0300nobodyさん
05/02/17 04:11:12ID:???激重だな…
0301nobodyさん
05/02/17 06:38:30ID:???ゲスのコンセプト自体、なんでもかんでも揃ってますとは対極にあるね。
土台として利用して、その上で好きなように積み上げて作っていけるのは
好きかも。ライブラリコンテナ的に利用できるってのは、ありがたい。
PHPの多機能なフレームワークって、俺様独自仕様が多すぎて、かえって
使いづらいからな。一度覚えて慣れてしまえば、そんなことないのか？
0302nobodyさん
05/02/17 08:21:24ID:???フレームワークにこだわる必要はないと思う
0303nobodyさん
05/02/17 11:35:45ID:???フレームワークにこだわったほうが効率がいい
0306nobodyさん
05/02/18 01:54:18ID:???スタッフ増員とかのたびに、その統一基準についていちいち説明するんですか？
無駄が多くてしょうがないですね。
0308nobodyさん
05/02/18 06:49:29ID:???別に304が標準の基準というわけではないとオモッタ
名前にレス番入ってないけど、下っかわはどれとどれが同一人物なの？
>>302=>>304
−−−−−−−−−
>>303 >>305 >>306
0310nobodyさん
05/02/18 19:24:55ID:???0311nobodyさん
05/02/18 20:26:26ID:???プロジェクトで規定のライブラリがあるっつーのは結構ありえる状況だと思うんだが。
よ〜し、パパ(プロジェクトマネージャーか？)このフレームワーク使っちゃうぞ♥
って躊躇無く言い出せる状況ってのは、
メンバー全員がそのフレームワークを使った事がある時くらいじゃないかなぁ。
フレームワークの肯定・否定をするつもりはないよ。
話がずれていってる気がしたから突っ込みいれてみただけ。
0312nobodyさん
05/02/19 00:22:53ID:???自称便利なライブラリ群で開発しちゃうような屑会社には
未来なんてあるわきゃーねぇ。もう業界辞めちまえよ。な？
0313nobodyさん
05/02/19 00:54:16ID:???の仕様もおのずと決まって楽チンなんです。
0315nobodyさん
05/02/19 12:38:38ID:???0317304
05/02/19 13:19:24ID:???俺解釈のお遊びなんだから、ピンとこなくても深刻に取らないで呉。
>>302に比べて、>>303は素直な発想できるいい奴だし、
こんなんで知能はかれるわけもないからなー。
0319nobodyさん
05/02/19 13:43:49ID:???＞プロジェクトで規定のライブラリがあるっつーのは結構ありえる状況だと思うんだが。
うん。確かに効率悪いことやってる会社や閉鎖的なとこでは結構あるね。
＞メンバー全員がそのフレームワークを使った事がある時くらいじゃないかなぁ。
使ったことなくても、まともな奴ならメジャーなフレームワークくらい覚えてくれる。
他のプロジェクトや、会社変えたときも使えたりするから。
もちろんPHPではまだそういう環境は整ってないけど。
あとは>>313に同意。それを理解できずに>>304達が標準以下な発言しだすから
話がずれてるように感じるんじゃない？
0320304
05/02/19 15:37:34ID:???ているか、ということは関係ないんだよ。
・俺に>>302のレスが標準以上に見えたのは、オールインワンな
多機能FWは面倒で、「好きなように積み上げて作りたい」という
>>301に対し、さりげに「プロジェクトで一貫して統一できるなら」
と皮肉っている産婆的な部分があったから。>>301にはチームで
開発するという視点が欠けていると感じていたから、ライブラリを
統一するようなチーム開発上のメリットをほのめかすやりかたが
上手いと思った。
・>>303をふざけて標準以下としたのは、「統一性を保障できるならFW
にこだわる必要はない=>FWはプロジェクトの統一性を保障する」という
>>302に対し、「ライブラリを統一するよりFWで統一する」と、ナンセ
ンスなレスを返してたから。俺は、>>303は>>302のレスを「ライ
ブラリ群をメンテして統一しろ（FW不要）」と読んでいると思う。だから、
「そんなことをするくらいなら」という言葉が出てきたんだと思うけど・・・。
まあ>>302と>>303はフレームワークの効用を理解しているかどうかで
言うとどっちもおんなじレベル・おんなじ知見だよ。
その後はいくつかのパターンがあるけど、FWを使うと仕様統一が楽
という当たり前のことを繰り返すレスと、誰かがFW使うメリットはない
と言ったかのように勘違いしてライブラリ開発否定して煽ってるよく
分からない人がいるって感じ。
フレーム起こしといて>>317だけじゃ無責任かと思って全部吐きま
すた。誤解がとけたかな？
0321nobodyさん
05/02/19 15:54:15ID:???おまえが煽ったせいでおかしな事になった”現実”を認識して、その”事実”を反省しろ。
0322nobodyさん
05/02/19 15:54:48ID:???0323nobodyさん
05/02/19 16:01:24ID:???0324nobodyさん
05/02/19 16:02:31ID:???ようするに>304はバカだと
0326nobodyさん
05/02/19 16:15:24ID:???真面目にフレームワークの話をしてくれた人が浮かばれねーですよ
0327nobodyさん
05/02/19 16:24:35ID:???多分今後広く使われていきそうなのはこの2つだと思うんだけど。
0328nobodyさん
05/02/19 16:36:55ID:???だから誤解じゃなくて、お前が理解できてないんだって。
＞>>302に対し、「ライブラリを統一するよりFWで統一する」と、ナンセ
＞ンスなレスを返してたから。
>>313読んでから書け。
0331nobodyさん
05/02/19 17:01:50ID:???.L二二」
| |
ヽ|・∀・|ノ
| |
.L二二」
.L二二」
、| | /／
ヽ ∴
ゝ∴ ├¨力 ン
− ∵ ∵
／/|＾＾”^lヽ ヽ
.L二二」
0332nobodyさん
05/02/19 17:04:36ID:???＞ためしに聞いてみるけど、俺が「何を」理解できてないと思ってるの
君のせいで、まともなネタすら煽りレスに流されてしまっているということ。
そして、君がいなくなればそれらが全ておさまるということを、まったく理解できていない。
0333nobodyさん
05/02/19 17:10:48ID:???フレームワークのメリットが理解できてないと思われてんじゃないのｗ
お相手さんは目が真っ赤だから、何を言ってもフレームワークの話に聞こえんだよ
>>331
土管乙
■ このスレッドは過去ログ倉庫に格納されています