【PHP】フレームワークについて語るスレ10【総合】
レス数が1000を超えています。これ以上書き込みはできません。
0001nobodyさん
2008/02/09(土) 10:43:58ID:???http://pc11.2ch.net/test/read.cgi/php/1197383840/
0002nobodyさん
2008/02/09(土) 10:44:59ID:???【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
0003nobodyさん
2008/02/09(土) 10:45:40ID:???symfony
http://www.symfony-project.com/
code igniter
http://codeigniter.com/
Zend Framework
http://framework.zend.com/manual/ja/index.html
CakePHP
http://www.cakephp.org/
【和モノ】
ちいたん
http://php.cheetan.net/
Ethna
http://ethna.jp/
guesswork
http://classic.guesswork.jp/
maple
http://kunit.jp/maple/
0005nobodyさん
2008/02/09(土) 16:05:48ID:???Piece Framework
http://piece-framework.com/
rhaco
http://www.rhaco.org/
でも、正直おなかいっぱいというかんじ。
3大フレームワーク(Cake, Symfony, ZF)+1(CodeIgniter)で十分という気も
0006nobodyさん
2008/02/09(土) 17:36:48ID:???ごてごてとしたフレームワークをごそっと入れるんじゃなく、
ファイル一枚か少数で完結したフレームワーク・・・
だが、命令などに互換性があり、必要になった時点で、
フルセットのフレームワークに容易に入れ替え可能。
0007nobodyさん
2008/02/09(土) 19:08:55ID:???今SimpleTestを使ってテストしています。
SimpleTestにはWebTestCaseといってあたかもブラウザで
アクセスしたかのように、ウェブページに対してhttpプロトコルで
接続・・・その結果をテストということができるのですが、
このメール版はないでしょうか？
つまり、自分のPHPアプリからメール送信・・・そしたら（仮想の）テスト用メールサーバーにメールがたまり、
テストコードから、メールサーバーに来たメールを見てアサーションや、そのメールに書かれているリンクを
クリックなどしてテストを続行という、一連の処理にメールが入る場合のテストの自動化をしたいのです。
なにか良いライブラリ、良い手は無いでしょうか？
0008nobodyさん
2008/02/09(土) 20:29:30ID:???なんか良い手あるなら俺も知りたい
00097
2008/02/09(土) 20:29:50ID:???00107
2008/02/09(土) 23:11:53ID:???ちなみに、Windowsで使うときの注意点です。
SimpleMailがSMTPサーバーとしてFakeMailを使用するので別途インストールする必要があります。
perl版は必要なライブラリが入れづらいようなのでpython版を使いました。
python版はWindows版があるのでインストーラーで簡単に入れられます。
あらかじめpython自体も入れておく必要があります。
http://www.lastcraft.com/fakemail.php ここに情報が少し書いてあります。
fakemailerを起動するときは、インストールしたフォルダで、
> fakemail.py --host=localhost --port=10025 --path=.
でいいのですが、そのままではエラーになりました。
エラーメッセージを見ると、「signal.SIGHUP」が定義されていないそうです。
どうせテストだし、あまり重要なものではなさそうなので、削除しました。
> for sig in (signal.SIGINT, signal.SIGTERM, signal.SIGHUP):
↑fakemail.pyの中の「, signal.SIGHUP」を消す。
SimpleMailにはstart()メソッドでfakemailを実行する機能があるのですが、
Linux/Unix用のパスで、perl版のコードの上、fakemail.pyをバックグラウンドで
実行しようとすると、forkなんたらのエラーが発生するのであきらめます。
start()、stop()メソッドを呼ばなくても使えます。
その代わり、テスト開始前にfakemailerを起動しておきましょう。
0011nobodyさん
2008/02/10(日) 02:22:40ID:???perlはperl.exeしか入ってなくて子飼弾脂肪ｗｗｗ
0012nobodyさん
2008/02/10(日) 03:34:26ID:???0013nobodyさん
2008/02/10(日) 04:00:38ID:???フレームワークありすぎって意味？
0014nobodyさん
2008/02/10(日) 04:23:36ID:???デファクト・スタンダードになったフレームワークは標準で取り込んで、
言語仕様上の優遇を受けるんじゃないか、と思ってる
そうなったらこのフレームワーク地獄も終わるんじゃないの
政治的にZend Frameworkになるのかなと思ってるけど
0015nobodyさん
2008/02/10(日) 16:37:08ID:???一つに落ち着くことはないと思うけどね。
ちょうど.comみたいに、たくさん出てきて、いろいろ淘汰されて、
最終的に数個残るみたいになるんじゃないかなぁ。
ま、資金力や人気もあるからZend Frameworkは残りそうだけど
0016nobodyさん
2008/02/11(月) 03:33:18ID:???利点でもあり、欠点でもあるんだろうね。
ASP.NETのように誰も参入できないようにしてしまうと
選択肢が無い分すっきりとするが、その設計手法から
洩れてしまうと、言語など根本的な部分から変更せざるを
得なくなってしまう。
0017nobodyさん
2008/02/11(月) 20:35:51ID:???linuxカーネルに穴があってPHPもちろん脂肪ｗｗｗ
0018nobodyさん
2008/02/12(火) 14:36:51ID:???0019nobodyさん
2008/02/12(火) 18:06:57ID:???JavaだとSpring Web Flowに近いと思うけど、LightweightだとほとんどがFront Controllerだから、
なかなか野心的でないかと思っている。
0021nobodyさん
2008/02/12(火) 19:45:13ID:???ただ、Piece_ORMのinsertのテーブルデフォルト値の扱いが未だに納得がいかん。
もう少し説明をしてくれればな・・・
0022nobodyさん
2008/02/13(水) 00:59:29ID:???0023nobodyさん
2008/02/13(水) 09:03:46ID:???それぞれのモジュールが個別に使えるようになっているみたいだし、
そのうち既存のアプリにPiece_Flowを組み込んでみたいと思ってるんだよね。
（今はORMとRightはドキュメントがあるけど、Flowの方はちょっと…なので）
少しだけcakePHPをかじってみたけど、まだ日本語のドキュメントが十分とは言い難いし。
0025nobodyさん
2008/02/13(水) 12:07:10ID:???これから始めるなら、php4対応は気にしなくてもいいんじゃない？
俺はまだまだ業務で４を引きずるから、cakeとethnaだけど。
0028nobodyさん
2008/02/14(木) 00:48:59ID:???多分組み方にコダワルやつはZendを使って苦労したがるのだろう
0029nobodyさん
2008/02/14(木) 01:42:15ID:???どう考えてもsymfony。作りこみが他の比じゃない。
そもそも全体が太るのを避けるならFWなんて使うべきじゃない。Rasmasのやつ使え。
0031nobodyさん
2008/02/14(木) 02:30:57ID:???そのせいで痒い所に手が届かない部分が、
フル装備のsymfonyやcakeに比べると物足りなく思える。
ZFは言ってみれば、
軽量な骨組みに綺麗なクラスライブラリを置いてある感じ。
というのがZFについて人から聞いた話。
0032nobodyさん
2008/02/14(木) 02:35:13ID:???0033nobodyさん
2008/02/14(木) 10:57:40ID:???0034nobodyさん
2008/02/14(木) 11:16:32ID:???0036nobodyさん
2008/02/14(木) 20:03:37ID:???mb_encode_mimeheaderはmb_internal_encodingが必要って見たけど
PHP4の稼働してるバージョンじゃそれでもだめだったし
自分でヘッダ組み立ててmailで送るしかないじゃん・・・('A`)
0037nobodyさん
2008/02/14(木) 22:00:33ID:???ただ、引数指定にはいろいろノウハウがあったような…
単純にテキストメール送るだけなら、楽なことは楽。
0038nobodyさん
2008/02/14(木) 22:01:07ID:???フレームワークにメールモジュールないの？
0039nobodyさん
2008/02/14(木) 22:52:13ID:???特に洋モノは。
南蛮人に極東のマイナー言語のサポートなんか期待できないのは
当然っちゃ当然だが
0040nobodyさん
2008/02/15(金) 00:58:46ID:???UTF-8通らないサーバとかメールクライアントとかはもう無視する方向で行きたいな。
（どのみちそっちの方向にしか進まないんだから）
0041nobodyさん
2008/02/15(金) 02:02:23ID:???そのせいでmb_encode_mimeheaderも腐ってるし
いつの時代の仕様なんだっての
0042nobodyさん
2008/02/15(金) 03:18:39ID:???mail関数のサブジェクトの説明には「改行を含んではいけません。」って書いてるし、
実際サブジェクトを適当な文字数で区切ってbase64エンコードした場合と
まったく区切らずにbase64エンコードした場合の結果が
gmail,shuriken,docomo(foma)で同じだったし
恐らく今のクライアントだったらほとんど問題ないだろう。
mb_encode_mimeheader的な区切り処理は
むしろ何かと害があるんじゃないか。
0043nobodyさん
2008/02/15(金) 03:25:30ID:???mb_send_mailの存在意義が分からないな。
出来ないことを出来ると見せかけるという意味で
むしろ悪影響の方が大きい
前もってmb_internal_encodingを設定しろとか
バッドノウハウが広まってること自体がおかしいだろ
常識で考えて
0044nobodyさん
2008/02/15(金) 11:46:50ID:???0045nobodyさん
2008/02/15(金) 21:41:50ID:???・・・仕様が半端だしあちこちで不具合が出るから結果的にはある程度知らなきゃいけないんだがｗ
本当に半端な関数で、こんなもの実装するくらいならPEARででもまともなMailクラスを育てればいいのに。
0046nobodyさん
2008/02/15(金) 22:11:53ID:???mail関数じゃダメなのか？ というか何が問題でmb_send_mailが出来たんだ？
調べろと？ そうですなｗ
とりあえず、subjectはISO-2022-JPにしたあとbase64エンコードしている。
本文はISO-2022-JPにしている。
これでmail関数使っているが、なにか罠があるのか？
0047nobodyさん
2008/02/15(金) 22:18:51ID:???> つーか、ここはフレームワークスレじゃん。
> フレームワークにメールモジュールないの？
じゃあ、フレームワークに絡める。
CakePHP 1.2にはメールモジュールEmailComponentがあるのだが、
このモジュール。mb_send_mailではなく、mail関数を使っている。
当然日本語とか考慮されていない。
charsetというプロパティはあるにはあるのだが、これだけじゃうまくいかない。
なので、EmailComponentを継承して__encode、__renderTemplateメソッドを
オーバーライドしてエンコードおよび、半角カナなどを変換しているよ。
0048nobodyさん
2008/02/15(金) 22:22:04ID:???mb_send_mailの挙動が変だから
ずっとメールに対して奇々怪々なイメージがあった
やってみればたいして難しくないんだが。
mailを直接触る方が健康的だな
0049nobodyさん
2008/02/16(土) 20:07:48ID:???CLIが速いスクリプト言語って何？
0050nobodyさん
2008/02/17(日) 00:10:17ID:???0051nobodyさん
2008/02/17(日) 11:55:49ID:???0052nobodyさん
2008/02/17(日) 19:25:33ID:???マジレスすると Perl
Ruby は普通
Python はかなり遅い
起動の早さはバイナリサイズによるところも大きくて、awkやluaのようにバイナリが小さいものだとPerlよりも起動が早い。
0053nobodyさん
2008/02/18(月) 20:19:24ID:???Perlの本買ってきた
Perlは糞記号が多いな
$にいろんな意味持たせすぎ。
こういうタイピング時点での節約がなんか前時代的
CLIのスクリプトってフレームワークの階層のどこに置けばいいんだろ？
0054nobodyさん
2008/02/18(月) 20:41:46ID:7b3e8wHYもうおそいか
0055nobodyさん
2008/02/19(火) 01:36:48ID:???0057nobodyさん
2008/02/19(火) 05:15:52ID:???shなんて単純なものしか書きたくないし
そうなるとPerlは充分妥当な線だろ。
スクリプト言語の中ではPHPに一番近いし。
0058nobodyさん
2008/02/19(火) 05:27:17ID:???速度がいらない処理（scaffolding等）はPHPで全然問題ないけどね
0059nobodyさん
2008/02/19(火) 07:47:46ID:???ここの結果だとPythonの方が速いけど。
まあ、当たり前だけど目的による。
なんで盲目的にPerlが速いといえるのかがわからん。
0060nobodyさん
2008/02/19(火) 12:02:30ID:???use Encode;
use CGI;
use Data::Dumper;
とかやると結構違うんじゃね？
結局CLIの起動速度とか、言語の選択にそれほど影響する場面ってあるか？
まあRubyは結構がつんと引っかかるのを感じることはあるけど
0061nobodyさん
2008/02/20(水) 03:45:15ID:???extで話が済んでるうちは、荒っぽくいえばCのWebフレームワークなわけだし。
rubyとか今やRailsないとWebアプリ作れねーんじゃねーかと。
0062nobodyさん
2008/02/20(水) 08:15:36ID:???rails作った奴も神だな
神と神が合体して偉大なるソフト
0063nobodyさん
2008/02/20(水) 08:57:52ID:???0064nobodyさん
2008/02/20(水) 11:16:03ID:???0065nobodyさん
2008/02/20(水) 16:36:10ID:???神と神を合体させると何が出来るのですか？
http://members.jcom.home.ne.jp/sss-3/shin3/shin3_gdevil.html
006624
2008/02/20(水) 18:10:02ID:???じゃあ、質問を変えてajax（というより、DHMLメイン？）前提ではどれが作りやすいかな？
たとえば、xhrを用いた非同期通信をサポートする上での仕様が覚えやすいとか、
prototype.js系に限らずほかのJSライブラリ（dojo系やYahooUI系）でも利用可能な仕様が公式側で用意されているとか。
0067nobodyさん
2008/02/20(水) 21:07:41ID:???別途jQuery叩いてて不満ないのでフレームワーク側のAJAXサポートとか評価したことない。もちろん手間はある
識者のお勧め希望
0068nobodyさん
2008/02/21(木) 00:14:33ID:???システム周りのちょっとした作業するのに使われてるのRubyばっかだな
逆にPythonはあんまり見ない
Ruby知らないとイモって言われる時代もすぐそこか・・・(´・ω・`)
0069nobodyさん
2008/02/21(木) 00:38:11ID:???なんか前スレのJaxerを彷彿とさせる流れだ
サーバサイドとフロントエンドをそれほど上手に連携させていて、しかも汎用的な
フレームワークとかまだそんなに無い雰囲気だけど、あるなら俺も知りたい
強いて言うなら、RubyはJavaScriptと近い記述も可能な印象があるので、スクリプトを
組む人間の脳みそ的に楽かも知れない。
オブジェクトやブロックの扱いとか、記述の柔らかさというかその辺で、少なくとも、PHP
よりは感覚が近いような
なんだこの印象論はと書いてて自分で思った。
0070nobodyさん
2008/02/21(木) 00:56:06ID:???まあ確かになんでもかんでもオブジェクトでござい、てあたりは似てるね
0071nobodyさん
2008/02/21(木) 01:12:47ID:???いいかえればキリストとアッラーが融合合体した「究極生命体」
0072nobodyさん
2008/02/21(木) 01:17:10ID:???0073nobodyさん
2008/02/21(木) 01:18:32ID:???バカとバカが合体すると子供が生まれる
0076nobodyさん
2008/02/21(木) 02:54:43ID:???GNOME周りの細かいスクリプトってPythonばっかでしょ？
海外でRuby使っている人ってRoRの流れの人じゃないかな
正直なところ、RoRは偉大だと思うけどRubyはそうは思わない
「RoRのプログラマに選ばれた言語」として評価はするけど
0077nobodyさん
2008/02/21(木) 12:49:51ID:???Google SketchUpのRuby
PHPをスクリプト言語として搭載した色物3DCGソフトがあったら色んな意味で面白そうだ
0078nobodyさん
2008/02/21(木) 13:39:33ID:???ずぅっと混戦状態な気もするけど。
案外Webだけに的を絞ったPHPが一番長生きだったりしてね。
でも10年後、PHPの役目が今のCOBOL的な負の遺産管理とか、そういう生き残りかたはやだな。
0079nobodyさん
2008/02/21(木) 14:20:40ID:???その間を埋める新しい言語が出てくるんじゃないの
一方extract($_POST);的なコードはいつまでも再生産されるっていう
0080nobodyさん
2008/02/21(木) 16:47:46ID:???http://pecl.php.net/package/python/download/0.8.0/
0081nobodyさん
2008/02/21(木) 18:22:05ID:???外人が大量にやってるからRuby始めました
YAMLが簡単に扱えてｲｲ(･∀･)！
0082nobodyさん
2008/02/21(木) 18:47:15ID:???これよりも簡単に扱えるん？
http://itpro.nikkeibp.co.jp/article/COLUMN/20070507/270080/
PHP版がこのコード↑として、Ruby版はどういうコードなん？
0083nobodyさん
2008/02/21(木) 19:00:50ID:???file_dir = './hoge.conf'
str = open(file_dir).read()
data = YAML.load(str)
こんなん
もっとキレイに書けるのか知らないけど。
コード自体はたいして変わらないか。
でも変なパースされてハマったことあるからspycにはいい印象ないな
0084nobodyさん
2008/02/21(木) 19:09:48ID:???0085nobodyさん
2008/02/21(木) 19:19:43ID:???YAMLライブラリが標準添付されているって言うべきだな。
0086nobodyさん
2008/02/21(木) 19:23:34ID:???[追加部分前半](元の文)[追加部分後半]
って分かれるのが普通だけど
Rubyだと
（元の文）[追加部分]
で済むのが気持ちええ～
多重に追加する時も
（元の文）[追加][追加][追加]
って書いていけるのがオルガスムス(´ρ｀)
0087nobodyさん
2008/02/21(木) 19:40:27ID:???0088nobodyさん
2008/02/21(木) 19:43:13ID:???地味だがjQueryハマってるので気持ちは判る
しかしスレ違いではないか
0089nobodyさん
2008/02/21(木) 20:06:49ID:???よっぽどPHPのフレームワークにネタがないのか
0090nobodyさん
2008/02/21(木) 21:58:56ID:???どこにあるんだよｗ
0091nobodyさん
2008/02/22(金) 09:46:47ID:???>http://www.timestretch.com/FractalBenchmark.html
>
>ここの結果だとPythonの方が速いけど。
>まあ、当たり前だけど目的による。
>なんで盲目的にPerlが速いといえるのかがわからん。
>>49と>>52よく読め。起動時間の話をしてるのに違うベンチマーク結果だしてどうする。
>>82
SpycはまともにYAML扱えないから止めた方がいい。いくらなんでも機能低すぎ。バグ大杉。しかもクソ遅い。
0092nobodyさん
2008/02/22(金) 12:35:59ID:???0093nobodyさん
2008/02/22(金) 12:47:30ID:???0094nobodyさん
2008/02/22(金) 15:13:53ID:???そんなに悪いとは思えないが？
0095nobodyさん
2008/02/22(金) 15:16:53ID:???0096nobodyさん
2008/02/22(金) 15:19:12ID:???0097nobodyさん
2008/02/22(金) 15:25:54ID:???ヘビーに使おうと思うとあきらかに役者不足だよ。
0098nobodyさん
2008/02/22(金) 15:37:27ID:???だいたいyamlなんて設定ファイルで使うケースがほとんだと思うが
遅いって言っても実環境で使うなら普通キャッシュするし
機能低いとかヘビーに使うとか一体どういう局面で困ってるの？
0099nobodyさん
2008/02/22(金) 16:34:52ID:???通常は設定ファイル程度に使わないか？
そういうのは一度キャッシュしてしまうだろうし。
（ってろく読まずに書いたら>>98も同じこといってるじゃんｗ）
0100nobodyさん
2008/02/22(金) 17:13:10ID:???symfonyってsyckとかいうの使うようになったんじゃなかったけ？
0101nobodyさん
2008/02/22(金) 17:18:54ID:???いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
0102nobodyさん
2008/02/22(金) 17:31:08ID:???web+db pressの個人的タイムリー感は異常
0103nobodyさん
2008/02/22(金) 17:33:55ID:???「起動が速くてもインクルードで遅れたら」のtypo?
0104nobodyさん
2008/02/22(金) 18:29:49ID:???>いや、起動が遅くてもインクルードで遅れたら意味ないでしょ？
>だから、「目的による」と書いてあるの。それ以上は自明だと思ったから説明しなかっただけで。
起動の速さを話題にしているんだから、それ以外の要素を持ち出すならそれを説明すべきだろ。
>>49,52,59を順に読んでみろ。どこにインクルードやrequireの話がでている?
「目的による」のひとことで分かるわけがない。おまえの脳内で勝手に補完するな。
>それについては、Perlでもインクルードするモジュールによると他の人も書いてるでしょ。
それは>>60からだろ。60はちゃんと説明しているが、59まではそんな話でてきてない。時系列を無視して語るな。
>この人は意図をよく理解してる。あなたはもう少しよく考えましょう。
おまえこそもう少しよく読め。
0105nobodyさん
2008/02/23(土) 21:58:54ID:???YAMLって結構高機能なんだな～
0106nobodyさん
2008/02/24(日) 09:22:41ID:???0107nobodyさん
2008/02/24(日) 11:54:48ID:???仕様を見ればわかるがな
0108nobodyさん
2008/02/24(日) 19:48:11ID:???Rubyの手のひらの上で暴れてるだけのPHP乙
0109nobodyさん
2008/02/24(日) 20:10:52ID:???PHPのプロダクションてほかの言語からの輸入物多いからいまさらそんなん言われても
0110nobodyさん
2008/02/24(日) 23:46:30ID:???0112nobodyさん
2008/02/25(月) 03:41:00ID:???0113nobodyさん
2008/02/25(月) 10:52:39ID:???0114nobodyさん
2008/02/25(月) 14:43:04ID:???0115nobodyさん
2008/02/26(火) 00:07:04ID:/Sycx4p+0116nobodyさん
2008/02/26(火) 00:42:37ID:???0117nobodyさん
2008/02/26(火) 02:09:18ID:???今までＰＨＰでいくら稼いだんや？
0118nobodyさん
2008/02/26(火) 02:10:31ID:???しかしネゴシックスは県民の恥さらし
0119nobodyさん
2008/02/26(火) 02:13:42ID:???島根県民だから同県民として素直にうれしいし
松本も地元に愛着を持ってるらしく
Ｒｕｂｙ検定やら松江を発信基地として活動してくれる
0120nobodyさん
2008/02/26(火) 02:15:05ID:???0121nobodyさん
2008/02/26(火) 02:39:30ID:???いい加減書き込むときはスレタイぐらい読めよ
0122nobodyさん
2008/02/26(火) 08:59:32ID:???確かに書きやすいしPHPに比べるときれい
でも肝心のRails環境があまり無い
実用面ではPHPがNo.1だと思います
それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
0123nobodyさん
2008/02/26(火) 16:01:26ID:???>それで質問ですが、最もRailライクなフレームワークはSymfonyでよろしいでしょうか？
YES
>この1ヶ月の勉強の知識でそのままPHPフレームワークに移行したいのです
その判断は誤りだといっておこう。
PHPはRubyと比べてできないことが多いから、PHPでRailsを真似てもたいしてうまくいかない。
0126nobodyさん
2008/02/26(火) 20:38:57ID:???0128nobodyさん
2008/02/26(火) 22:30:12ID:???Railsに最も近いのは、現状でいえばakelos
でも、Railsがベストなわけじゃないってのは認識したほうが。
symfonyはRailsよりリッチ。いい意味でも悪い意味でも。
0129nobodyさん
2008/02/26(火) 22:47:06ID:???akelosだけど現実的に考えるとsymfonyだろう
リッチってなんだよリッチって曖昧過ぎるだろ
0130nobodyさん
2008/02/26(火) 23:46:19ID:???symfonyの方がエンタープライズ向けな感じはする。
0131nobodyさん
2008/02/26(火) 23:56:03ID:???簡潔な記述もそうだけど、PHPはメタプログラミングが弱いんだよ。
Rubyはそこが強力で、だからこそActiveRecordみたいなのが実現できる。
ActiveRecordがほんとに望ましいものかどうかは別として。
0132nobodyさん
2008/02/27(水) 00:00:57ID:???0133nobodyさん
2008/02/27(水) 00:03:44ID:???0134nobodyさん
2008/02/27(水) 01:13:23ID:???PHPの言語仕様がRubyよりも少ないのはわかるけどさ、
それで開発をする上で何ができないということなの？
0136nobodyさん
2008/02/27(水) 09:27:49ID:???akelosも十二分に実用だと思うよ。
http://pc11.2ch.net/test/read.cgi/php/1187333485/
http://www.akelos.org/docs/tutorials/booklink-ja
http://www.akelos.org/
http://blogs.atanaka.biz/tanaka/index.php?catid=18&blogid=2
http://blog.takeda-soft.jp/blog/category/17
http://blog.hakuja.jp/articles/tag/akelos
http://d.hatena.ne.jp/simpraight/searchdiary?word=%2a%5bAkelos%5d
0137nobodyさん
2008/02/27(水) 21:44:16ID:???akelosは>>136の上から5番目のブログ見て良さげと思った
0138nobodyさん
2008/02/28(木) 13:46:19ID:???・RDB使わずテキストの場合
ちいたん（ちょっと改造）
・PHP4でRDB使う
ちいたん（ちょっと改造） + PieceORM
・PHP5でRDB使う
symfony
こんな感じ
0139nobodyさん
2008/02/28(木) 13:51:16ID:???キツい・・。perlにするかな。
0140nobodyさん
2008/02/28(木) 17:43:37ID:???その環境のPerlも当然バージョンが古く、
そのバージョンのPerlに対応しているフレームワークも無い。
0142nobodyさん
2008/02/28(木) 19:18:01ID:???pakeがあるし、普通に雑務タスク書く分にはpakeでもわりと使えるよ
まあrakeみたいにDSLっぽく書けない、という意味で書いてるんだろうけども
0143nobodyさん
2008/02/28(木) 19:27:24ID:???提供すれば、ほぼ同等のことが出来る。
違った形での実装、使い方になるだろうが、どちらを使っても
普段の仕事で使う分には大差がない。
大差があれば、われわれは○言語を使うから、
大幅に工数が減って、結果、”安く”作れます。といえるはずだろう？
安く作るって事は給料が減るわけだが、本当に工数が減るのなら問題ないはずだ。
実際は工数が減らないから「優れた言語を使うから安く作れる」なんて話を聞いたことが無い。
0144nobodyさん
2008/02/28(木) 20:48:04ID:???どちらを使っても大差がないんだと思うなら
優れた言語使えばいいんじゃないのと思うがｗ
相手も同種のベンダーとかじゃない限り、
顧客にとっちゃどんな言語使ってようがあまり関係がない
「われわれは○言語を使うから云々」とか意味不明
安いのどうのっていうのは見積判断次第なわけで
工数とコストが比例するのが前提っておかしいだろう
0145nobodyさん
2008/02/28(木) 20:53:41ID:???0146nobodyさん
2008/02/28(木) 20:54:47ID:???＞工数とコストが比例するのが前提っておかしいだろう
上記の「コスト」は見積もり、のこと？
この業界の最大のコストは人件費なんだから、コストは素直に比例でいいんじゃね？
まあ商用パッケージ等を使うこととかは別問題だけど、それでも「工数」を比較的上手に
コストと交換しているみたいなもんだし。
まあ、見積もりは別だ。 ・・・でもあんまり無茶なダンp(ry
0147144
2008/02/28(木) 21:09:31ID:???コストじゃねー見積orz
工数とコスト（経費）が比例しなかったらまずいｗ
俺が意味不明だった
内部的な工数の変化と外部への見積とはまた別だろう的な
意味で書いたつもりだったけど変な文章になってた
0148nobodyさん
2008/02/28(木) 22:37:10ID:???フレームワークを使うと、工数も作りやすさも変わらない罠。
なぜかというと、フレームワークを使うとビジネスロジックに専念できる。
そのビジネスロジックでは高度な言語機能なんて使わないから
0149nobodyさん
2008/02/28(木) 23:57:02ID:???それどころか、コピペで作られたシステムじゃないと、修正した場合の影響範囲が大きくなるから嫌がられる。
変更箇所が多くても土方仕事の方が良いというプロマネは多いはず。
土方仕事なんだから、職人技が使えないのは当然。
0150nobodyさん
2008/02/29(金) 02:19:49ID:???それどころかPerl5以降なら、たいていそのまま動くよ。15年前のリリースだけど。
0151nobodyさん
2008/02/29(金) 10:50:18ID:???0152nobodyさん
2008/02/29(金) 12:09:50ID:???まだまだ時期が早い。
symfonyだよな、
春くらいに大手サイトでのsymfony採用実績がどんどん発表されるのを
知ってる人は少ないだろうな
0153nobodyさん
2008/02/29(金) 12:11:59ID:???長い期間でsymfony独占だろうな
規模でかいフレームワークが乱立することは、マズ無い
会社を上げてその競争に入るのに多大なコストがかかる
0154nobodyさん
2008/02/29(金) 13:21:45ID:???>大規模で使えるフレームワーク
これってなにをもってそういってるの？
大規模って何が大規模？大規模向けにsymfonyがもっていて他がもっていない特徴って何？
0155nobodyさん
2008/02/29(金) 15:41:39ID:???なにかアンチをひきつける要素があったのか
0156nobodyさん
2008/02/29(金) 18:20:40ID:???ここでいう大規模てのは人それぞれだからね
あえて俺が境界定義する必要はない
大規模に向けにある機能といったら
Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
0157nobodyさん
2008/02/29(金) 18:24:46ID:???えらく特化された大規模向け機能だな
よっぽど小回り利かないFWを使ってるのか
0158nobodyさん
2008/02/29(金) 18:26:58ID:???0159nobodyさん
2008/02/29(金) 19:55:13ID:???あとは開発者数ってのもある
>>156
>Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
これもうちょっと詳しく説明できる？どんな機能で、どう大規模な開発で便利なのか。
0160nobodyさん
2008/02/29(金) 20:10:06ID:???＞Viewからコンポーネント、モデルに手軽にアクセスできる柔軟性
具体的に想像出来ないが、Viewからとりあえず Hoge::new とか Hoge::factory とか Hoge::singleton とか
Hoge::getInstance とかであらゆるオブジェクトを気軽に作成できて、またそうするのが前提で、みたいな？
すっごくネガティブな方向でしか想像できない。
なんか、上の方とか他に影響のありそうな所とかをいじらなくて済むから、お伺いを
立てずにとりあえず現場でなんでも出来る、うーん効率的、などなど
直行性を高く保って実現する、ていうことなのかな？DRYはある程度犠牲にして、ていう？
なんかふわふわｽﾏｿｗ
0161nobodyさん
2008/02/29(金) 20:57:56ID:???コントローラー様を介せよｶｽ
0162nobodyさん
2008/02/29(金) 21:05:30ID:???0163nobodyさん
2008/02/29(金) 21:12:31ID:???少し考えたが、Ethnaみたいになるのか？
どのオブジェクトもあらゆるオブジェクトを持ってるみたいな
Ethnaはもう循環参照で開き直ってるけどｗ
$this->af->ae->af->ae みたいな （← これはなかったかもｗ）
もしくは$this->backend->(永遠に続くオブジェクトループ) みたいな
っていうか、backendの範囲広すぎｗ
そこまでするんなら、もうオブジェクトそれぞれ$GLOBALSに置いておいて
変更は禁止で（変更するならcloneでもして）勝手にアクセスすればいいん
じゃね？とかいう気がすごくする。
0164nobodyさん
2008/02/29(金) 21:34:21ID:???は？5.8、5.10とリリースされてるんだけど。PHPみたいに0.1のバージョンアップでもう動かなくなる方がどうかしてる。
PHPの場合、間違いなくPHP4系、PHP5系、PHP6系が平行して使われていくだろう。
0165nobodyさん
2008/02/29(金) 22:14:57ID:???0166nobodyさん
2008/02/29(金) 23:02:18ID:???CとVがワンセットでコンポーネントされてる場合
コンポーネントで定義されてるV切り離してCだけ呼ぶことも出来るし
CとＶをワンセットで呼ぶことも出来る
この辺り便利
0167nobodyさん
2008/03/01(土) 00:01:06ID:???その説明じゃわからん。特に1行目と2行目。
コンポーネントされてる場合ってなんのことだ
CとVをワンセットで呼び出すってどういうことよ
0168nobodyさん
2008/03/01(土) 00:45:22ID:???意味を考えるなんて馬鹿だよな。
0169nobodyさん
2008/03/01(土) 14:08:24ID:???0170nobodyさん
2008/03/01(土) 23:54:17ID:???大規模フレームワーク symfony
CakePHPは作者がバカそう
0171nobodyさん
2008/03/02(日) 01:01:22ID:???悪口を言う気持ちは、わかります。
0172nobodyさん
2008/03/03(月) 17:23:19ID:???日本PostgreSQLユーザー会のWebページがクラックされてPHP脂肪ｗｗｗ
0173nobodyさん
2008/03/03(月) 18:05:14ID:???0174nobodyさん
2008/03/04(火) 00:15:16ID:???名前空間が入ることはもう確定っぽいけど、そういうのを使ったフレームワークとかはいつ頃出てくるんだろうか
普及すれば、フレームワークの書き方が思いっきり変わりそうな機能だけど、まだしばらくはお手本とかなさそう？
0175nobodyさん
2008/03/04(火) 02:04:28ID:???0176nobodyさん
2008/03/04(火) 03:18:14ID:???0177nobodyさん
2008/03/04(火) 14:37:23ID:???// import Zend::DB as DB
import MyFramework::DB as DB;
$table = new DB::Table();
として差し替える、とか。配布スクリプトがカオスになる可能性もあるな
0178nobodyさん
2008/03/04(火) 18:08:54ID:???個人的にはicuがどうなるかだな
まぁ時代はqiqってことで
0179nobodyさん
2008/03/04(火) 20:48:12ID:???gotoと名前空間を同列に語るなよ
程度が知れるぞ
0180nobodyさん
2008/03/04(火) 21:32:54ID:???0181nobodyさん
2008/03/04(火) 21:45:54ID:???無名関数・クロージャ・配列の構文糖衣 が主な拡張？
そんなに欲しかったのか？
0182nobodyさん
2008/03/04(火) 21:49:23ID:???0183nobodyさん
2008/03/04(火) 22:06:37ID:???0184nobodyさん
2008/03/04(火) 22:07:34ID:???・・・って別にいらないと言えばいらないし、むしろ必要なのは標準ライブラリかな
いい加減、メール送信とかDBアクセスとかに外部のライブラリをいちいち吟味って
結構めんどい。さっさと標準で十分にするんだ。
Zend Framework付属のライブラリ群がそうなる予定なのかも知れないけど、そうすると
PEAR2の立ち位置が微妙になるし。
PEAR2にZend Frameworkからのバックポートがあるんなら、それが良いのかも知れない
0185nobodyさん
2008/03/04(火) 22:52:02ID:???0186nobodyさん
2008/03/04(火) 23:05:45ID:???人たちや企業がまた慣れて旧態依然としたコードを乱発してしまう前にがんがん新機軸を
入れてしまえっていう、最後の機会かも知れない
0187nobodyさん
2008/03/05(水) 02:03:59ID:???0188nobodyさん
2008/03/05(水) 02:11:31ID:???0189nobodyさん
2008/03/05(水) 03:29:57ID:???俺が体験した範囲だと、4→5よりも古い4とlatestの4の間でコケて
5+ZFで作り直しってのがこの所多発
0190nobodyさん
2008/03/05(水) 04:22:14ID:???0191nobodyさん
2008/03/05(水) 07:13:06ID:???子供と同じ心理
0192nobodyさん
2008/03/05(水) 11:55:03ID:???0194nobodyさん
2008/03/05(水) 19:36:02ID:???0195nobodyさん
2008/03/05(水) 20:10:34ID:???別案件でばらばら投げられて苛々したけど、ZFでやれたので最終的にDB一本化はけっこう綺麗にいった
運用ベースで見たら古い環境って相当な数居るように感じるのよね
問題でない限り使い続ける（というかリプレースする理由がない）もんだし
0196nobodyさん
2008/03/05(水) 23:07:01ID:???古い４って脆弱性問題にならなかったのか
0197nobodyさん
2008/03/05(水) 23:16:55ID:???0198nobodyさん
2008/03/05(水) 23:20:10ID:???0199nobodyさん
2008/03/07(金) 02:17:48ID:???0201nobodyさん
2008/03/07(金) 09:49:44ID:???Windowsのセキュリティを語っているやつ死亡ｗｗｗ
0202nobodyさん
2008/03/07(金) 10:01:43ID:???オープンソースのWEBフレームワーク言語と、ソースの秘匿されている商用OSを同列に並べるのは
ちょっと無理があるんじゃね？
せめてLinuxにしとけよ
0204nobodyさん
2008/03/09(日) 02:17:33ID:???従ってPHP脂肪ｗｗｗ
0205nobodyさん
2008/03/12(水) 03:50:21ID:???http://jp2.php.net/manual/ja/ref.spl.php ?
0207nobodyさん
2008/03/13(木) 03:53:53ID:???if (式) {hoge()}
みたいな書き方出来ないのな
ブロック付きメソッドでは{}を使うのにifで{}使えないって何なの？
0208nobodyさん
2008/03/13(木) 04:08:48ID:???その {} を then end に変えるだけなんだがな
何なのって言われると、文法としか言いようが無さそう
PHPって hoge() if (式) って出来ないのな、ってなもんだ
MLで聞けばひょっとするとMatzが答えてくれるかも知れないよ
ってか、スレ違い
0209nobodyさん
2008/03/13(木) 04:17:52ID:???0210nobodyさん
2008/03/13(木) 07:21:58ID:???Matz & Dan : コンピュータサイエンスとしての知識が高まると
PHPに対して不満がでてくるかもよというのは予言しておきます（笑）
PHPER=コンピュータサイエンスとしての知識が低い人ｗｗｗ
0214nobodyさん
2008/03/13(木) 18:49:20ID:???0216nobodyさん
2008/03/13(木) 21:40:53ID:???違う
if文はrubyでいう意味の「ブロック」じゃない
rubyのifやwhileやforはスコープを持たない
だからdo～endの代わりにブレスが使えない
eachのようにブロック付き呼び出しで使うのがブロック
こちらはブロックスコープを持つ
0217nobodyさん
2008/03/13(木) 23:01:09ID:???0218nobodyさん
2008/03/14(金) 05:52:57ID:???Rubyにおいてはブロック付メソッドが例外で
それ以外ではカーリーブラケットは使わないってことか
Cに喧嘩売りすぎワロタ
0219nobodyさん
2008/03/14(金) 16:06:52ID:???0220nobodyさん
2008/03/14(金) 16:16:37ID:???0221nobodyさん
2008/03/14(金) 17:48:44ID:???アクセラレータじゃなくね
0222nobodyさん
2008/03/14(金) 18:10:09ID:???すべての言語が統一されればいいのに・・・
0223nobodyさん
2008/03/14(金) 18:41:06ID:???バッドノウハウ頼みな制限や変態仕様が全ての言語から根絶されたら素敵だろうなあ
0224nobodyさん
2008/03/14(金) 18:44:08ID:???0225nobodyさん
2008/03/14(金) 18:44:37ID:???0227nobodyさん
2008/03/14(金) 21:58:17ID:???PHP=光秀
Python=秀吉
Ruby=家康
PHPERﾃﾗ三日天下ｗｗｗ
0230nobodyさん
2008/03/14(金) 22:25:17ID:???0231nobodyさん
2008/03/15(土) 00:01:12ID:???PHP＝トラブルｗ
LAMPセキュリティ問題の主犯ｗｗ
人知れずPHP3やPHP4を使い続けているサイトはたくさんｗｗｗ
もはやキリシタンみたいな扱いだな
0233nobodyさん
2008/03/15(土) 00:13:21ID:???そのサイトはひどい釣りにしか見えんな
確かに、既存サーバのPHPが硬直してしまっているっていうのは必要な指摘だとは思うんだけど、
その書き方が突飛と言うか無理過ぎるというか、とにかく説得力がない
例えば
＞Apacheのmod_phpを使ってPHPをApacheモジュールとして実行すると、Apacheプロセスの
＞すべての資格情報がPHPに引き継がれます
って、SuExec等を使わない限り、Perl、Ruby、Python等のCGIでも同じっていうことに言及しない
のはどうかとも思う。他にもいろいろ、わざとかも知れないけど香ばしい
0234nobodyさん
2008/03/15(土) 00:14:31ID:???0236nobodyさん
2008/03/15(土) 08:30:08ID:???0237nobodyさん
2008/03/15(土) 16:57:53ID:???0238nobodyさん
2008/03/15(土) 17:23:26ID:???apacheのsuexecの説明見たら
suEXEC の設定には管理者の詳細にわたる慎重な注意が必要
とか書かれてｺﾜｽ
0239nobodyさん
2008/03/15(土) 18:23:12ID:???0240nobodyさん
2008/03/15(土) 18:30:06ID:???てことはモジュール版のPHPは普通にapacheの権限で実行される？
0241nobodyさん
2008/03/15(土) 20:29:23ID:???ってことは、suexecが必要になるのって
不特定多数のユーザにリソースを貸すサーバ屋さんくらい？
0242nobodyさん
2008/03/16(日) 00:45:11ID:???ほぼApacheモジュールで動いているのと同じなわけで、
Apacheモジュールで動くということは、Apacheの権限で動いているわけで、
PHPを使えば、Apache権限になれるから、
Apache権限で読み出せる他ユーザーのファイルを読み出せるからな。
0243nobodyさん
2008/03/16(日) 21:39:19ID:9hRtdL6Rapc.include_once_overrideで解決できるんじゃね？
0244nobodyさん
2008/03/16(日) 23:14:35ID:???Ruby脂肪ｗｗｗ
0245nobodyさん
2008/03/23(日) 05:33:05ID:???PHP=光秀
Python=秀吉
Ruby=隠れキリシタンｗｗｗｗｗｗｗ
0246nobodyさん
2008/03/23(日) 12:01:53ID:???0247nobodyさん
2008/03/23(日) 12:28:04ID:???0248nobodyさん
2008/03/23(日) 15:47:03ID:???.htaccessに書いたらしなくなったけど。
mbstring系の設定はphp.iniか.htaccessでするって常識？
0249nobodyさん
2008/03/23(日) 16:40:24ID:???まだ見習い中なのでとりあえずphpに慣れてもらおうと課題を出したのですが、
何日たっても報告にこないのでついさっき報告をあげさせると共に指針を与えた所でした。
mbstringが、mbstringがと、説明が要領を得なくて時間がかかったのですが、
どうやらmbstring.languageをスクリプト中で指定しようとしていたらしく、
マニュアルで確認するように伝え、日々日報に問題点を記述するように厳しく指導いたしました。
今後このような事が無いように指導を行い、
また、ご迷惑をおかけしましたことをお詫び申し上げます。
0250nobodyさん
2008/03/23(日) 16:51:02ID:???0251nobodyさん
2008/03/23(日) 19:26:02ID:???誰も言わなかったじゃん
ちゃんと説明しろよ249のハゲ
0252nobodyさん
2008/03/23(日) 20:55:07ID:???0253nobodyさん
2008/03/23(日) 21:23:45ID:???0255nobodyさん
2008/03/23(日) 21:48:36ID:???0256nobodyさん
2008/03/23(日) 22:31:41ID:???まあ汎用的ではあるな。一度しっかりとモジュールを作ってしまえばいいわけだし
というわけで、マルチバイトや添付ファイル、HTMLメールにがっつり対応したメールモジュールのある
フレームワークの紹介よろしく！
0257nobodyさん
2008/03/23(日) 22:35:47ID:???あとPOP before SMTP と SMTP Auth にも当然対応しているという奴かな
どこにでも転がってそうだけど、一つばっちりした物があればそれでいいんだし
0260nobodyさん
2008/03/23(日) 22:52:37ID:???0261nobodyさん
2008/03/23(日) 23:09:14ID:???わざわざSMTP叩く奴なんなの？変態なの？
0262nobodyさん
2008/03/23(日) 23:32:43ID:???MTAはMUAの間違い？（sendmailコマンドの様な）
PHPの関数インターフェイス(mail(), mb_send_mail())もMUAと言えなくもないのかな
でも、外部SMTPサーバを使いたい時も同様に扱えるから初めからMTAのサーバを
ソケットから叩くっていうのはそんなにおかしくないと思うけどな
そりゃいちいちpopenとかベタベタでやるのは変態っぽいけど、ライブラリになっていれば
そんなに手間でもないと思うし、PHPの関数叩くのとやってることは大して変わらないと思う
0264nobodyさん
2008/03/24(月) 00:44:07ID:???外部にメールサーバがある場合か
なるほどね
0265nobodyさん
2008/03/24(月) 00:53:41ID:???0266nobodyさん
2008/03/24(月) 01:03:45ID:???んで、sendmailで添付ファイルを送るにはどうすればいいんだ？
0267nobodyさん
2008/03/25(火) 15:59:11ID:???添付ファイルを処理させるのはおかどちがいだろう。
まぁ適当にmultipartなメールをでっちあげてください。
>>262
MUAって、MDAが落としたメールとかも読めなきゃいけないんじゃない?
たぶん、あれをMUAとは言わんような...どっちでもいいけど。
どっちも/sbin/sendmailだからややこしいな。
0268nobodyさん
2008/03/29(土) 02:49:42ID:???http://www.ibm.com/developerworks/jp/opensource/library/os-php-fwk5/?ca=drs-jp
3大フレームワークでのバッチ処理についての記事。
このシリーズは正にこのスレ向けだね。
0269nobodyさん
2008/03/30(日) 17:45:17ID:???例外だとApacheのエラーログに残らないのが難だな
フレームワークのログには残るけど。
Apacheのエラーログ見ながらテストってよくやるし、
そこで例外が確認できないのはイケてない。
0270nobodyさん
2008/03/30(日) 18:05:39ID:???FWの一番上層のtry～catchで
error_log($exception->getMessage());
しておけばいい
mod_phpならapacheのerror_logに吐かれる
自分で例外をハンドリングもせずに例外が難だな、とか言われても
0271nobodyさん
2008/03/30(日) 19:45:47ID:???>FWの一番上層のtry～catchで
その部分はFWが提供していて書き換えられない・拡張できない場合がほとんどだろ
自作FWじゃないんだから
0272nobodyさん
2008/03/30(日) 19:55:44ID:???0273nobodyさん
2008/03/30(日) 22:07:54ID:???FW全域に渡ってのエラーハンドリングできないFWもアレだと思うし
仮にできなくてもブートストラップになるdispatch部分をtry-catchしたらいいし
それもいやならexception_handlerだってあるしやり方はいくらでもあるよ
0274nobodyさん
2008/03/30(日) 22:31:58ID:???0275nobodyさん
2008/03/30(日) 23:06:10ID:???0276nobodyさん
2008/03/30(日) 23:37:57ID:???0277nobodyさん
2008/03/30(日) 23:45:40ID:???HTTPヘッダやスタックトレースを出したりできるしな。
なんで不便なapacheログに頼るのだろう？
0278nobodyさん
2008/03/31(月) 01:07:38ID:???fwのログではリソースへのリンクミスは分からない
どこかひとつにまとめておくならapacheログになる
0280nobodyさん
2008/03/31(月) 02:58:55ID:???0281nobodyさん
2008/03/31(月) 03:01:14ID:???0282nobodyさん
2008/03/31(月) 13:35:52ID:q29QDC7Uテンポラリテーブルやサブクエリ使うような処理はどうなってるの？
出来るのはせいぜいリレーションまで？
0283nobodyさん
2008/03/31(月) 14:57:48ID:???テンポラリテーブルはORMの範疇じゃないと思う。
0285nobodyさん
2008/04/01(火) 00:51:46ID:???0286nobodyさん
2008/04/01(火) 01:29:08ID:???簡単に使うのが目的なわけで。
表形式のデータを扱いやすい構造体に変更するの
面倒なんだよ。
0287nobodyさん
2008/04/01(火) 02:16:43ID:???それはORMを理解してない。
> 表形式のデータを扱いやすい構造体に変更
「テーブルのリレーションをオブジェクトのグラフに」ってことだと思うが、
本来ORMはそれを半自動的(設定ファイルが必要)に実現するためのもの。
> 簡単なSQLを簡単に使うのが目的
これを実装したライブラリとかプロダクトがORMを理解してないのに
ORMとか言っちゃったもんだから、そう勘違いしてる人が多いんだけど。
0288nobodyさん
2008/04/01(火) 16:18:05ID:???joinとかサブクエリとか使いこなせてないわ
そんな俺は何から勉強したらいい？
0289nobodyさん
2008/04/01(火) 16:23:40ID:???それ以上は、DB屋さんが面倒見てくれるでしょ。
0290nobodyさん
2008/04/02(水) 09:36:40ID:???まぁ、ジョークなんだけど。
ttp://emasaka.blog65.fc2.com/blog-entry-379.html
シェルスクリプトって、普段/bin/sh互換で書かされるから、
Bashの機能をフルに使って、のびのびと何か書きたい気持ちはわかる。
なんか、昔BashでIMAPを喋るスクリプトを書いたのを思い出した。
0291nobodyさん
2008/04/02(水) 21:41:33ID:???0292nobodyさん
2008/04/02(水) 21:57:39ID:???0293nobodyさん
2008/04/02(水) 23:23:53ID:???ファイル名のこと？
っていうか拡張子すら無いのも多いし、シェバングがきっちりしてれば気にしない
スレ的に展開すると、世の中には.htmlでPHP書く会社も結構あるしなあ
そこまでじゃなくてもテンプレートファイルが（実質PHPやテンプレート独自言語でも）.htmlなところも多いし
まああれだ。拡張子なんて飾りですよと。Windows使いにはそれがわからんのですよ
0294nobodyさん
2008/04/03(木) 00:32:15ID:???Rubyでやればいいじゃん
0295nobodyさん
2008/04/03(木) 00:37:29ID:???0296nobodyさん
2008/04/03(木) 01:07:46ID:???0298nobodyさん
2008/04/03(木) 16:03:55ID:YXuoF4WI0300nobodyさん
2008/04/03(木) 23:27:45ID:???BシェルはもちろんBASHの移植性にはかなわない。
0301nobodyさん
2008/04/03(木) 23:42:49ID:???それがPerlではなくRubyの理由？
じゃないよな
この噛み合わなさはいい加減すごいな
っていうかPHPフレームワークの話題は無いのかｗｗｗ
0302nobodyさん
2008/04/05(土) 00:07:56ID:???CPANモジュール使わなきゃいいじゃんっていうのは無し？
だってCPANモジュール使わなくても、bashに出来ることはPerlで書く方が楽じゃね？
俺はLinuxとかよくわからんが、bashで書けてPerlで書けないこととかってあるの？
0303nobodyさん
2008/04/05(土) 08:17:54ID:ELSeDes50304nobodyさん
2008/04/05(土) 10:40:20ID:???0305nobodyさん
2008/04/05(土) 22:54:08ID:???0306nobodyさん
2008/04/05(土) 23:05:37ID:???なにと比べて、を書かないとあんまり意味がないな。逆もあるから
例えばシェルの場合はUnixコマンド（互換性があるとは限らない）を必要とすることでも、
Perlなら力業でベタに書けてしまうかも知れない
もっというとPerlで書いたものはWindowsにも持ってこられる場合も多い
shをBATに書き直す事を考えると、移植性って何？ってな事にもなるなｗ
0307nobodyさん
2008/04/06(日) 04:34:39ID:???シェルの仕事はコマンド発行とパイプ、リダイレクトまで
制御構造の文法がいびつすぎ
0308nobodyさん
2008/04/06(日) 19:14:33ID:???0309nobodyさん
2008/04/06(日) 21:05:04ID:???業務だとシェルスクリプトを「使わないといけない」んだよなぁ・・・。
そういう場では、「Ruby使いましょう」なんて言える空気ないよ。
Rubyは枯れてないしね。
ところで、Symfonyはそろそろ何かテンプレート機構は装備されたの？
未だに<?php echo $hoge ?>なの？
0310nobodyさん
2008/04/06(日) 21:36:35ID:???0311nobodyさん
2008/04/07(月) 17:09:13ID:???0312nobodyさん
2008/04/07(月) 23:28:06ID:???それなら自分でサーバの設定をいじれるときは、テンプレートファイルに限定して
<? ?> <?= ?>形式で記述するのも手だなと感じる。
だれかえろいひと教えて
0313nobodyさん
2008/04/07(月) 23:31:50ID:???やはり自民党清和会の下に結集し、日教組を壊滅させることでしょうね。
日教組の教師に｢労働者の権利｣などという左翼思想を吹き込まれた連中が義務も果たさずに
サビ残は嫌だ、非正規雇用は止めろ、などと権利ばかり主張しています。
あとは残業代を要求して裁判を起こしてるような腐った輩を社会全体で徹底的に叩くことでしょう。
0314nobodyさん
2008/04/08(火) 00:07:06ID:???0315nobodyさん
2008/04/08(火) 00:20:04ID:???0316nobodyさん
2008/04/08(火) 00:26:07ID:???個人的には、<% %>が廃止は馬鹿だろ、と思った。
使ってはなかったが、Rails使い始めて、やはり必要だと思った。
<?php echo $hoge ?> と <%= $hoge %>
はどちらがすっきり見えますか？どちらがタイプ数（補完なしで）少ないですか？
って事を言いたくて、例えばSmarty正式サポートしろという事ではない。
>>312
自サバならそれもありだと思う。
けど、エロい人がこう言ってるから、凡人の俺は使うのを控えてしまう。
ttp://wiki.poyo.jp/read/Reviewes/Book/IT/PHP
>■ショートタグを使っている
>まだそういう本出てきますか．ハァ．
0317nobodyさん
2008/04/08(火) 00:49:12ID:???認めてもいいと思う。
0318nobodyさん
2008/04/08(火) 05:07:11ID:???htmlspecialchars, array(); preg_replace...
0319nobodyさん
2008/04/08(火) 06:48:18ID:???0320nobodyさん
2008/04/08(火) 15:59:49ID:???0321nobodyさん
2008/04/08(火) 17:41:25ID:???まぁ、フラットな名前空間で、メソッドの動的書き換えなしというのは
読みやすさに貢献しているのかもしれない。
0322nobodyさん
2008/04/08(火) 19:53:54ID:???0323nobodyさん
2008/04/09(水) 13:45:29ID:???単体Webアプリの開発すると全く役に立たないのがなあ。
昔はPerlでよくCGIの配布がされていて、PHPも後から増えてきたが
当時は完璧にMVCなんて欠片もないデザイン＆コード全部ひっくるめソース。
だがそれだけに、配布して掲示板だけ使いたいとかいう場合も
そのPHPファイルさえ設置して設定ちょこちょこ弄れば出来た。
しかし今もしframeworkありきでBBSとか作っても、それを配布するとなるとframeworkをまずインストールしなければならない。
大体掲示板とか配布されてるCGI使うのなんて素人だし、そんなframeworkの導入なんてできないし
第一例えばZFで作っていた場合、ディスパッチャが統括してるから普通の巣HTMLコンテンツまで影響が出る。
ただBBSを設置したいだけなのに、今まで普通にそのままアクセスできていたHTMLをZFのルールに従って設置しないといけない。
とか色々面倒すぎる。
frameworkの特にこの部分が気に入らないんだけど、諸兄らは特に気にしない？
index.phpで統括して振り分けるってのね。
普通に配下に全部おいてディレクトリ構成そのままと同じアドレスでアクセスできりゃいいじゃねえか、って思うんだけど。
コントローラー名/アクション名/
とかプログラマは理解してもデザイナが理解しないだろうと。
完全にプログラムばかりなサイトだといいけど、静的コンテンツが殆どで一部に動的コンテンツがある程度じゃ無駄すぎる。
かといってじゃあそういう時は今まで通りの直PHPファイルのみにしろってなると、なんの為のframeworkだかって思ってしまう。
なげーなｗ
0324nobodyさん
2008/04/09(水) 16:03:25ID:???あとZFに限らずフロントコントローラ形式のFWでも
mod_rewriteのルール次第で特定のディレクトリ以下や
ファイルのみに限定して動作させる事はそれほど面倒な事でもない
ディレクトリ構成そのままで一部分だけFW管轄下にする事もできるだろう
mod_rewriteやrouterの使い方が分からない人の言い訳にしか聴こえない
0325nobodyさん
2008/04/09(水) 18:42:17ID:???結局全部framework上につくれば無問題
0326nobodyさん
2008/04/09(水) 21:44:17ID:???フレームワークつったってただのPHPファイルに過ぎんよ。
新しくフォルダ作って、そこにすべてのファイルぶっこめばいいだけ。
0328nobodyさん
2008/04/10(木) 01:47:20ID:???0329nobodyさん
2008/04/10(木) 07:35:57ID:???だからPHP技術者が理解できても、一般人が理解できないだろって話をしてるんだが。
昔のPHPやPerlならちょっとだけ勉強すれば素人でもいけるレベルだったが
mod_rewriteを弄る素人いないだろ、ってか無料レン鯖だと弄れないところ多いだろ。
有効になってるかどうかすら怪しい。
お手軽が利点だったのに、そういう配布しても一部の技術者しか設定して使えないようなPHPプログラム作ってもなと。
今までPHPファイルを好きな場所に放り込んで、confとかをちょこちょこ弄った程度で使えていたものが
まずFWを導入して、mod_rewriteとかapacheの設定を弄って更に仕様に則った方式に従ってファイルを配置する
なんての誰が使うんだと。
ZFでいえば、PHP.iniのincludeパスまで設定しないといけない（PHP大本ファイルに全てincludeを書くというてもあるが、まあないわな）
そういうケースってか、後からこの機能だけ他で使いたいな って事があるだろ？
趣味でもいいが、FWフル活用であるシステムを作りました、その中の一部機能が評判なのでそこだけ配布する事にしました
が、当然元のFWに依存しているのでそれ以外のFWじゃ動かないし、FW前提の作りなのでファイル置いてconfファイル設定程度じゃ動きません。
で結局配布しても使えるのはほぼPHP技術者のみ。
ちょっと自分のページにCGI設置したい、とかそういう昔からいる人間には無理。
仕事のになら別にいいんだよ。
だが仕事でFW使ってそんな配布するのは昔みたいな作りにすればいいとかナンセンスだしな。
それじゃお互いが有効利用しあえないし。
仕事で作ってた一部を配布したいって時無理だし、趣味で配布用に作ったのをFW使ってる方に使いたいって時も無理（または変換に手間）だし。
>>326
フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
0330nobodyさん
2008/04/10(木) 08:56:21ID:???昔は「オブジェクト指向が分かっている人間はプログラマの中でもほとんどいない」
なんて本に書かれていたもんだけど
プログラマ界の被差別層PHPERの間でも
オブジェクト指向なんてもはや前提条件だし
0331nobodyさん
2008/04/10(木) 11:14:42ID:???> フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
有名どころは全部対応しているが？
mod_rewriteだって、index.phpを隠すためだけに使用されているわけで、
デフォルト設定のまま使える。
mod_rewriteでコントローラ/アクションに振り分けているんじゃないんだよ？
0332nobodyさん
2008/04/12(土) 13:05:07ID:???mod_rails登場でmod_php雪崩式に脂肪ｗｗｗ
0333nobodyさん
2008/04/12(土) 15:40:54ID:???しかもプリインストールされるまではきてないし、
何年遅れだよｗｗ
0334nobodyさん
2008/04/12(土) 16:17:48ID:???フレームワークレベルでmodになってるんだからとっくにphpをぶち抜いてるよ
mod_symfonyとかmod_zend_frameworkみたいなもの
ﾌﾟｰﾌﾟﾌﾟﾌﾟ
0335nobodyさん
2008/04/12(土) 17:23:23ID:???0336nobodyさん
2008/04/17(木) 16:32:23ID:???0337nobodyさん
2008/04/17(木) 17:02:10ID:???0338nobodyさん
2008/04/18(金) 06:17:36ID:???新規開発はpostgresにした方がいいんかな
0339nobodyさん
2008/04/18(金) 07:41:13ID:???ポスグレも充分に速くなってるから代替効くし
Sunの戦略がわからんわ
0340nobodyさん
2008/04/18(金) 09:42:52ID:???0341nobodyさん
2008/04/18(金) 14:07:52ID:???MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に
http://www.technobahn.com/news/2008/200804172000.html
0342nobodyさん
2008/04/18(金) 14:18:22ID:???趣味ならそれは重要だが。企業レベルじゃあまり関係ない。
SQLServerやらMySQLの有料版が実際使われているのがいい証拠。
企業の場合どっちかというとサポート体制が重要。
金払ってるといざって時サポート呼べるし、場合によっては責任もとらせられる。
無料版だとサポート呼べないし責任は全部自分ところ。
なんでもオープンソース使え使えっていってるのは2流の技術者と、そういうのに疎い有料無料かでしかみれない上役だけ。
現場でわかってるプロの技術者なら有料か無料かなんて選択肢の中ではかなり優先度は低い。
少なくとも、これオープンソースだから使いましょうよ、なんていってる技術者いたらその時点で役立たずのレッテル貼るわ。
その構築するシステムに向いてるかどうかで判断するのならまだしも。
0344nobodyさん
2008/04/18(金) 15:42:02ID:???0345nobodyさん
2008/04/18(金) 18:10:17ID:???0346nobodyさん
2008/04/18(金) 18:23:32ID:???先見の明の違いが出たねｗ
0347nobodyさん
2008/04/18(金) 18:54:43ID:???0348nobodyさん
2008/04/18(金) 19:35:54ID:???フレームワークに内蔵してデフォルトにしているだけで
別に良いものだから選んでいるわけじゃないんだけどな。
あくまで開発・プロトタイプ・個人用のもので
複数の人が同時にアクセスするものとしての
本番利用は現実的じゃない。
それにPHPは、sqliteをとっくの昔に言語の標準
データベースとして組み込んでいる。お前に言わせれば先見の明だなｗ
0349nobodyさん
2008/04/18(金) 19:41:04ID:???みっともないｗ
0350nobodyさん
2008/04/18(金) 19:55:20ID:???使ってもいないくせに何か言おうとしているなこいつｗ
0352nobodyさん
2008/04/18(金) 20:38:46ID:???一般企業で有償MySQLってなかなかないんじゃないかな？
OracleかSQL Serverでしょう、有償なら。
現場で解ってるプロの技術者には選択肢ないんじゃないかと思う。
俺の周りだけの話だけかもしれないけど。
0353nobodyさん
2008/04/18(金) 20:56:40ID:???オープンソースからプロプライエタリに移行して成功した製品あんのかと
0354nobodyさん
2008/04/19(土) 01:02:42ID:???どうやら、あなたはオープンソースからプロプライエタリに移行したら
失敗するといいたいようですが、そもそも
オープンソースからプロプライエタリになった製品があるのですか？
あと、MySQLはsunが買収したとしても、オープンソースのままなのは
知っていますか？
0355nobodyさん
2008/04/19(土) 03:29:45ID:???オープンソースからプロプライエタリに移行した製品がないという
悪魔の証明に自ら挑むとはｗ
製品を殺す愚策なんだから知られないのは当然
まぁ俺も知らないけどね
本当に無償版の開発を停止して有償版しか出さなくなったら
MySQLは死んでいくと思うよ
0356nobodyさん
2008/04/19(土) 07:12:17ID:???もしメンテ（および機能改良）が続くんなら別にいいかなと、無理矢理楽観してみる
0357nobodyさん
2008/04/19(土) 08:21:08ID:???金かかるんだったら、ポスグレにして、その分自分の収入にする罠。
0358nobodyさん
2008/04/19(土) 09:19:18ID:Pd4VwcNbApacheもMySQLも信頼性が低いってー事はないぞ。PHPについてはシランが。
あと、普通にPHPでwebプログラムを組める奴は必然的にPHPとJavascriptという風に複数言語使えるようになってるからそこから更にrubyとかいうことになってもそんなにコストかかるわけじゃないと思う。
俺もrubyについては手をつけてないが、Cやらpythonやらに手をつけてるし。
PHP脂肪とか言われたら他の言語使えばいいだけだって気づかないんかね。
# あと、ここはフレームワークのスレかと
0361nobodyさん
2008/04/19(土) 18:10:16ID:???Community Server開発継続でPHP余命一年延びるｗｗｗ
0362nobodyさん
2008/04/20(日) 01:52:32ID:???けどまだ時期尚早だよな
0363nobodyさん
2008/04/22(火) 22:01:35ID:???Ruby1.9以下のWEBrickにディレクトリ遷移攻撃脆弱性があってPHP脂肪ｗｗｗ
0364nobodyさん
2008/04/22(火) 23:27:24ID:???誰かこれ参加しろよ
0365nobodyさん
2008/04/23(水) 03:25:02ID:???「データベースに特別なコードを書かずとも容易に接続できるようにした」
とかいう説明読むとフレームワークと認識してもいいように思うけど
0366nobodyさん
2008/04/23(水) 10:30:22ID:???フレームワークの定義って、データベースアクセスが簡単かどうかってよりも
アクションのディスパッチャがあるかどうかだと思う。
0367nobodyさん
2008/04/23(水) 21:37:32ID:???0368nobodyさん
2008/04/24(木) 20:18:05ID:???Pythonのセキュリティー警告してたらSPAMにメールアドレス使われたみたいだ
Python厨タチわりー
0369nobodyさん
2008/04/24(木) 20:21:21ID:???0370nobodyさん
2008/04/25(金) 06:21:16ID:???phythonerﾔﾊﾞｽ
しかも単なるセキュリティー情報で誹謗中傷ですらねーし
0371nobodyさん
2008/04/28(月) 10:48:30ID:???せっかくMVCなのにテンプレートに関数入れるなんて、とっても矛盾してると
思うのですが・・・
そういう需要もあるってだけなんですかね
0372nobodyさん
2008/04/28(月) 11:49:40ID:???MVC=Viewの動的要素を一切省こうってわけじゃないよ
0373nobodyさん
2008/04/29(火) 00:07:53ID:???準備するのはなんだかなーだ
分担としては間違いなくViewの仕事だろう。ヘルパーって言うのが微妙なんだけどな
0374nobodyさん
2008/04/29(火) 01:49:36ID:???高校生か？
0375nobodyさん
2008/04/29(火) 09:35:20ID:???またフレームワークが増えましたよ、と。
0376nobodyさん
2008/04/30(水) 02:52:49ID:???採用検討／評価するにしてもうちはGW終わってからだなー。
おまえら頑張れ
0377nobodyさん
2008/04/30(水) 04:53:29ID:???0378nobodyさん
2008/04/30(水) 15:03:38ID:???0379nobodyさん
2008/04/30(水) 16:29:31ID:???0380nobodyさん
2008/05/01(木) 17:01:00ID:1aec6u7x社内システムの標準FWに採用しました。
0381nobodyさん
2008/05/01(木) 20:29:40ID:???0382nobodyさん
2008/05/02(金) 00:35:33ID:ulIGiMsU0383nobodyさん
2008/05/02(金) 14:05:51ID:ulIGiMsU0384nobodyさん
2008/05/02(金) 14:35:04ID:???同じパフォーマンスをあげようと思ったら3倍のリソースが必要か…
0385nobodyさん
2008/05/02(金) 14:58:16ID:???0386nobodyさん
2008/05/02(金) 16:54:39ID:???twitterがRoRを放棄でPHP復活ｗｗｗ
0387nobodyさん
2008/05/02(金) 16:57:33ID:???それならRoRをパクっただけのPHPのFWが対応できるのか？
0388nobodyさん
2008/05/02(金) 17:16:29ID:???0389nobodyさん
2008/05/02(金) 17:16:36ID:mpl3PtrU0390nobodyさん
2008/05/02(金) 18:38:44ID:ulIGiMsU0391nobodyさん
2008/05/02(金) 20:08:53ID:???0392nobodyさん
2008/05/02(金) 20:50:58ID:???仕方ないんだろうけどさ
0394nobodyさん
2008/05/02(金) 21:37:21ID:???0396nobodyさん
2008/05/02(金) 22:22:41ID:???0397nobodyさん
2008/05/02(金) 23:34:45ID:???それは激しく思う。というか閉じタグをとっぱずすなんてどう考えてもバッドノウハウじゃねえかｗ
少しは疑問に感じろよPHPerども
0398nobodyさん
2008/05/03(土) 03:55:15ID:???0399nobodyさん
2008/05/03(土) 03:59:36ID:???そこは分けとけよ
0401nobodyさん
2008/05/03(土) 06:16:41ID:???久しぶりにci触ったら身軽でいいわ～
0402nobodyさん
2008/05/04(日) 23:06:36ID:QrBYi/l0CakePHP
-> DBと密接すぎる
CodeIgniter
-> セッションがクッキーに保存される
とどっちも肝心なとこがいまいちだった…
0403nobodyさん
2008/05/04(日) 23:10:28ID:???ちゃんと使えば？CIのセッションについては、DBに保存することもできたと思うけど。
っていう自分はドキュメントよんで評価して改良してっていう手間がもうしんどくて、
guesswork classic をカスタマイズしたものを延々つかってるけど
0404nobodyさん
2008/05/04(日) 23:13:41ID:???うん DB使うときはそれでいいんだけど
使わないときがね…
小規模だと CakeかCIがよさげなんだけどね
その改造する手間がね… orz
guessworkもためしてみるかな
0405nobodyさん
2008/05/05(月) 00:52:06ID:???usesプロパティにnull代入すれば
それで終わりじゃね？
0406nobodyさん
2008/05/05(月) 01:19:43ID:???それで一応できるけど
modelは必須なのが前提だし…
DB使うにしても密接すぎて融通きかない感じかな
はまれば楽なんだけどね
0407nobodyさん
2008/05/05(月) 03:33:55ID:???まあ経験をつめ。
0408nobodyさん
2008/05/05(月) 09:50:45ID:???0410nobodyさん
2008/05/05(月) 12:31:02ID:???0411nobodyさん
2008/05/05(月) 13:45:56ID:???FWを使うべきかどうかを検討する規模の開発だと思う。
生PHP+何かしら必要なライブラリで事足りそう。
0412nobodyさん
2008/05/05(月) 15:29:14ID:???自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？
オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。
0413nobodyさん
2008/05/05(月) 17:17:56ID:???0414nobodyさん
2008/05/05(月) 19:08:40ID:???画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。
っていうか、モデルとしてのメリットがほとんどない。
0415nobodyさん
2008/05/05(月) 19:21:04ID:???0416nobodyさん
2008/05/06(火) 01:40:18ID:Db+mgkTmhoge/moge/
と
hoge/moge
を同一と判定すべき？しないべき？
0417nobodyさん
2008/05/06(火) 01:45:13ID:iGu8GQhf0418nobodyさん
2008/05/06(火) 01:54:34ID:???ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな
0419nobodyさん
2008/05/06(火) 03:21:15ID:???どちらかに転送した方が良いと思われ
0420nobodyさん
2008/05/06(火) 16:53:07ID:???和製フレームワークっぽいけど
このスレで出たことないよね？
0421nobodyさん
2008/05/06(火) 16:54:23ID:???結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。
0422nobodyさん
2008/05/06(火) 16:56:00ID:???パフォーマンスでないのかな？
0423nobodyさん
2008/05/06(火) 16:59:32ID:???なんでまったく話題に出なかったんだろ？
0425nobodyさん
2008/05/06(火) 17:47:31ID:???0426nobodyさん
2008/05/06(火) 17:48:55ID:???おいおい。index.htmlを忘れているぞ。
hoge/moge/ だとmogeフォルダのindex.html（設定による）を参照すべきだろう？
0428nobodyさん
2008/05/06(火) 18:14:00ID:???URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か
で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな
0429nobodyさん
2008/05/06(火) 18:15:28ID:???mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな
0430nobodyさん
2008/05/06(火) 18:16:27ID:???0432nobodyさん
2008/05/06(火) 18:22:19ID:???0433nobodyさん
2008/05/06(火) 18:24:06ID:???428・429…最後の/で判断しないよ派
これであってる？
0434nobodyさん
2008/05/06(火) 18:30:18ID:???フレームワークのルータに/hoge/moge/index.htmlが渡ることって考えにくいな
素のリソースはmod_rewriteの設定で直接アクセスされるだろ
0435nobodyさん
2008/05/07(水) 00:29:19ID:???1./foo/barがファイルであるか確認
2./foo/bar/へリダイレクト（301 Moved Permanently）
が正しい動作のはず。
0436nobodyさん
2008/05/07(水) 01:08:20ID:???0437nobodyさん
2008/05/07(水) 01:32:49ID:???独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?
0438nobodyさん
2008/05/07(水) 02:53:40ID:???妥協点はスラ付きへリダイレクト
が正解
0439nobodyさん
2008/05/07(水) 03:22:12ID:???SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 → http://pmakino.jp/tdiary/20061105.html#p01
0440nobodyさん
2008/05/07(水) 06:16:35ID:???たしかにSEO的にリダイレクトする方がいいな
㌧㌧
0441nobodyさん
2008/05/07(水) 06:36:20ID:???乗り遅れたけど、いい事言ってるなあ。
>>407とか>>415は流行に流されて本質を見失ってるな。
俺はテーブルと一対一になるモデル「じゃない」モデルクラスを作って対処してる。
0442nobodyさん
2008/05/07(水) 06:50:57ID:???日本語が読みきれん。どっち？
テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる
前者だろうとは思うけど、一応。
0443nobodyさん
2008/05/07(水) 09:21:36ID:???モデルはモデルだろ。
0444nobodyさん
2008/05/07(水) 09:47:29ID:???モデリングとして不適切だと思ってる。
だから自分的には >>443 は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。
0445nobodyさん
2008/05/07(水) 09:56:24ID:???クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ
0446nobodyさん
2008/05/07(水) 12:42:06ID:???自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
0447nobodyさん
2008/05/07(水) 14:16:49ID:???0448nobodyさん
2008/05/07(水) 20:53:16ID:???せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？
0450nobodyさん
2008/05/07(水) 21:14:56ID:???例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。
0451nobodyさん
2008/05/07(水) 21:59:18ID:???class なんとか_かんとか_Exception extends なんとか_Exception
{}
だけみたいなファイルが増えてくのはやっぱバカバカしいな
0452nobodyさん
2008/05/07(水) 23:57:23ID:???0453nobodyさん
2008/05/08(木) 00:14:58ID:???$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
0454nobodyさん
2008/05/08(木) 00:29:40ID:???長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
0455nobodyさん
2008/05/08(木) 00:42:41ID:???プログラマとしては気に入らないけど、現場レベルだとコピペ嵐の方が修正時の影響範囲が
限定的だから現実的だというのは、認めないわけでもない。
カラシニコフ的アーキテクチャとでも言うべきか。
0456nobodyさん
2008/05/08(木) 00:55:28ID:???修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
0457nobodyさん
2008/05/08(木) 02:02:54ID:???0459nobodyさん
2008/05/08(木) 05:17:56ID:???>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
0460nobodyさん
2008/05/08(木) 06:45:47ID:???開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
0461nobodyさん
2008/05/08(木) 08:00:22ID:???0462nobodyさん
2008/05/08(木) 08:20:17ID:???エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
0463nobodyさん
2008/05/08(木) 08:43:03ID:???この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
0464nobodyさん
2008/05/08(木) 09:39:12ID:???そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
0465nobodyさん
2008/05/08(木) 09:40:21ID:???0466463
2008/05/08(木) 10:10:38ID:???そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
0467nobodyさん
2008/05/08(木) 11:24:56ID:???MVC＝Python＋Google App Engine
がいいかな？
0468nobodyさん
2008/05/08(木) 11:33:59ID:???GoogleAppEngineは本サービスの内容次第だけど
0469nobodyさん
2008/05/08(木) 12:49:25ID:???好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
0470nobodyさん
2008/05/08(木) 12:54:43ID:???0471nobodyさん
2008/05/08(木) 13:01:46ID:???クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
0473nobodyさん
2008/05/08(木) 14:41:46ID:???綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
0474nobodyさん
2008/05/08(木) 14:52:22ID:???サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
0475nobodyさん
2008/05/08(木) 15:13:05ID:???まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
0476nobodyさん
2008/05/08(木) 21:45:25ID:???で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
0477nobodyさん
2008/05/08(木) 22:39:24ID:???どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
0478nobodyさん
2008/05/09(金) 00:59:50ID:???一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
0479nobodyさん
2008/05/09(金) 02:21:08ID:???それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
0480nobodyさん
2008/05/09(金) 03:21:13ID:???異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
0481nobodyさん
2008/05/09(金) 13:09:55ID:???単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
0482nobodyさん
2008/05/09(金) 21:42:19ID:???>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
0483nobodyさん
2008/05/09(金) 22:56:26ID:???0484nobodyさん
2008/05/09(金) 23:11:23ID:a3XtheQg>>475じゃないけどsymfony+smarty使ったことあるかい？
しかしMVCは良いとしてもO/Rマッパはなんとかならんもんかね
0485nobodyさん
2008/05/10(土) 01:24:53ID:???あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
0486484
2008/05/10(土) 03:06:24ID:???>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
0487nobodyさん
2008/05/10(土) 10:23:21ID:???大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
0488nobodyさん
2008/05/10(土) 10:26:41ID:???> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
0489nobodyさん
2008/05/10(土) 11:47:06ID:???テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
0490nobodyさん
2008/05/10(土) 12:08:18ID:???保守を考えるとフレームワーク使わないときついだろ
0491nobodyさん
2008/05/10(土) 22:09:04ID:???> ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしい理由は？
DAOとしての面ではあるテーブルに対する操作が一つのクラスに集約されるから見通しが良くなるが。
0492nobodyさん
2008/05/10(土) 22:28:21ID:???パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
0493nobodyさん
2008/05/10(土) 23:26:26ID:???結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
0494nobodyさん
2008/05/11(日) 00:27:11ID:???セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
0495nobodyさん
2008/05/11(日) 00:39:19ID:???でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
0496nobodyさん
2008/05/11(日) 00:43:17ID:???>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
0497nobodyさん
2008/05/11(日) 00:50:47ID:???>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
0498nobodyさん
2008/05/11(日) 01:04:31ID:???そのテーブルに対して「のみ」のモデルじゃない
0499nobodyさん
2008/05/11(日) 03:58:08ID:???検討にすら値しないだろ
0500nobodyさん
2008/05/11(日) 04:09:26ID:???・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
0501484
2008/05/11(日) 05:00:31ID:???>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
0502nobodyさん
2008/05/11(日) 08:41:33ID:???>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
0503nobodyさん
2008/05/11(日) 08:51:20ID:???そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
0504nobodyさん
2008/05/11(日) 09:50:03ID:???設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
0505nobodyさん
2008/05/11(日) 13:40:27ID:???symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
0506nobodyさん
2008/05/11(日) 14:20:23ID:???0507nobodyさん
2008/05/11(日) 14:24:05ID:???どこからか金が環流しないと時間と労力投入できないじゃん
0508nobodyさん
2008/05/11(日) 14:44:30ID:???お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ
それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ
0509nobodyさん
2008/05/11(日) 14:49:35ID:???0510nobodyさん
2008/05/11(日) 15:03:35ID:???>>502じゃないが、デザインとロジックの分離のレベルは
WicketやMayaaレベルを言ってるんだろう。
俺も分離するならそのレベルが妥当だと思う。
逆にそのレベルで分離できないなら、
開発者には必要とされてもデザイナには使いにくいことに変わりないと思う。
0511nobodyさん
2008/05/11(日) 15:25:06ID:???んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
そもそも一番のメリットは上に書いたがテンプレートにロジック書くようなｳﾝｺ野郎を排除するところだし。
0512nobodyさん
2008/05/11(日) 15:54:25ID:???>んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
>.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
すまんが主語は何だ。smartyが、か？
WicketやMayaaはテンプレートがHTMLなので（独自タグや{if}等が無い）、
HTMLしかしらないデザイナも扱いやすいし、
HTML編集ソフトでテンプレートを読み込んで修正しやすいのがメリットなんだが、
そんなメリットは必要ないってことか？
0513nobodyさん
2008/05/11(日) 15:55:42ID:???SQLイヤならOODB使うしかない
0514nobodyさん
2008/05/11(日) 16:05:35ID:???参考になります。
ついでにPHPにも移植してください。
Wicket
http://www.wicket-ja.org/
Mayaa
http://mayaa.seasar.org/
0515nobodyさん
2008/05/11(日) 16:19:02ID:???そう、SQLってかなり完成度高いんだよね。
SQLで拾った値でインスタンス作っても作らなくてもいいんだけど、
拾うためにインスタンス作るのに何のメリットがあるのか。
SQLをラップするのって、正規表現が分からない人向けに正規表現エンジンをラップして
簡単なテキスト検索エンジンを作ってるような気持ち悪さを感じる。で、正規表現をつかう
抜け道も用意してありますみたいな。
0516nobodyさん
2008/05/11(日) 17:42:48ID:tIr1XyIc先生、WicketやMayaaをsymfonyと連携させる方法を教えてください＞＜
smarty使わないので教えてください＞＜
0517nobodyさん
2008/05/11(日) 17:43:09ID:???ごめんね
0518nobodyさん
2008/05/11(日) 17:49:27ID:???簡単にメールを送信するmail()関数がある。で、プロトコルしゃべる
抜け道も用意してある。
SQLラップするのも正規表現ラップするのも同じ。ライブラリとはそういうもの。
0519nobodyさん
2008/05/11(日) 17:52:41ID:???0521nobodyさん
2008/05/11(日) 18:49:51ID:???0522nobodyさん
2008/05/11(日) 19:01:31ID:???PG/SIerとしては、そっちのほうが幸せかもしれん。
0523nobodyさん
2008/05/11(日) 19:19:10ID:???で、その完成度の高い低い、ラップすべきしないべきは誰が決めんの？
結局自分の趣味趣向で言ってるだけなんだよなぁ。
0524nobodyさん
2008/05/11(日) 21:01:26ID:???> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
クビにするべきだろう。
> デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレートを渡すという事は、責任を渡すという事と同義だよ。
> 使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
こう言ってるって事は、理不尽さを感じながら妥協をしていて、それを愚痴ってるんだと思うんだが、
たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
たとえば、ウンコ書くプログラマが居る可能性がある時に、
そのプログラマが極力コードを書けないように制限する事は困難だと思う。
制限を課す事に手間を割くくらいなら、生産性のある作業に注力した方が良いんでないかい。
0526nobodyさん
2008/05/11(日) 22:15:43ID:???本当にプログラマ？
すぐクビにするとかテンプレート渡す＝責任を渡すとか
到底社会人の発想とは思えないんだが。
サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
0527nobodyさん
2008/05/11(日) 22:19:14ID:???0528nobodyさん
2008/05/12(月) 00:11:47ID:???自信のある人なんだなーって素直に感心してる俺ｗ
とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
されてないの？
まあ「MVCのモデル」ってレベルではなく、DBIインターフェイスレベルの話ではあるん
だけどｗ
0529nobodyさん
2008/05/12(月) 00:52:56ID:???SQLより速くてインピーダンスミスマッチのないORMがあったら教えて！＞＜
分類 / 基礎となる計算モデル / 例
1. 手続型言語 / チューリングマシン / C, Java
2. 問合せ言語 / 関係モデル / SQL
3. 関数型言語 / ラムダ計算 / Lisp, Haskell
4. 論理型言語 / 一階述語言語 / Prolog
（2～4は、非手続型言語）
↑1～4のどれでも使えるようにしておいた方がいいよ
＝RDBを使ってる人はSQLも必須スキル
つhttp://www.amazon.co.jp/dp/4798115169/
0530nobodyさん
2008/05/12(月) 01:12:44ID:???「SQL」って言っちゃうと、結局最終的に「文字列」に落とし込まなきゃいけないのが
違和感があるのかも
メソッドの引数とかオブジェクトのプロパティとかなら抵抗ないのに・・・
PerlやRubyで /\A"[^"]+"\z/ みたいなリテラルで書くことの出来る正規表現を、
文字列として "/\\A\"[^\"]\"\\z$/" って書かなきゃいけない歯がゆさみたいなｗ
だから、変数的な部分をプレースホルダにしたprepare(), execute() インターフェイスが
あれば、それで良いのか。それなら、変数的な部分以外はけっこうソリッドに組み立て
られる、と考えて・・・でも、やっぱりパラメータの数が変わったらプレースホルダの数も
変わるし・・・
いかに簡単にSQLを組み立てるかっていうツールとしてのモデルの効能が、あんまり
問題になっていないから書いてみたっていうだけ。低レベルだとは思うけど
0531nobodyさん
2008/05/12(月) 01:35:11ID:???0532nobodyさん
2008/05/12(月) 02:19:06ID:???1つはJOINを駆使したりサブクエリーを使うような、（比較的）高度なSQLを書ける人が少なかった。（複雑な処理はホスト言語で処理する。）
もう1つはORマッパー＝オブジェクト指向を連想させ、オブジェクト指向って言葉だけをやたらもてはやすような風潮に乗っかった。
0533nobodyさん
2008/05/12(月) 03:49:51ID:???SQLで書いてもすぐ書ける罠
0534nobodyさん
2008/05/12(月) 03:51:14ID:???あまり意味ないってことでいい？
0535nobodyさん
2008/05/12(月) 03:56:57ID:???ActiveRecordとかはシンプルでいいと思うけど、やりすぎ感っての？あるんじゃね？
APIが全てで、文字列としてのSQLを流し込むっていう感覚があんまり無いって感じで。
（C#とかの.net系でもO/Rマッパって使うのならごめん）
でも、PHPになじむかどうかは別問題なんだろうとは思う
0536nobodyさん
2008/05/12(月) 04:10:33ID:???0537nobodyさん
2008/05/12(月) 06:31:54ID:???私見だけど、メモリ中のオブジェクトをそのまま永続化させて使用するための
手段として RDBへの格納するのが良いのではないかっていう考え方があって、
でも現実には永続化よりもデータベース的な検索のほうが重要なことがはっきりして、
結局ラッパーとしてだけ生き残ったって感じではないかと思う。
まぁ、そうした抜け殻のようなツールとし出来上がった後、現場では >>532みたいなな
流れで流行ったんじゃないかと。
0538nobodyさん
2008/05/12(月) 07:26:54ID:???>とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
>あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
>されてないの？
思うに、「フレームワークのパワーを生かした」開発においては、そういう小難しいことは、
基本的にやらない、もしくは極力避けるんじゃないかね。
フレームワークが力を発揮するのは、単機能な画面が多数あるようなシステムだと思う。
そうした前提においては、動的なSQLを嫌ったとしても、それは普通な判断だと思うし。
0539nobodyさん
2008/05/12(月) 23:55:26ID:???http://tracfort.jp/projects/symfony-phptal
0540524
2008/05/13(火) 02:06:31ID:???いや、sfSmartyViewPluginは間違いなくsymfonyにとって改悪だと思うわ。
>>526
権限と責任が乖離している時点で、体制を考え直すべきだよ。
仮に、よほど信用出来なくて悪意があってとても偉いデザイナーと仕事をしてるとしても、
MVCやORMという概念や、symfonyやsmartyという実装は、
プログラマーとデザイナーの「責任の所在」を明らかにするための方法論では無いと思う。
>>528
俺はORMには否定的だけど、SQLを抽象化する事には肯定的。
0541nobodyさん
2008/05/13(火) 02:11:29ID:???因習的に使い続けてるところもあるだろ
そういうところのために出来ただけじゃねーの>smartyplugin
いちいち目くじら立てるようなものでもない思うが
0542524
2008/05/13(火) 02:23:12ID:???うん。>>484が偉そうにsymfony+smartyが完璧だと言ってたので、
そりゃねーよ、って反論してるだけだ。
よく考えればスレ違いな主張に相手してる気がするので、smartyに構うのは以後控えるわ。
0543nobodyさん
2008/05/13(火) 08:44:20ID:???>> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
>
>クビにするべきだろう。
大賛成。お金をもらう仕事に、なんでウンコな人間を混ぜなきゃいけないの?
>たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
そうそう。それができない環境はプロとして仕事すべきじゃない。
>>526
> 本当にプログラマ？
> すぐクビにするとかテンプレート渡す＝責任を渡すとか
> 到底社会人の発想とは思えないんだが。
なんで? 使えない人間は教育し、それでも使えなければクビでいいじゃん。あんたどこの公務員よ?
> サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
> 分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
分業することと、ウンコを混ぜる話は別だろ。それをいっしょくたにしているおまえがウンコ。
0544nobodyさん
2008/05/13(火) 10:54:49ID:???1つはJOINを駆使したりサブクエリーを使うようなSQLから生成されるデータを扱うにはハッシュの配列では使いにくかった。
SQLには方言があり簡単な文でさえダブルクォーテーションとクォーテーションの意味が違うなど複数のDBMSに対応しづらかった。
もう1つはORマッパー＝オブジェクト指向であり、ただのデータの出し入れに過ぎないSQLに様々な付加価値をつけることが出来た
（たとえばバリエーションなど）
0546524
2008/05/13(火) 13:10:19ID:???あまり恥ずかしい書き込みをするなよ。
>>544
それは全部PDOの利点でもあると思う。
PDO != ORMなので、ORMの利点だとは言えないと思う。
CreoleとPropelの違いを理解した上で、
Propelの機能として好ましいと感じる部分は、
propel-generate-modelとBasePeerのクエリ生成部分かな。
BasePeerははっきり言って複雑なSQLは全く書けないけど、
でもまあ、そのあたりの機能だけ流行れば良かったのに、と思うよ。
0547nobodyさん
2008/05/13(火) 15:35:20ID:???首にできる権限がある奴に限って現場見てねえんだよなぁ
0548nobodyさん
2008/05/13(火) 16:32:21ID:???フォーム要素が多次元配列になる時のバリデーションが
きれいに書けないよう・・・
値はコンポジットパターンになるのに
errorはchildだけじゃなくて親も持つとか複雑過ぎ
0550nobodyさん
2008/05/13(火) 21:12:36ID:???0551nobodyさん
2008/05/15(木) 02:42:52ID:???PHPは省略できないんですかぁ？
ださーい
0553nobodyさん
2008/05/15(木) 18:06:07ID:???VBなんて中二みたいの名前の言語使いませんよぉ
ださーい
0554nobodyさん
2008/05/15(木) 18:06:50ID:???返ってくるデータが二次元の表だけって面倒だよね。
たとえばアドレス帳があったとして、電話番号を複数登録できるようにしたい。
まあ、普通は正規化する。んで、それを取得すると
ID, 名前, 電話番号ID, 電話番号
1, 山田, 1, 090-0000-0000
1, 山田, 2, 090-0000-0001
1, 山田, 3, 090-0000-0002
2, 佐藤, 4, 090-0001-0000
2, 佐藤, 5, 090-0001-0001
2, 佐藤, 6, 090-0001-0002
こうなる。階層的に取得できたらどんなに使いやすいか。
0555nobodyさん
2008/05/15(木) 18:07:41ID:???ダサいって流れじゃないのか？ｗ
VBやRubyはダサい。
0556nobodyさん
2008/05/15(木) 18:13:49ID:???関数と変数の区別をはっきりつけたいから使おうとは思わないけど
0557nobodyさん
2008/05/15(木) 18:30:45ID:???0558nobodyさん
2008/05/15(木) 18:36:25ID:???いろんな人がいるだろうし
0560nobodyさん
2008/05/15(木) 18:52:47ID:???引数省略に付随する問題も一緒に抱えるのに
手放しで喜ぶ馬鹿は死んだほうがいい
0563nobodyさん
2008/05/15(木) 23:37:08ID:???それがリレーショナルDBだから。
オブジェクトで扱いたいなら、ORMじゃなくって、OODBを使えばいいんだよ。誰も使ってないけど。
もっともその例って、単なる配列のデータ構造を表してるだけで、オブジェクトとは関係ないと思うけど。
0564nobodyさん
2008/05/15(木) 23:50:37ID:???そりゃ、元のレスが
> 連想配列ですべて解決する。
だからだろうね。
RDBの結果なら連想配列で全て表すことができるっていうだけの書き込みに対して、
それが便利なのか？っていうつっこみなんだろうと思った。
>>554が例に挙げてる様なデータなら、多次元の配列で処理する人も多いだろうし
O/Rマッパとはまた違う次元の話の様な気もするｗ
0565nobodyさん
2008/05/16(金) 00:41:02ID:???0566nobodyさん
2008/05/16(金) 00:51:22ID:???そんなに複雑でビジネスロジックとその他もろもろの制約によって
アドホックばりばりのシステムの話なんてするところじゃないじゃ無いか
0567nobodyさん
2008/05/16(金) 05:20:25ID:???そういう制約が意味あるのって、DB専門班とぎっちぎちに分業するようなケースだしなあ。
null拒否くらいならデバッグの意味はあると思うけど
PHPみたいな上層で使うモンなら正規形も凝らんでそ
制約意識するくらいなら処理ロジックや自前キャッシュ手法に凝った方が百倍マシ
PHPが生かせるケースじゃない
なんか元コメ辿ると、bindやprepare使えば十分だろ的な思惑も感じるけど
0568nobodyさん
2008/05/16(金) 17:52:55ID:???0569nobodyさん
2008/05/16(金) 19:19:07ID:???アドホック - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%89%E3%83%9B%E3%83%83%E3%82%AF
アドホック（ad hoc)は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。
ヨーロッパ諸語では様々な語句と組み合わせて用いられている。
ad hoc quering アドホック・クエリ
情報科学分野の用語。
アドホック・クエリを使えば、カスタマイズされたクエリを簡単に作成することが可能になる。
通常、データベースの原理やSQL 文を深く理解していなくても、GUIを使って行うことができる環境が提供されている。
ただし、このような方式のクエリが多用されるとデータベース システム全体のパフォーマンスにも影響が出かねないため、直接に"生"のデータベースを対象とするのではなく、"生"のデータベースを定期的に複製したものを対象にクエリを作成する、というようなことも行われる。
そのような複製は「データウェアハウス」などと呼ばれることもある。
0570nobodyさん
2008/05/16(金) 19:20:35ID:???http://d.hatena.ne.jp/keyword/%A5%A2%A5%C9%A5%DB%A5%C3%A5%AF
アドホック あどほっく
【ad hoc(羅)】取ってつけたようであるさま。
この意味より，「恒久的でない」とか「反復的でない」ような形容に使われる
0572nobodyさん
2008/05/16(金) 22:47:17ID:???0573nobodyさん
2008/05/16(金) 22:53:58ID:???0574nobodyさん
2008/05/16(金) 22:59:30ID:???0575nobodyさん
2008/05/16(金) 23:36:11ID:???0576nobodyさん
2008/05/17(土) 00:30:15ID:???0577nobodyさん
2008/05/17(土) 00:50:50ID:???0578nobodyさん
2008/05/17(土) 03:55:36ID:???そのまま使う？
0579nobodyさん
2008/05/17(土) 04:45:21ID:???0580nobodyさん
2008/05/17(土) 09:38:16ID:???0581nobodyさん
2008/05/17(土) 13:16:01ID:???O/Rマッパー最高！！！
という流れですね。わかります。
0583524
2008/05/17(土) 19:36:50ID:???そうだね。
「ハッシュの配列では扱いにくい」と言ってるってことは、
PDOが連想配列で返すのを不便だと感じているという事だもんね。
俺は>>550と同意見だった。
オブジェクトが返ってくる事自体にまったく利点を感じないのだ。
データベースエンジンの差異を吸収するのはORMの副産物だと思うし、
それをやってくれるORMじゃないライブラリは好きなので、
やっぱり俺は世にあるORMにはあまり意義を感じていないのかも知れない。
バリエーションって何？
0585nobodyさん
2008/05/18(日) 00:27:53ID:???http://itpro.nikkeibp.co.jp/article/lecture/20070419/268987/
モデリングの過程がオブジェクト指向じゃないと、あまり劇的に便利という実感は湧かないかな？
0587nobodyさん
2008/05/18(日) 02:08:18ID:???0588nobodyさん
2008/05/18(日) 04:15:22ID:???0589nobodyさん
2008/05/18(日) 08:26:46ID:???0590nobodyさん
2008/05/18(日) 18:14:47ID:???単にデザインセンスだけでなくプログラマ的な素養が必要
お前らのデザイナはDRYでびゅーちふるなCSSを書けるの？
それともお前らが手直しするの？
0591nobodyさん
2008/05/18(日) 22:23:00ID:???0592nobodyさん
2008/05/18(日) 22:31:44ID:???因みに俺のところでは手直しも指導も回答も全部俺がやっている。
つうか、エディタを使う作業は、たいがい俺に回ってくる。
一度も書いたことがないASをいきなり書けたら天才呼ばわりされた。
ほとんど使わないエクセルでマクロをいきなり書いたときもそうだった。
冗談じゃない、感心するなら金くれと言いたい。
うぇぶでざいなー（笑）の100倍は貰って当然だろ、本気で。
0593nobodyさん
2008/05/19(月) 00:14:19ID:???ウェブアプリって、一覧画面なら連想配列の配列、詳細画面なら連想配列でDBから情報を取得して、HTMLという静的な状態に移す、ほとんどはそれで済む話。
複雑なロジックを伴うクラスが必要な場合だけクラスにすればいい。そういうクラスはDBからだけで構成されるわけじゃない。ORMからさらにDAOと2重にラップする必要はない。
0594nobodyさん
2008/05/19(月) 22:23:22ID:???それをモデルとして便利にする方向はある意味自然か
0595nobodyさん
2008/05/20(火) 17:15:34ID:???0596nobodyさん
2008/05/20(火) 17:39:18ID:???http://jp.techcrunch.com/archives/20080519job-cuts-at-php-startup-zend-could-be-aimed-with-an-eye-towards-a-sale/
PHPそのものはともかく、ZendFrameworkとかは影響うけるかもね。
0597nobodyさん
2008/05/20(火) 17:46:06ID:???ってなるに500ペリカ
ZFなんかを使っていた先見の明ない奴ら涙目ｗｗｗ
0598nobodyさん
2008/05/21(水) 11:31:16ID:???俺は捨てるｗｗｗ
0599nobodyさん
2008/05/21(水) 15:22:14ID:???0600nobodyさん
2008/05/21(水) 15:48:10ID:???そのフレームワークの機能はIISでしか動かないみたいなのはあるかもよ。
あぁ、想像しただけで嫌だ。
0601nobodyさん
2008/05/21(水) 22:30:45ID:???0602nobodyさん
2008/05/21(水) 23:44:23ID:???GoogleとかYahooとかAmazonとか楽天とかMixi見たいな大手で。
もちろんMicrosoftのサイトは除いて。
直感だけど、MSのフレームワークが前提になったらPHPは確実に死ぬと思う。
0603nobodyさん
2008/05/22(木) 00:36:44ID:???うちJavaに次いで.net/レガシーASP案件が多いよ
でもASPはイントラ用途での案件ばっかりだな
IISに.netにMSSQLにPowerShellにVSSと、MSモノで固めた場合は
けっこういい環境だと思うんだけどねー。
MSモノだけやる訳じゃないせいか、誰もVisual Studio使ってないけどw
つまり、MSモノで固められるケースが限られるのが問題なんだろう。
レン鯖とかでも（Javaともども）機能制限しにくい故にユーザに提供しにくいしな。
その隙間をPHP需要が埋めているんじゃないかい。
0604nobodyさん
2008/05/22(木) 01:06:04ID:???まさかのM$大逆転
0605nobodyさん
2008/05/22(木) 01:06:57ID:???結局さ、ASP.NETが良いのってSIerにとってでしかないと思うんよ。
小さく使われる、汎用性がないプログラムとしてと言うか。
そういう前提がなければ PHPなりPythonの方が有用だから、大手のサイトでは
ＰＨＰやPythonなんかが使われてるじゃかなろうかと思ってる。
仮にＭＳに買収されたら、PHPはPHPらしさを残せるかのかなぁ。かなり不安。
0606nobodyさん
2008/05/22(木) 01:11:58ID:???0607nobodyさん
2008/05/22(木) 01:22:14ID:???っていうかDreamWeaverとかじゃねえのそれ
0608nobodyさん
2008/05/22(木) 13:40:13ID:???ただ、イントラ以外の、一般のウェブサイトの場合、結局凝ったデザインを実現するための泥臭い部分に多くの労力を割かれるので、ASP.NETのメリットは薄れる。
後は、LAMPみたいに全部無料ではないので、中小規模の場合、LAMPを選択することが増えるだろうな。
0609nobodyさん
2008/05/22(木) 15:06:08ID:???会社・技術者も多いんだけどね。特にCGI等の設置運用あたりからぽこぽこ出来た会社はｗ
0610nobodyさん
2008/05/22(木) 15:43:18ID:???そういう仕事を片付けるためのFWじゃねーのかよ
コミュニティベースかそうじゃないかで
出来が云々とかいかにもMSのバカ顧客らしい発想だ
その作りこまれたFWとやらで死ぬまで
綺麗で泥のないアプリを作りつづけてろ
0611nobodyさん
2008/05/22(木) 16:11:39ID:???想像だけど、 確実にMS は Yahoo みたいな超大規模なところには、ほとんど無料で使えるような
営業をかけてると思う。仮に Yahooのサイトが ASP.NETで運用されれば、広告効果大きいし。
だから、ASP.NETが PHPとかPythonより大規模なサイト構築に向いていれば、使ってないはずがない。
パフォーマンスの問題か、セキュリティに対する透明性の問題か、生産性の問題化は判らんが、
大規模なサイトにおいては ASP.NETは PHPとかPython以下という評価がされているだけだと思う。
中規模なところには普通にしか販売しないだろうから、ASP.NETはイントラみたいな小規模なところでしか
使われない気がする。SIerとしては、そっちのほうがマーケットが広いだろうから、そんなに悪い話でもないけど。
0612nobodyさん
2008/05/22(木) 17:50:15ID:???0613nobodyさん
2008/05/22(木) 23:15:21ID:???Apacheが強いのは予算のないところとか、２ちゃんみたいにひたすらウェブサーバの数を増やしたい大規模なサイト。
0614nobodyさん
2008/05/22(木) 23:18:13ID:???0615nobodyさん
2008/05/23(金) 00:01:10ID:???あんまりASP.NETを使用してないんでしょ？やっぱ本質的な問題があるんじゃないの。
事例見ても、イマイチぱっとしないし。
http://www.microsoft.com/japan/msdn/asp.net/technologyinfo/showcase/
0616nobodyさん
2008/05/23(金) 00:55:23ID:???本質的な問題、とやらがあるのかどうかは判らんけど、
「ソースが公開されてていざとなれば力技が効く」世界とは180度方向性が違うからねえ。
その事例のリード文で処理規模謳ってるのはセガダイレクトくらいか
「.aspx」で終わるURLぐぐるといろいろ出て来るけど、大規模サービスって感じのはないなー。
リネ2のwebとかJR東の運行情報とかパンヤのwebとか地図閲覧サービスとか
まあそれなりに規模あって安定性が望まれるサービスも垣間見れるね。
致命的な弱点があるようには見えないな
オープンソースじゃない事、ってのは一つの理由になると思う。
0617nobodyさん
2008/05/23(金) 01:25:55ID:???俺は文字列と、文字列が入った配列を再帰的にエスケープして、
オブジェクトはそのままviewに渡してるけど
0618nobodyさん
2008/05/23(金) 06:55:54ID:???本質的にはhtmlを生成するときにその場でコンテキストにあわせてエスケープするのが適当だよ。
htmlに入れ込むといってもテキスト要素として入れ込む場合と属性値としてクオートの中に入れるばあいなんかに分かれるから。
0619nobodyさん
2008/05/23(金) 10:28:17ID:???日本は今でもApacheしか対応してないレンタルサーバ屋が多いけど、アメリカは昔からレンタルサーバ屋がIISとApache両方対応してた。
Fortune1000を対象にしたシェア調査が少し前に話題になったけど、大企業のコーポレートサイトなど、予算のかけられるところはJavaやASPが強い。
PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
0620nobodyさん
2008/05/23(金) 10:29:53ID:???0621nobodyさん
2008/05/23(金) 10:52:28ID:???それにしても2回に分けて書くのは芸風か。
0622nobodyさん
2008/05/23(金) 13:01:37ID:???↑俺のことですねｗ
Webアプリは、PHPとJavaしか使ってない★
ASP.NETじゃないと実現できない機能は今のところ無し(・∀・)
どうしてもASP.NETじゃないと無理なら手を出しますが、他の実現方法を探すかな？
…というかMS製品しか使っていない客には当たったことないです（ラッキー！？）
0623nobodyさん
2008/05/23(金) 13:04:32ID:???大手＝PHPを使わない企業という定義でOKですか？
そんなわけねーだろｗｗｗｗｗｗ
0624nobodyさん
2008/05/23(金) 13:14:15ID:???自分が便利だと思ったら使えばいい
他人の判断、他人の価値観を気にして、他人に認められたいと思う演技を続ける人生は、勝ち組じゃない
奴隷じゃないなら、最後は自分の判断で決めろ
…俺はRuby、Pythonの準備をしときますｗ
0625nobodyさん
2008/05/23(金) 13:28:14ID:???Javaなんかだと顧客側が動作環境を WebsphereとかWeblogicに限定してるところ
は多いでしょ。SI案件だとフリーの環境は一切使いたくないってのは普通だし、
そういう客のほうがカネ払いもいいだろうし。
ただ、そういうのは技術的な判断じゃないから、これをもって技術的にも良いはずって
言うのは愚かしいと思う。
0626nobodyさん
2008/05/23(金) 17:03:53ID:???よくいるよな、おまえみたいな無知ｗ
属性値はいわばRCDATAなのでHTMLエスケープに関してはPCDATAと全く違いなし。
現在のほぼ100%のUAが、属性値もエスケープされていることを見込んでパースしている。
0627nobodyさん
2008/05/23(金) 21:22:09ID:???618じゃないけど
RCDATA、PCDATAという用語は初めて知った。
参考になったよ、ありがとう
データ形式一覧
http://bakera.jp/ref/html/dataformat
#PCDATA (構文解析対象文字データ) の解説
http://bakera.jp/ref/html/dataformat/pcdata
PCDATA は Parsed Character Data の略で、「構文解析対象文字データ」です。
RCDATA (置換可能文字データ) の解説
http://bakera.jp/ref/html/dataformat/rcdata
Replaceable Character Data、「置換可能文字データ」です。
0630nobodyさん
2008/05/24(土) 22:37:13ID:???0631nobodyさん
2008/05/25(日) 11:29:57ID:???PHP on IIS - MicrosoftがPHPをフルサポート
http://www.microsoft.com/japan/opensource/php/default.mspx
【Special Seminar】 PHP on IIS - あなたの可能性を広げる、Windows 環境へ -
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032377878&Culture=ja-JP
0632nobodyさん
2008/05/25(日) 13:35:47ID:???0633nobodyさん
2008/05/25(日) 16:38:21ID:???javascriptのエスケープはコンテキストによって、
ブラウザによって必要とされるものは違うでしょ。
「HTMLエスケープ」っていう言葉が悪い気はするけど。
0636nobodyさん
2008/05/26(月) 09:16:56ID:???>>635
http://www.google.co.jp/search?hl=ja&q=javascript+%E3%82%A8%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%97+%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%83%8F%E3%83%B3%E3%83%89%E3%83%A9&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
0637nobodyさん
2008/05/26(月) 09:25:06ID:???ユーザ入力でタグの中に何かを出力する場合(ほとんど無いけど)は、
ホワイトリスト方式。
0638nobodyさん
2008/05/27(火) 23:55:46ID:???PHPなんて、なーんも考えずに工夫せずにコピペ最強でサクっと済ませられる「フレームワーク」なんだがな。
0639nobodyさん
2008/05/28(水) 01:02:34ID:???話を単純化し過ぎ
0640nobodyさん
2008/05/28(水) 01:55:54ID:???規模がでかいと、謎エラーの出所が分かんない場合あるよね。
何回も呼んでるフレームワークの関数で、止まる時とかさ。
大概人的ミスだから、CVSとかで誰がやったか、すぐにばれるんだがな。
そんな時はブーブー文句垂れるおｗ
0641nobodyさん
2008/06/06(金) 02:37:05ID:???apacheのプロセス数が増えるとメモリが圧迫されてmemcacheが消えるね
一台の鯖で稼働できるプロセス数かなり減らね？
0642nobodyさん
2008/06/06(金) 07:32:19ID:???やっぱPerl?
0643nobodyさん
2008/06/06(金) 08:14:24ID:???0644nobodyさん
2008/06/06(金) 08:18:17ID:???はてなもPerlだし、やっぱPerlなのかな？
0645nobodyさん
2008/06/06(金) 08:56:45ID:???1リクエスト毎にドラクエ4の全容量以上のメモリを食うって一体…
0646nobodyさん
2008/06/06(金) 08:57:39ID:???まぁ、続きは向こうで。
【Perlフレームワーク】Catalystを語る人
http://pc11.2ch.net/test/read.cgi/php/1168406385/
0647nobodyさん
2008/06/07(土) 08:06:42ID:???Perlの場合、Catalyst含めて、独立したモジュールが集合して構成されるので、PHPのようなウェブフレームワークとは意味が違ってくる。
0648nobodyさん
2008/06/07(土) 12:29:05ID:???PHPでは関数やエクステンションで提供されてるだけの話で
本質的にはたいして変わりなくね？
0649nobodyさん
2008/06/07(土) 19:46:49ID:???0650nobodyさん
2008/06/07(土) 21:25:56ID:???大体だれかが野良クラスで対応するじゃない。
パフォーマンスにしたって、それ以外の部分でがっつり重いFWも結構あるし。
もうViewクラスを作るのはほぼ共通なんだから、Zendがなんか作ってくれ
ないかな。if と foreach と変数展開（オブジェクトのメソッド呼び出し含む）と、
スクリプトでregisterしたヘルパメソッドのみが使えるとかいう感じで。
PDOみたいに組み込みクラスで速ければ、とりあえず俺は多分それを使う
0651nobodyさん
2008/06/08(日) 13:31:14ID:oe9fgjbi0652nobodyさん
2008/06/08(日) 23:13:03ID:???http://d.hatena.ne.jp/shimooka/20071111/1194764798
0653nobodyさん
2008/06/09(月) 02:02:29ID:???0654nobodyさん
2008/06/09(月) 13:52:03ID:???BlitzはPHP拡張として作られているから、PHPそのものといえる。
SmartyもPHPそのものに変換されるから、PHPそのものといえる。
0655nobodyさん
2008/06/09(月) 14:03:38ID:???0656nobodyさん
2008/06/09(月) 14:28:34ID:???それ以外にテンプレートエンジン使ってる奴がいたとしたら救いようがないうつけ者だな
0657nobodyさん
2008/06/09(月) 17:37:34ID:???これは違うだろ。うぇぶでざいなあが作る段階でPHPじゃないのだから。
0658nobodyさん
2008/06/10(火) 00:15:51ID:00QPcxQHWEBデザイナー兼WEBプログラマーな私はSmartyを使っておりました。
最近はテンプレートは生PHPで充分ということに気付き、原点回帰しました！
0659nobodyさん
2008/06/10(火) 05:28:42ID:???スコープを確保するためにファイルを読み込んでeval()してそうな気もするんだが、違うのかな。
それとも、グローバルにオブジェクト（や関数）を置いて、それを参照するのを前提にrequireなの？
0660nobodyさん
2008/06/10(火) 09:31:44ID:???実行されるので、別にeval()する必要は無かろう。
っていうか、そんなPHPフレームワークあるの?
RoRはerbでevalしてるが。
0661nobodyさん
2008/06/10(火) 11:18:10ID:???MVCはいいけど、そのためにいろんな「専用の」クラスの使い方
を覚えなければいけないし、覚えてもZFのみってことは、
別のFWに変更するときや、ZF自体が消滅（ありえない？）するときには、
その資産がチャラになっちまうんじゃないの？
大規模開発に向いている、プログラミングの標準化ができるってのが
ウリだと思うけど、FW乗り換えなんかを考えるとデメリットも大きいよな。
そんなんだったら、自分のシステムに必要なクラスを自分で作って
充実させていったほうがいいのかな．．．．とも思う。
まあ、その維持管理が大変といえば大変だが、資産が消滅することや
方針変更で別のものに作り変えるときでも、ノウハウが残るから、
長期的なスパンでみるとメリットがあるんじゃないのかなあ。
特にシステム開発環境を選択している人、そういう問題点ってどう考えている？
0662nobodyさん
2008/06/10(火) 12:12:38ID:???俺俺FWは、俺しか使えない。
他人が使うと、学習コストがかかる。
ましてや、俺と仕事するときにしか使えない。
その点、ZF等のFWは既に学んでいる人々がいる。
その人たちと共同で仕事ができる。
独りでできるもんっ♪なら俺俺でFA
既に学習した人たちのTips等を利用したり、
共同で作業したいなら、
既存のFWでいいんじゃね？
0663nobodyさん
2008/06/10(火) 12:15:11ID:???大体、オープンソースなんだからZF自体が消えてもコード資産はまるまる残るだろう。
まぁノウハウって奴を蓄積したいのならべつにどうぞ
0664nobodyさん
2008/06/10(火) 12:27:28ID:???ZFが死んでもなんとかなるじゃん
0665661
2008/06/10(火) 13:05:21ID:???確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
その内容を整理して文書にすればいいんじゃないのかな。
それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
無い分だけPHPを使える人は多いし、知らない人もちょいと学習すれば
使えるようになる。
>>663
ZFが消滅してもオープンソースだから残るだろう。
でもセキュリティホールや新しい技術は一切入ってこないよねえ。
>>664
ラッパーという手はあるが、実際簡単にいく？
0667nobodyさん
2008/06/10(火) 13:17:29ID:???だからさ、その心配はZFが無くなってからすればいいってこと。
そんなもん心配していまから俺フレームワーク作るわっていうのなら、
セキュリホールだのなんだのはどっちみち全部自分で面倒みるんだろう?
0668nobodyさん
2008/06/10(火) 14:27:18ID:???> その内容を整理して文書にすればいいんじゃないのかな。
その文章を読まないといけないだろ？
初めて会った人が、あんたが書いたオレオレ文書を
すでに読んでいるなんてことはまずありえない。
その点ZFなら読んでいることはありえる。
> それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
オレオレFWの制約を受けるだろう。
何の制約もないフレームワークがあったとしたら、それは
フレームワークじゃなくて、ただのライブラリだ。
> 知らない人もちょいと学習すれば 使えるようになる。
使えるということと、開発の早さ・楽さは別の話。
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
オレオレFWは、すでにセキュリティホールや新しい技術は一切入ってこないよねえ。
0669nobodyさん
2008/06/10(火) 14:50:32ID:???WEBアプリのFW全般に対するノウハウってのもあるし
現に今のFWはほとんどMVCベースなわけで
基本的なコンセプトが大きく変わるわけじゃない
個人的なFWを作って使うのも別に悪くはないと思うけど、
オープンソースで開発されているFWが
どれだけレビューされてテストされた上で
リリースされているかよく考えてみるべき
乗り換えたら全部チャラだし俺俺FWの方がいい、
と安易に考える奴は自惚れてるとしか思えない
FWが変わったら覚えた事が全て無駄になる、ってのは
結局表面的な部分でしかFWを扱えてないわけで
FWに「使われている」プログラマでしかないよ
0670nobodyさん
2008/06/10(火) 15:11:29ID:???一回メジャーなFW使ってみてから手を出すならともかく
0671nobodyさん
2008/06/10(火) 16:42:19ID:???自分で作るのが、そんなに悪い選択とは思わないけど。
0672nobodyさん
2008/06/10(火) 17:28:40ID:???0673661
2008/06/10(火) 17:29:20ID:???FW乗り換えでも、MVCの考え方やノウハウは残るが、
現実的にアプリはすべて書き換え。
数十本ならそうでもないが、1000本単位なら相当な手間。
「FWに使われているプログラマ」はいいけど、現実的に手間を
掛けられないというところをわかってないのは問題。
同じFWに縛られ続けていくのはいいが、消滅しちゃったとき
どうやって資産をメンテしていくのか。
そういう意味でチャラって書いた。
だから >>665 が書いたようにオープンソースであること
を考えると、そういった問題が解決できそうだ。
また多くの人が使ってこなれている面はメリットだよな。
それで、実際どれだけのモンがFWで構築されてんだろ。
cakePHPなんかも有名だが、ZFが出て乗り換えを考える
人もいるだろうし、どうするんだろ。
0674nobodyさん
2008/06/10(火) 17:32:43ID:???ショボfwじゃん
0675nobodyさん
2008/06/10(火) 17:35:53ID:???それは普通にソースツリーをフォークしてメンテするだけだろう?
自分でゼロから作るよりは随分と楽だと思うが。
0676nobodyさん
2008/06/10(火) 19:10:47ID:???採用しているFWが変わったからって
既に出来上がってるアプリをそのFWに
全て書き換えるケースなんてそうそう無いだろ
完全な自社コンテンツでアクティブなものか
コンテンツ自体を総リニューアル時に合わせて移行、くらいなもんで
元から運用してるものは普通そのままメンテだろ？
千本単位とかそれこそ非現実的じゃないか？
0677nobodyさん
2008/06/10(火) 19:46:40ID:???世界全体でも1000もないだろｗ
0678nobodyさん
2008/06/10(火) 21:11:39ID:???↓
少し釣れる
↓
ツンデレ教えて君
こうするとggrksと言われないんですねわかります
0679nobodyさん
2008/06/10(火) 21:26:00ID:???↓
突っ込まれる
↓
雲隠れですねわかります
0680661
2008/06/11(水) 09:37:45ID:???なるほど、すべて書き換えないケースもあるな．．．．
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。
>>677が書いたように、事実上PHPのFWはまだまだ
浸透していない、PHPでの開発は結局小規模なもののみ
ってことなんかな。
0681nobodyさん
2008/06/11(水) 09:58:12ID:???大規模開発って、ふつうプロジェクト数のことじゃなくて、
ユーザ数とか、高信頼性を確保するために大きいシステムを組むってことだろう?
そんなものは、当然一件ごとに何年もかかることがままあるから、
大規模なプロジェクトを千なんてオーダーで抱えてるとこなんてありえないよ。
ていうか、自分が抱えてもいない数のプロジェクトの事と、
(まだつぶれていない)ZFが潰れることを心配して
自分で作った方がいいと思ったの???
0682nobodyさん
2008/06/11(水) 23:15:02ID:???もうとっくに殆どの環境はPHP5に移行している。
lib/php内やフレームワークのコードだけがPHP4。
自分で書く時、例えば、varなんて使う機会が無い。
そのせいで、細かく曖昧さを指摘する目に見えないエラーがリクエスト毎に何10何100と出ている。
0683nobodyさん
2008/06/11(水) 23:37:36ID:???>>661 ではないけど、大規模開発って言ったら、コード量をイメージするなぁ。
大規模サイトだと、ユーザ数が多いって意味なのかなぁって感じもするけど。
外部のフレームワークの適用については、例えばバグとかセキュリティホールが
あるからバージョンアップしてくださいって言われても、影響範囲が読めないと
二の足踏むし、かといってそのままってのも気持ち悪いし、自作しても知れてる
程度の使い方しかしないのなら、使いたくないってのは良く分かる。
0684nobodyさん
2008/06/12(木) 00:08:14ID:???一番初めに書いてあるS2Container.version.tgzを落としてきたら拡張子が.tgになってるし、
＞S2Container.php と S2ContainerSplAutoLoad.php を require して下さい
って何のファイルに書けばいいのか書いてないし・・・。
0685nobodyさん
2008/06/12(木) 00:18:48ID:???pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの？
で、PEARのディレクトリってPHP5を入れた時点でパス通ってて、
ソレを、これから加工と思ってる空のPHPにrequire_onceで例に書いてあるとおりに書けばいいんじゃないの？
違うの？
0686nobodyさん
2008/06/12(木) 04:04:39ID:???個人的に、pearコマンドを使わないインストール方法をきちんと書いてくれないFWは信用できない。
S2Containerは触ったこと無いけど。
最初からPEAR必須ライブラリも把握できるし、必要最低限の設定等がわかっていれば、環境を
変えるときも対処しやすいと思う
0687681
2008/06/12(木) 12:13:00ID:???つまり、アップデートのパッチを調べる労力 > 自分で書く+メンテする労力
ならば自分で書いてもいいってことね。で、コード量が少ないなら
書くのもメンテするのもたいした労力はいらないからそれもあり、と。
まぁそういう理由なら納得できる。
個人的にはFWを導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。
大規模開発ってやつについては、言うとおりコード量もあると思う。
なんていうか、大規模開発っていうのはプロジェクト一件あたりの
必要な金、期間や人力がデカいっていうことで。
0688nobodyさん
2008/06/12(木) 13:50:39ID:5LtH7vFxSeaserは簡易版のTeedaに期待
0689nobodyさん
2008/06/12(木) 23:10:10ID:???全部 Ajax 経由でいいと思う。
何かする度に、フォームの全ての値がサーバに送られて
画面全体がリロードされるのって変すぎる。
で、Ajaxと一体になってるフレームワークって何かありませんか？
0690nobodyさん
2008/06/12(木) 23:17:19ID:???極端な意見ｷﾀｰ
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞｗ
で、そんなFWはこれから大流行するだろうから、しばらくのんびり待ってたら？AIRとかもあるしね
0691689
2008/06/12(木) 23:58:39ID:???作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。
Ajaxから戻ってきたデータによって、JavaScriptで画面上の
変化部分を更新するとか、ある程度自動でできる仕組みがあると嬉しい。
更新したデータは、セッション変数で保持してればいい。
かと言って、ブラウザにプラグインが必要になるような技術もいやだな。
今のWebと親和性をなるべく保ちながら、より自然な開発がしたい。
もうちょっと真剣に探してみるかな。
0692nobodyさん
2008/06/13(金) 00:15:02ID:???>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。
どうしてもその手の処理が必要な時は
「ユーザに断ってから」Applet立ち上げれば今時でさえ通じるもんだ
他不要
0693nobodyさん
2008/06/13(金) 00:25:04ID:???サーバサイドはPHPで、クライアントはJavaScriptなりFlash(ActionScript)なりっていうのが
面倒ってこと？
>>691で書いているくらいやりたいことが決まっていれば、例えばW3CとECMAScript標準に
完全準拠の理想フレームワークなら、作ろうと思えば作れるかもね
どのみちデザインのためにHTMLで小細工しなくちゃいけないなら、それがやりにくい様なフォー
ムデータの扱いを強要するFWは結局流行らないだろうと思う
Ajaxを含むJavaScriptやFlashの技術は、まさにクライアント依存の妥協案というか手法というか、
っていう部分なんだから、それをサーバ側の組み方と違うと言って敬遠していては現状何も作れ
ない、とみんなそう思ってるんじゃないかなあ
だから、俺は今日もしこしこ正しいかどうか解らないJavaScriptを書きますよ、と。
0694691
2008/06/13(金) 01:22:41ID:???違和感ってのは、>>689に書いた内容です。
画面の一部を変更したい時でも、画面全体に影響があるので、
プログラムがそれを考慮した構造になり、分かりにくいものになってしまいます。
GETとPOSTを分けたりすると、更に分かりにくくなります。
WindowsのGUIプログラミングのような開発ができたらいいなと。
イベントドリブンで感じで。
サーバサイド言語 + JavaScript (Ajax含む) でそういう仕組み
になってるフレームワークがないかなと思ったんですよね。
今の自分の作り方が悪いだけかもしれませんが。
0695nobodyさん
2008/06/13(金) 02:12:02ID:???イベントドリブンって言葉だけに反応すると、
PRADOとか、PHPのフレームワークはイベントドリブンらしいよ。
後、Ajaxだと、AjaxCoreとかってフレームワークがあるみたいだけど、ここら辺組み合わせたらなんかできるのかな。
0696nobodyさん
2008/06/13(金) 02:15:42ID:???Windowsフォームのアプリケーションと同じことをウェブに求めるのは無理がある。
凝ったウェブデザイン（というか、普通のエンドユーザ向けウェブサイトで求められるデザイン）を、DOMによるCSSの操作だけでデザイン対応するのは相当無理がある。
そこまで機能性を求められるアプリなら、.ウェブアプリじゃなくてNETのアプリにするのが妥当と思うし、マルチプラットフォームにしたいならJavaでも使えばいいと思う。
0698nobodyさん
2008/06/13(金) 23:34:10ID:???0699nobodyさん
2008/06/13(金) 23:43:31ID:???0700nobodyさん
2008/06/14(土) 00:22:27ID:???0701nobodyさん
2008/06/14(土) 00:27:33ID:???kwsk
運用上でも昨今のAjaxライブラリの伏魔殿具合見ても、
けっこ前に壁にぶちあたったきり進歩がないしな。
javascript1.7以上が普及してくれれば、スコープ汚しまくりで
setTimeout地獄な糞Ajaxの現状を打破できるのかもしれないが。
air入れてる奴もsilverlight入れてる奴も見ないしな
Ajaxは割り切って使うに限る。
GoogleはFlashも使ってる。必要に応じて適用してるだけじゃないのかね
0702nobodyさん
2008/06/15(日) 14:13:27ID:???mysqlのスロークエリみたいに
処理速度が遅ければログ取る機構とか付けてる？
てかそんなのフレームワークの標準機能で付けとけよ
0703nobodyさん
2008/06/16(月) 12:59:18ID:???0704nobodyさん
2008/06/18(水) 02:05:34ID:ZYTHmHR00705nobodyさん
2008/06/19(木) 21:58:18ID:???0706nobodyさん
2008/06/19(木) 22:29:31ID:???0707nobodyさん
2008/06/20(金) 00:37:33ID:???0708nobodyさん
2008/06/20(金) 00:41:52ID:???0710nobodyさん
2008/06/20(金) 02:15:40ID:???0711nobodyさん
2008/06/20(金) 12:38:43ID:???0712nobodyさん
2008/06/23(月) 10:47:52ID:isKyS0yI以下、個人の感想だが、設計は面白いが、web用のフレームワークとして間違った方向に行ってる気がしたので、実践では使ってない。
フレームワークの勉強をするにはいいとは思うよ。
0713nobodyさん
2008/06/23(月) 16:04:32ID:???PRADOは構築ルール縛りをするには良いとおもう。
開発効率は生だとものすごく悪いので、Radを待つか自前でつくるなりしないと使い物にならん。
0714nobodyさん
2008/06/25(水) 00:06:13ID:???CIからforkして、PHP5 Strictと安定性・堅牢性を進めると聞いてるけど。
ググっても日本語サイト少ない・・・
0715nobodyさん
2008/06/25(水) 01:09:00ID:???日本語情報どころか英語の情報もあまりない。
0716nobodyさん
2008/06/25(水) 11:12:53ID:2TehNRcN詳しく書かないでｽﾏﾝ。
自分の感じた事を伝えようと思って、昔実験したサンプルを見ながら今書いてるんで現在のバージョンとは違うかもしれんけど
home.page
<com:TForm>
<com:TButton Text="Click me" OnClick="buttonClicked" />
</com:TForm>
確か、テンプレート風にこう書いて
Home.php
class Home extends TPage
{
public function buttonClicked($sender,$param)
{
$sender->Text="Hello World!";
}
}
で、アクションはこう書くだろ？
なんか、symfonyだと（というか、俺の主に使ってるフレームワークがsymfonyなのでそれとの比較になるが）request、responseっていうのがあって、webアプリなんだなぁ、と見るからに分かるんだが、
Pradoの場合、これ見るだけだとwebアプリだって分からないんじゃない？と思って「間違った方向」って言ってしまったんだ。
あくまで個人的な感想だと思って「間違った方向」については受け流してくれ。
# 改めて見るとやっぱり面白いフレームワークだとは思うな。
# ただ、実際に使うのは、request responseが無いとか、どうしても実装に何か無理がありそうな気がしてしまう、というのが感想な訳だ。
# バリバリに使ってる人の感想を聞いてみたい所かも？
0717nobodyさん
2008/06/25(水) 13:22:19ID:???0719nobodyさん
2008/06/25(水) 19:18:36ID:???いまいち『フレームワーク』ってのがわからないんです。
ググって調べたりしてるんだけど、『？』な感じなんです。
すご～くカンタンでいいんで説明してくれる方いませんでしょうか？
あと、こんなオレにおすすめの本あったら紹介して下さい。
プログラムは一応、データベースとか使って基本的なCMSとかつくれます。
今度、作ろうと思ってるサイトがあるんですが、『フレームワーク』ってのを
使った方がいいような感じがしてここへきました。
よろしくお願いします。
0720nobodyさん
2008/06/25(水) 19:20:21ID:???0721nobodyさん
2008/06/25(水) 19:39:02ID:???framework
【名】
1. 骨組み｛ほねぐみ｝、フレームワーク、枠組み｛わくぐみ｝、下部構造｛かぶ こうぞう｝、骨格｛こっかく｝
なんか作るときに土台が出来てると楽だろ？
でもその土台に制限されてしまうこともある。
0722nobodyさん
2008/06/25(水) 19:49:30ID:???ありがとうございます。
ググってました。
『車』で例えるとしたら、
”キーを回すとエンジンがかかる”とかの仕組みができていて
一から作らなくてもいいってことなんでしょうか？
『いろんな仕組みのセットがあって、ボタンひとつで簡単に組み込める』
みないな感じですかね…？
0723nobodyさん
2008/06/25(水) 20:15:21ID:???家を建てるに当たって、その骨組みが出来ているって感じ。
で、その骨組みに合わせて作っていくので、やりやすいよと。
>>722の車の例えだと、PEARとか見たいなライブラリだね。フレームワークではない。
0724nobodyさん
2008/06/25(水) 20:27:52ID:???ありがとうございます。
ってことは、一戸建ての骨組みができている状態からスタートして
中身の部屋とかキッチンとかを入れて（？）いく。ような感じ？
フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？
今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。
0725nobodyさん
2008/06/25(水) 20:34:00ID:gyu7FUKSPHPを粘土と例えて、像を作ってみよう、という事になった時の事を考えてみると
いきなり粘土で像を作る事はできると思うが、やっぱり、予め骨組みあった方が作りやすいだろ？
でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
>>716
なるほど。という事は現在は大分変わってるのか。
そのうち、また見てみる事にするよ。
0726nobodyさん
2008/06/25(水) 20:34:34ID:???そういうところで悩む人は、多分人のソースなんかあんまり読まない様なタイプの
人だろうから、いっぺん使ってみるのは勉強になるんではないかと偏見だけど思う。
まあ業務に使うかどうかは置いておいて、PHPでお仕事しているんなら触って損は
無いかと思う。
0727nobodyさん
2008/06/25(水) 20:40:00ID:???0728nobodyさん
2008/06/25(水) 20:41:46ID:???ページの遷移部分だとか、データの検証(バリデーション)部分だとかが簡単に出来たり、
フレームワーク自身が持っているライブラリが便利だったりとか。
データベースへのアクセスに関しては各フレームワーク共に工夫されてて凄く使いやすいです。
＞フレームワークの違いってのは、その『骨組み』がマンションだったり一戸建て
だったりするってことなんでしょうか？
そうですね。「ちいたん」見たいなライトウェイトなフレームワークは一戸建てな感じで、
synfonyやEthnaやCakePHPなんかはマンションみたいな巨大なプロジェクトの開発に向いてるかと。
＞今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
普通（？）に作るのがいいのか。という所なんです。
フレームワークは、できるなら使ってみたほうがいいと思います。
開発の規模や趣味趣向によって合う合わないってのはあると思いますが、
プログラムを組む上での手法として、勉強になる部分は大きいですし。
とりあえず、賛否両論歩けど、CodeIgniterなんかを触ってみてはいかがでしょう。
日本語のマニュアルが充実しているのと、割かしライトウェイトなので、扱いやすいのではないでしょうか。
0729nobodyさん
2008/06/25(水) 20:43:00ID:???ありがとうございます。
>>でも、骨組みが、犬の骨組みだとしたら、人間の像を作るのは却って難しいと思う。
これ気になります…
>>726
ありがとうございます。
自分はまだ、人のソースをじっくり見て分かる所まで行ってないと思います。
なんか、好きなようにしたくて。ソースはかなり変かもしれません。
今『CakePHP』の関連サイトを見てました。
CakePHPってどうでしょうか？
明日、ジュンク堂とか行って関連本探してこようと思います。
0730nobodyさん
2008/06/25(水) 20:46:21ID:gyu7FUKS>今、悩んでいるのは、フレームワークを使った方がいいのか、今までのように
>普通（？）に作るのがいいのか。という所なんです。
なるほど。フレームワークを学習するのには、コストがかかるからそういう風に悩むのは正しい姿勢だと思うよ。
で、まずは、どれだけの時間があるか？という所をはっきりさせるべきだと思うね。今書いたように「コストがかかる」から。
フレームワークを使わないでもできない事はないレベル & 時間が無い（半年以下）なら、たぶん今まで通り作った方がいいと思う。
（半年、というの人によるかな。でも、最低1ヶ月は学習する時間が欲しい。）
かなり大きなアプリになる予定（設計がまだ未定。先が見えない）& 時間がある、というのなら、なにかフレームワークを使う事を考えた方がいい。
後で付け足す事になったとしても、フレームワークで作ってあると、部品を付け足せるように設計されている（事が多い）からね。
・・・実際のお客様というのは、かなーり想定外の要求してくるから、それでも吸収できないくらいの事を言ってくる事もあるんだがな・・・
0731nobodyさん
2008/06/25(水) 20:47:14ID:???0732nobodyさん
2008/06/25(水) 20:53:37ID:???ってか、みんなレス早いな。
>>でも、骨組みが、犬の骨組みだとしたら
実際には、webアプリの骨組みだから、あまり気にしないで大丈夫だと思う。
まぁ、時間あるならいくつかいじってみて、そのフレームワークの癖を見ておくのもいい勉強になるはず。
（あぁ。結構勉強してそうだからこんな事言っちまったが・・・たぶん、PEARを使いこなせる・・・使えるくらいの力量あるよね？もし無かったとしたら、まずは、ライブラリを使いこなせるようになってから、がいいと思う。）
# Cakeについては、使ってないので他の方に
0733nobodyさん
2008/06/25(水) 20:58:58ID:???CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、一回作っていいかもしれない。
普通にプログラム作ってるだけだったりすると、なんでこんな動きするのか分からないような動きする。
今後、フレームワークを使わないプログラムを書くにしても、凄く勉強になるよ。
0734nobodyさん
2008/06/25(水) 21:03:51ID:???ありがとうございます。
CodeIgniterってのは聞いたことがなかったのでちょっと
見てきます。
>>730
ありがとうございます。
メインはデザイン仕事でやっているので、時間はそれなりに
とれそうです。
自分としても勉強したい部分もあります。
ライブラリに関しては…”使いこなしてる”とまでは…
>>733
ありがとうございます。
>CakePHPで一回チュートリアルとか「10分で作る～」とかを見て、
やっぱりそれが一番かもしれませんね。
>普通にプログラム作ってるだけだったりすると、
なんかコワイですね。
明日本屋行ってきます！
皆さん、いきなりなのに本当にいろいろありがとうございました！
0735nobodyさん
2008/06/25(水) 21:41:34ID:???っていう言葉は、誤解を招く売り文句だと思う。
現実には、フレームワークの内部動作を調べて、
中で何をやってるかだいたい分かるレベルになって初めて
効率よく安全なアプリを自信を持って作れるようになる。
と思うけどな。
0736nobodyさん
2008/06/25(水) 22:45:59ID:???正しい動作がしないとか、問題が出たときに見ればいいんじゃないのかね。
そのためにチュートリアルとか、マニュアルサイトとかあるわけだし。
PHPやるのに、PHPの関数のソースコードまで読まないでしょ？
0737nobodyさん
2008/06/25(水) 23:06:49ID:???それはその通りなんだけどね
世の中には、想像を絶するような要求をしてくる人がいたりして、そういう要求を満たす為には・・・という事なんじゃないかな。
普通は、チュートリアルをこなせば（一応）使えるようなレベルにはなるはず。
とはいえ、そのレベルだと、そのフレームワーク臭さ（？）が抜けないアプリしか出来ないけど。
あぁ。現在のPHPのフレームワークはRAD機能がついているのばっかりだから、そういう奴で標準的なアプリを作って試してみるといいんだな。
で、そのフレームワークらしさが気に入ったら使えばいいと。
0738nobodyさん
2008/06/25(水) 23:22:18ID:???Emacsとかviのような変態エディタみたいなもんか
操作を覚えるまでの過程を考えると必ずしも開発効率が向上するとは限らないみたいな
0739nobodyさん
2008/06/25(水) 23:42:13ID:???ちょっと話題とずれるけど、
http://d.hatena.ne.jp/sotarok/20080422/php_framework_fight
最近、こんなの見つけた。
各フレームワークで同一アプリケーションを作成して、その使いやすさだとか、コーディング量が少ないのがどれか
とかを決めるような大会みたい。
0740nobodyさん
2008/06/26(木) 00:01:32ID:???PHPのソースコード（C++?）は読まないけど、マニュアルは死ぬほど読む
ヴァージョンの差異もでかいしorz
んで、フレームワークでソースコードを読むのは、PHP程ドキュメントが整備されて
いないから、っていうのが一番大きい気がする。「正しい動作」とか「使い方」が、実は
サンプルを含めてソースを読まなきゃわからない、みたいな。
だから「問題が出たとき」だけソースを読めばいいとは思わない。
というか、それで現行のフレームワークが使える気がしない俺がいる
0741nobodyさん
2008/06/26(木) 00:06:30ID:???たまにPHPのソースコード(Cだよ)も読むよ
>>738
そうそう
苦労量保存の法則
でも、覚えてしまえば、品質を保ったままで開発スピード
を上げられるから、やればやるほど楽して儲けられるはず。
0742nobodyさん
2008/06/26(木) 00:40:00ID:???なるほど～。
フレームワークってちょろっと眺めてちょっと使ってみる、ぐらいしかしたこと無いわけだけど、
確かに理解しきるのは困難極めそう。
実際、Webで結構出てるPHPフレームワークって、日本の企業さんとかはつかってるところあるのかな？
0743nobodyさん
2008/06/26(木) 05:27:45ID:???企業が使わずしてどこで使うの
0744nobodyさん
2008/06/26(木) 07:21:25ID:???さすがにCakePHPやちいたんを使うようなイメージは持ちにくい
まあベンチャーというか中小業者なら、担当者の趣味で半年
単位で採用フレームワークが変わってても驚かない
それをもって企業が使っていると言うのは、抵抗があるけど
0745nobodyさん
2008/06/26(木) 07:26:20ID:???0746nobodyさん
2008/06/26(木) 14:03:08ID:???やっぱり世界規模で進んでいるものの方が安心だよね。
0747nobodyさん
2008/06/26(木) 14:07:52ID:???そーでもない。マルチバイトって何？おいしいの？っていう開発者？も
英米圏にはてんこ盛りだということを忘れてはいけない
だからといって国産が使いやすいわけでも無いけど、日本はそれなりに
良い線いってるんじゃ無いかとも思う。
世界規模にならないのは、コミュニティやドキュメントが英語ベースじゃ
ないからだけじゃね？
0748nobodyさん
2008/06/26(木) 14:16:13ID:???0749nobodyさん
2008/06/26(木) 14:18:26ID:???0750nobodyさん
2008/06/26(木) 14:25:59ID:???Validationや文字数カウントが入る部分も微妙
UTF-8に限定すれば問題は少ないだろうけどね・・・。
コメントのコピーライト部分のラテン文字が必ず文字化けして
いるのは多分仕様です。・・・奴らはUTF-8使ってるのか？
0751nobodyさん
2008/06/26(木) 14:41:05ID:???0752nobodyさん
2008/06/26(木) 19:00:58ID:0xtx7Zko必要最小限の機能でやりたい事は全部やれた。
0753nobodyさん
2008/06/26(木) 22:54:59ID:???0754nobodyさん
2008/06/27(金) 00:09:22ID:???自社開発のクローズなフレームワーク使ってるっていう例も多いの？
0755nobodyさん
2008/06/27(金) 00:25:40ID:???もう醜いのはうんざりだ
これからはRubyたんとちゅっちゅするんだ
0756nobodyさん
2008/06/27(金) 01:10:55ID:???ありゃ便利だけど、あくまでbetter perlであって綺麗な世界ではないぜ
まだJavaScriptの方が一貫性と綺麗な世界、シンプルさ保っててる
醜いこと嫌ってweb用となら、pythonも併せて検討した方がいいかもね
Rubyが気になるようなら、もしかしたら君は醜いモノもある程度必要としている方の人かもしれん
もし醜くないことだけが評価されるなら、CのCGIはもっと普及していることだろうw
0757nobodyさん
2008/06/27(金) 02:15:02ID:???PythonのOOは後付で一貫してない部分があるし
OOPと手続き型の混在感がある
JSは悪くはないが、まじめなだけが取り柄でおもしろみに欠ける
0758nobodyさん
2008/06/27(金) 03:07:52ID:???汚く書きたくなきゃ制約の多い言語で十分だ
PHPに不満ある奴は、もっと泥に塗れられる言語を求めてるんだぜ
QIQとか、自由度と混沌を一緒に提案してくれてるんだ
本家にマージされてほしいぜ
あとJSはまじめどころか変態だぜw
0759nobodyさん
2008/06/27(金) 03:35:51ID:???0760nobodyさん
2008/06/27(金) 09:10:17ID:???0761nobodyさん
2008/06/27(金) 09:32:26ID:???0762nobodyさん
2008/06/27(金) 09:37:50ID:???0763nobodyさん
2008/06/28(土) 19:37:31ID:???CGIを高速に運用する環境で決定打を持つものがないな
どれも不安定っぽい
そう考えるとmod_phpの安定感は偉大だった
0764nobodyさん
2008/06/29(日) 02:47:07ID:???>>763の言いたいことはわかるけど、「PHPのフレームワーク」っていう
テーマからは見事にずれてるなｗ
0766nobodyさん
2008/06/29(日) 02:52:54ID:???多分、競合相手は「CGI」ではなく、例えばTomcatベースのJavaプラットフォームだったり
asp含む.NetのWindowsサーバだったり。
あなたの持ち出した基準では、そういうプラットフォームのお話であって。
そういうレベルでは（良くも悪くも）このスレの関心の範囲外だと言ってみる
0767nobodyさん
2008/06/29(日) 19:24:11ID:???0768nobodyさん
2008/06/29(日) 19:31:13ID:k12JEG0L本命なんでしょうかね？
0769nobodyさん
2008/06/29(日) 19:42:33ID:???0770nobodyさん
2008/06/29(日) 19:52:21ID:???0771nobodyさん
2008/06/29(日) 19:57:50ID:???鵞鳥は白鳥にはなられへんねん！
0772nobodyさん
2008/06/29(日) 20:24:04ID:???0773nobodyさん
2008/06/29(日) 20:25:38ID:???0774nobodyさん
2008/06/29(日) 20:32:14ID:???0775nobodyさん
2008/06/29(日) 20:33:32ID:???0777nobodyさん
2008/06/29(日) 22:15:09ID:???と書いてあるだろ。
むしろPHP4に対応しちゃっている部分を問題視しろ。
0778nobodyさん
2008/07/01(火) 12:45:16ID:???0779nobodyさん
2008/07/02(水) 06:01:43ID:???リクエストからレスポンスまでしかオブジェクトが存在しないのに
singletonだろうが何だろうがたいして意味ねーよ
0782nobodyさん
2008/07/03(木) 00:26:16ID:???0783nobodyさん
2008/07/03(木) 01:56:11ID:???0784nobodyさん
2008/07/03(木) 01:59:48ID:???0785nobodyさん
2008/07/03(木) 07:18:34ID:???全然良くねーよ。定数にできるのはスカラーのみ。オブジェクトは不可。
PHPでシングルトンパターンは専らグローバル変数を使わずに
共通のインスタンスを使い回すのに使われる。
Javaでの使われ方とは違うけど、意味がないわけではない。
あとPHPでスレッドプログラミングはできないけど、ZTSを有効にしてビルドされた
PHPはApache2のworker MPMみたいなマルチスレッドサーバ上でスレッドセーフに動作する。
リンクされているライブラリやサードパーティ製拡張モジュールに関しては保証されないけど。
0786nobodyさん
2008/07/03(木) 07:23:17ID:???0787nobodyさん
2008/07/03(木) 07:24:12ID:???> PHPでシングルトンパターンは専らグローバル変数を使わずに
> 共通のインスタンスを使い回すのに使われる。
まあPHP4でのシングルトン実装は、みんな$GLOBALSへの放り込みだったけどなｗ
シングルトンのつもりで設計したのに & を付け忘れてオブジェクトコピーしまくってたり。
過去の話になってくれて、本当にめでたい。
0788nobodyさん
2008/07/03(木) 08:06:55ID:???そういえばPEARで $GLOBALS['_クラス名']['instances'] = array(); とかあったｗ（ていうか今でもある）
今は↓みたいなのが多いね。ものによっては__construct()をprivate/protectedにしてたり。
public static function getInstance() {
static $obj = null;
if ($obj === null) { /* 初期化 */ }
return $obj;
}
0789nobodyさん
2008/07/03(木) 08:31:08ID:???if ($obj === null) { /* 初期化 */ }
return $obj;
}
↑なんだそりゃｗ
0792nobodyさん
2008/07/03(木) 13:01:00ID:???0793nobodyさん
2008/07/03(木) 13:09:24ID:???0794nobodyさん
2008/07/03(木) 13:14:16ID:???んじゃ、むしろ>>788の書き方は（関数宣言を除けば） PHP4、5共用の書き方ってこと？
PHP5なら、クラス変数にした方がわかりやすいじゃん？って思ってしまうが、この書き方の
メリットってある？
0795nobodyさん
2008/07/03(木) 14:11:05ID:???PHP4が苦渋の策だっただけ
0796nobodyさん
2008/07/03(木) 14:29:05ID:???超private変数にはなる、のかなｗ ・・・メリット？
0797nobodyさん
2008/07/03(木) 14:56:36ID:???0798nobodyさん
2008/07/03(木) 14:57:42ID:???singletonという意味ではそうしないと意味がないような
クラスプロパティだと書き換えられる
0799nobodyさん
2008/07/03(木) 14:59:52ID:???5だとstaticを付けなきゃいけないとか、4だと関数名の前に & を付けて、
呼び出し時も & が必要とか、微妙な違いがある。しかも内部的に等価じゃないし。
5だとクラス変数にしたほうがいいね。
0800nobodyさん
2008/07/03(木) 15:05:49ID:???そのクラスの中からしか書き換えられないから何の問題もない
っていうか、普通singletonってそういうもの
0801nobodyさん
2008/07/03(木) 21:05:31ID:???PHPだぞ、これ。Javaじゃない。
ふっつーにグローバル変数で何の問題も起きない。起こしたら本格的に痴呆だ。
0802nobodyさん
2008/07/03(木) 21:17:58ID:???PHPSDLとかイロモノ出て来てるの見ると、色々考えちまうがw
0803nobodyさん
2008/07/03(木) 21:26:56ID:???ライブラリやフレームワークでの記述の統一が無視できないと思う。
あんたの書いたライブラリで$GLOBALS['hogehoge']['pagepage']['instance']とか、
誰が使うかｗ
Hogehoge::getInstance() の方が憶えやすいし、見通しがいいに決まってるじゃないか。
ただの$_SESSIONアクセサ+アルファで、別にそれほど目立った特色のないSession
クラスや同様のCookieクラスが一部で存在する意味もそれだろ。
こういった要素を軽視する人間と一緒に作業できそうな気はあまりしない
0804nobodyさん
2008/07/03(木) 21:46:38ID:???>>801はフレームワーク不要とか言ってる人と同一人物じゃないかな？
趣味プログラマだと思うから、状況が違うんでしょう。
おそらくJavaで仕事したこともないからこその発言に見えるね。
なので議論は（フレームワーク不要論と同様に）平行線になるね。
0805nobodyさん
2008/07/03(木) 21:52:42ID:???0806nobodyさん
2008/07/03(木) 22:03:42ID:???>>803とは違うことだけど、安全性の問題かな
このファイルをincludeすると、$なんとか っていうグローバル変数が
定義されますっていうのはちょっと・・・。
グローバル変数への格納・利用が、同一人物が同時期に書いたソース
のみで起こるんならまだいいんだけどね。
Xoopsも結構良くできてたけど、プラグインを作るときにこの辺が物凄く
引っかかった。クラスベースでも、覚えたりソース読んだりするのは同じ
なんだけど、少なくとも汚染されていない保証っていうのかな、そういう
ものが大事だと俺は感じた。
0807nobodyさん
2008/07/03(木) 22:08:54ID:???どうせシングルトンの対象になるのって、DBコネクションとか限られてるんだから。
0808nobodyさん
2008/07/03(木) 22:37:22ID:???どうせSingletonの意味は薄いんだから、クラスは普通に書いて
Factoryで管理した方がいいかもね
0810nobodyさん
2008/07/03(木) 22:55:35ID:???agaviはContextクラスがAgaviModelの派生クラスのファクトリーになってて、
IAgaviSingleModelインターフェイスを実装している場合はSingletonになるようにしてる。
0811nobodyさん
2008/07/03(木) 22:57:16ID:???想定しているのはこういうのじゃなくて？
＃ これなら継承しても特に問題なさそうなんだけど・・・
class A
{
protected static $obj;
public static function singleton()
{
if(!isset(self::$obj)){
self::$obj = new stdClass();
}
return self::$obj;
}
}
class B extends A{}
var_dump(B::singleton());
0812nobodyさん
2008/07/03(木) 23:14:16ID:???>>811 での Bクラスの singleton() では、例えば Aクラスを継承した
Cクラス・Dクラス・・・でも、「同じ」インスタンスが返ってくるなｗ
class B extends A{}
+ class C extends A{}
var_dump(B::singleton());
+ var_dump(C:::singleton());
んで、ぐーーーーっと戻るが、>>788 での記述でAクラスが書かれて
いたとすると、結果が変わる。
BクラスとCクラスでは、戻ってくるインスタンスが違う。
結局、こういうことなのかな？
詳しい人、解説頼む
0814nobodyさん
2008/07/05(土) 12:22:18ID:???0816nobodyさん
2008/07/05(土) 21:17:29ID:???そんなことより、JavaもPerlもRubyもMVCフレームワークって
ほぼ１択なのにPHPは乱立してんの？
決定版が出てこない時点で終わってるな。
0817nobodyさん
2008/07/05(土) 21:51:53ID:???ある意味、PHPの敷居の低さかな。もともとWEBフレームワークみたいなものだから、
基本機能（CookieだとかHTTP周りとか、出力とかサーバへのデプロイとかもろもろ）を
スキップしていきなり構築出来るし、書いてみれば結構できちゃった、みたいな感じじゃね？
0819nobodyさん
2008/07/07(月) 15:48:06ID:???・DIコンテナとsingletonの関連は？
・DIコンテナを使ったPHPフレームワークってある？その得意とするケースは？
初心者が、ここでこれくらい聞いてもいい？
0820nobodyさん
2008/07/07(月) 16:02:09ID:???0821nobodyさん
2008/07/07(月) 17:53:08ID:???> ほぼ１択なのにPHPは乱立してんの？
PHPがオープンだからじゃないかな？
Javaも最近オープンになってきたから
フレームワーク増えてきているよね。
0823nobodyさん
2008/07/07(月) 21:40:56ID:???Javaを勉強しないといけませんか？＾＾
0825nobodyさん
2008/07/07(月) 23:23:56ID:???いやいやｗ それデザパタとかないしｗ
まずは、DIコンテナが有効なのかどうか、その辺の話が出来ないのか？
ググっても古い情報しかないのは、もう廃れたのか、常識的に使われている
からなのか、どうなんだ
基本的に、手法がXML等の外部設定ファイルだろ？PHPに馴染むとは思えん。
俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
0826nobodyさん
2008/07/08(火) 15:28:51ID:???XMLなどの外部設定ファイルで設定するのって
大変だよ。
0827nobodyさん
2008/07/08(火) 17:39:01ID:???Javaのフレームワークがほぼ一択だと思ってるなら、無知すぎ。
Rubyは開発者が少なすぎの過疎言語だったから。
Perlも廃れた言語だから。
Pythonも多い。
PHPも、乱立っても紹介が多いだけで、実際使われてるフレームワークは
限られてる
0829nobodyさん
2008/07/08(火) 21:14:00ID:???0830nobodyさん
2008/07/08(火) 21:14:32ID:???yamlの奴とかもあるよ
0832nobodyさん
2008/07/08(火) 21:21:43ID:???ともすればRouterやControllerあたりに目を奪われて、ライブラリ
部分の評価がおざなりになってしまったりする。
例えばCIに持ち込むとかすればいいし、双方ともそれが簡単に
出来るように作ってはあるんだけど、その時に何というか気持ち悪い
何故かと考えたが、クラス・変数・関数・ファイル名等の命名規則が、
分散しすぎているせいもあるなあというのが最近の実感。
異質な気持ち悪さがあるのは、きっと命名規則等も分散して
0834nobodyさん
2008/07/08(火) 21:29:32ID:???0835nobodyさん
2008/07/08(火) 21:38:19ID:???多分、それが普及するまでまた３年くらいかかるんじゃね？
名前空間全開で使ってると使用者が増えないという、何という二の舞ｗ
んで、5.2のサポート終了まで引っ張るとか。
0836nobodyさん
2008/07/08(火) 21:46:15ID:???0837nobodyさん
2008/07/08(火) 21:48:24ID:???4はそれこそ、今までの遺産でがんばれば良いじゃない
0838nobodyさん
2008/07/08(火) 22:09:17ID:PfgpRR5RCodeIgniterにZendFrameworkのライブラリを引っ張ってくる＝いいとこ取りで、楽ができますか？
ＭＶＣならルーティングとか、コアになる部分は、どのフレームワーク使ってもに似たような処理になっているでしょうか？＾＾
0839nobodyさん
2008/07/08(火) 22:12:20ID:???自由に組み合わせて食べられるとウマー？
時間があったら、フレームワークのコードを読んでみるか…。
0840nobodyさん
2008/07/08(火) 22:12:52ID:???0841nobodyさん
2008/07/08(火) 22:34:22ID:???別にそんなに難しくないし、メリットはあるとおもう。例えばZend_Pdfとか持って来たり。
lib/Zend 以下をごっそりvendor/とかにコピーしてinclude_pathを通すのが一番楽だけど、
依存に注意しながら必要なものだけを持ってくるのでも、それほど難しくない。
例外が２系統投げられるので、その辺が気になるなら対処して。
CIの場合はそれほどコアに密着したライブラリって無いので、例えばSessionとかDbとか
も、好きなものを使おうと思えば使える。Registryとか、なんでCIにないのかなって思ったし。
＃ そうすると、CIの機能をいくらか無視することにもなるかもだけど、それで幸せになれるならおｋ
で、問題はそれをやると、ソースがカオスになると。メソッドの命名規則なんか、CIはZFの
対局にいると言っても過言ではないとおもうし。
＃ クラスにprefixつけない、CamelCase嫌い、クラスファイル名でもCamelCase式と
＃ lowercase-underscore式の、独自ルールによる混在、もろもろ・・・
そこに上乗せする俺のソースはどっちで書けばすっきりするんだああ、となるよ。
0842nobodyさん
2008/07/09(水) 00:45:59ID:???ここのアホ住人は。
今は、XMLにはほとんど記述せずにアノテーションでお手軽に記述できるんだよ。
0843nobodyさん
2008/07/09(水) 00:54:02ID:???そうやって、どんどんJava風を進めて行くわけですね。＞アノテーション
出来れば、そのメリット・デメリットを絡めたレスが欲しいなぁ。
なんでJavaで一般的なものがPHPで一般的でないか、それを、
「遅れている」等としか捉えられないのなら、少しおかしいと思っていいよｗ
0845nobodyさん
2008/07/09(水) 01:12:38ID:???それを言うなら、XML言い出した大本の>>825では自嘲している
> 俺を含めて、本格的に使ったことの無い奴が多いんだろうとは思うが。
むしろ、DI派の具体的な書き込みが無いから発展しないんだろうが。
0846nobodyさん
2008/07/09(水) 01:20:27ID:???0847nobodyさん
2008/07/09(水) 02:45:49ID:???静的言語の融通の効かなさを誤魔化すために生み出されたものだし。
0848nobodyさん
2008/07/09(水) 10:02:19ID:???0849nobodyさん
2008/07/09(水) 12:00:32ID:QmvziGkHアルゴリズム能力は知識で補えない、もって生まれた能力
0850nobodyさん
2008/07/09(水) 20:19:04ID:My9jWWGdオリジナルの式を組めるなら凄いな
0851nobodyさん
2008/07/09(水) 21:05:11ID:???アルゴリズムってか、ロジックレベルで言ってるんでは無かろうかとも思う
ってか、何これ。コピペ？
0852nobodyさん
2008/07/09(水) 23:28:12ID:???世界ＩＴコンテスト、慶大生が３位入賞
世界の学生がＩＴ（情報技術）の開発力を競う「イマジンカップ」（米マイクロソフト主催）の第6回世界大会が
8日までパリで開かれ、「アルゴリズム部門」で、慶応大の高橋直大さん（20）が3位に入賞した。
日本人の3位以内の入賞は初めて。アルゴリズムはコンピューターソフトの基礎となる計算手法で、
高橋さんのアルゴリズムの独創性などが評価された。
アルゴリズム部門のコンテストは数学パズルのような9問の課題を24時間の制限時間内に
コンピューターを駆使して解法を考案する。高橋さんは「好きな算数や数学の考え方をいかした。
2、3分しか寝なかった」と話した。
パリの大会には100カ国以上から124チームが参加した。予選を含めた総参加人数は20万人を超える。（パリ支局）(11:01)
http://www.nikkei.co.jp/news/shakai/20080709AT1G0900609072008.html
0853nobodyさん
2008/07/10(木) 03:46:42ID:???0854nobodyさん
2008/07/10(木) 03:57:12ID:???「DIコンテナ」のこと？それとも
「自分のプログラム技術が上手なことに気付いた」の方？
はっきりしろやｗ卑怯者がｗｗｗ
0855nobodyさん
2008/07/10(木) 04:07:03ID:???なんで卑怯者？？？
0856nobodyさん
2008/07/10(木) 04:08:03ID:???0857nobodyさん
2008/07/10(木) 10:37:59ID:R+kirKl3ってなると、話がピタッと止まるから面白いｗ
0858nobodyさん
2008/07/10(木) 12:07:19ID:???0859nobodyさん
2008/07/10(木) 12:11:37ID:???各フレームワーク専用スレに移行しております。
0860nobodyさん
2008/07/11(金) 18:54:57ID:???クラス作成の適切な方法を調べています。
分析（モデリング）→設計の流れにおいて、
・構造化プログラミングだとDFD
・オブジェクト指向プログラミングだとUML
ユースケースドリブン＝ユースケース図→ロバストネス分析→クラス図を作成する？
アーキテクチャセントリック＝アーキテクチャ（基盤）としてのフレームワークを選定→フレームワークの流儀に従って機能（クラス等）をどんどん追加していく？
…ということでしょうか？
本やサイトを調べると、Javaの事例がたくさん出てきました。
0861nobodyさん
2008/07/11(金) 19:04:44ID:???0862nobodyさん
2008/07/11(金) 19:28:36ID:???0863nobodyさん
2008/07/11(金) 19:37:29ID:???0864nobodyさん
2008/07/11(金) 19:49:05ID:???＝簡単なアプレットを作れます。
オブジェクト指向分析→設計って、言語の仕様に依存しないで使えますよね？
クラス作成は、適当でも動くものは作れるけど、先人が体得してきた上手いやり方を知りたいです。
デザインパターンは、これから勉強してみます。
0865nobodyさん
2008/07/11(金) 19:53:01ID:???文書を作成する場合も、フローチャート図やDFD図を書けば、人に説明できる。
データベース設計もER図で書ける。
オブジェクト指向設計はこれから勉強しますが、体当たりで試行錯誤するより、典型的な勉強方法を知りたいです。
0866nobodyさん
2008/07/11(金) 23:06:34ID:???0867nobodyさん
2008/07/11(金) 23:37:05ID:3Q95O5fB群雄割拠＞＜
0869nobodyさん
2008/07/12(土) 09:41:14ID:jBMGyyJiが、そもそもCの勉強コスト自体が高いかね。
でも、勉強しておくと、後々効いてくる。
0870nobodyさん
2008/07/12(土) 09:52:14ID:???関連書籍のレベルも低いし
0871nobodyさん
2008/07/12(土) 11:05:18ID:???関数の寄せ集めって考えれば、すごく楽なのに。
0872nobodyさん
2008/07/12(土) 11:12:05ID:???より便利に関数・・・というか、プログラミングを、と考えていくとオブジェクト指向につながっては行くけどな。
0874nobodyさん
2008/07/12(土) 11:38:13ID:???0877nobodyさん
2008/07/12(土) 12:02:11ID:???どうせ「ソースは自分」だろうからほっとけ。
オブジェクト指向はOOPだけ見てると、どうしても小手先的な話が多くなりがちだから
OODも勉強したほうが良いとは思う。ただ、これに関して自分が呼んだ範囲でよかったと
思える本は、Booch先生の「Booch法：オブジェクト指向分析と設計」ぐらい。
しかもこれはもう絶版で再版はされないだろうから、中々に難しい。
0879nobodyさん
2008/07/12(土) 12:33:16ID:???じゃあ、自分の言葉で、「OODも勉強したほうが良い」と思われることを一つでもよろしく
例えば設計手法としてドメインモデルに基づいた「名前」の抽出とか、そう言った具体的な
ものは、"OOではなく"普通に有効なものだと思う。
何がOOのエッセンスか、その辺がよくわからない。
例えば新しい手法が出てきたとして、それがある場面で有効であっても、付帯する、
例えばJavaを前提としたUMLの書式であったりJavaの文脈であったり、そういった
ものはあまり普遍的ではないように感じる。
例： Beanとかなんとか書いてある本を、PHPで実際に参考にするのは非常に難しい。
0880nobodyさん
2008/07/12(土) 12:41:03ID:???> "OOではなく"普通に有効なものだと思う。
色々あるだろうけど、それはその通りだと思うよ。
ただ、例えばモジュール化とかの方法論は、機能単位に分解することを前提にしてたり、
して、モデリングの方法論としては使用されていなかったというだけの話で。
OO言語が流行るまで、個々のエンジニアレベルでOO的な思考がされていなかったのかと
言えば、そんなことはないでしょ。ただ、共通的なモデルとしては語られなかっただけで。
でも、それが出来るようになったのは、それなりに大きい。
後半は何言ってるかわからんから、コメントは控える。
0881nobodyさん
2008/07/12(土) 15:09:10ID:2oBRlMWNhttp://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%87%E3%83%AB%E9%A7%86%E5%8B%95%E5%9E%8B%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3
>フォレスターリサーチは2006年に MDA は死に体（D.O.A.）であるとした
OOA/OOD業界には、SIerが儲けるためのバスワードが混ざっているんでしょうか？
0882nobodyさん
2008/07/12(土) 15:11:44ID:2oBRlMWN○ バズワード
バズワード - 【buzzword】(特にビジネスの世界における)流行語。
バズワード(buzzword)とは一見専門用語のように見えるがそうではない、明確な合意や定義のない用語のことである。
0883nobodyさん
2008/07/12(土) 16:00:51ID:???昔、IBMでさえ、「VBはOO言語だから、VBで作ったシステムはオブジェクト指向技術で作られているんだ」なんて
意味の無いことを主張してたし。
ただ、近いところだと、SOAなんかはバズだなぁって思う。
0884nobodyさん
2008/07/12(土) 17:44:37ID:???具体的に何が気に障ったのか判らんが
0885nobodyさん
2008/07/12(土) 17:54:21ID:bJKqKB86MVCとヴァアリデートだけできればいいし
0886nobodyさん
2008/07/12(土) 19:26:06ID:???逆に、それ以外で要らないものって何だ？
0887nobodyさん
2008/07/12(土) 19:35:29ID:???やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
のことかも
でも、ぶっちゃけヴァリデートはテンプレートライブラリと同程度にフレームワーク
からの独立性や選択肢が欲しいな。
一時期HTML_QuickFormが流行ったのは、独立したヴァリデーションライブラリの
側面もあったからだと俺は思ってる
0889nobodyさん
2008/07/12(土) 21:52:20ID:???> MVCが広すぎて何とも言えないが、独自セッションライブラリとかO/Rマッパとか
> やたらと柔軟なrouterとか、使いやすいConfig、Repositoryクラスとか、そんなもの
> のことかも
俺もそれのことだろうとは思ったのよ。
でも、本当にそんな便利なものをいらないと
言っているのかと疑問になってね。
0890nobodyさん
2008/07/12(土) 22:01:37ID:???0891nobodyさん
2008/07/12(土) 22:05:04ID:yMqg6CvPhttp://bizboard.nikkeibp.co.jp/kijiken/summary/19980817/NC0450H_416091a.html
日経コンピュータ 1998/08/17号
大規模オブジェクト指向開発が破綻 早期稼働を狙いVisual Basicへ変更
九州大学医学部附属病院は98年5月，医師や看護婦のあらゆる業務を支援する「新医療情報システム」を予定より1年以上遅れて全面稼働させた。
当初は97年1月から順次稼働させる予定だったが，システム・インテグレータとして開発を担当した日本アイ・ビー・エムのプロジェクト管理の甘さなどが原因で，開発が大幅に遅れてしまった。
最初smalltalkを使って、頓挫してVisualBasicに変更＝オブジェクト指向プログラミングを捨てて、構造化プログラミングでデスマーチに対処したんですね？
0892nobodyさん
2008/07/12(土) 22:08:56ID:???スルガ銀行は2008年3月6日、日本IBMに111億700万円の損害賠償を求める訴訟を東京地方裁判所に提起したと発表した。
「新経営システム」の開発を委託したが、「IBMの債務不履行により開発を中止せざるを得なくなった」（広報）ことにより被った損害や逸失利益などの賠償を求めたもの。
スルガ銀が導入を目指していたのは、IBMのオープン勘定系パッケージ「NEFSS/Corebank」。
2004年9月にプロジェクトを開始していた。
当初は2008年1月の稼働を目指していたが、開発遅れにより、延期していた。
俺なら111億円も弁償できないよ＞＜
PHPで月100万円儲けられれば十分です(^^)v
0893nobodyさん
2008/07/12(土) 22:10:53ID:???結構古い話なのね
肝心の97年のnikkeiBPの記事がリンク切れなのでぐぐっても良く判らないな。
http://bizboard.nikkeibp.co.jp/kijiken/summary/19980817/NC0450H_416091a.html
有料記事化してたこいつかな（SMLのML漁った方が早いのかな）
ともあれあの当時のVBでOO云々っていう事なら
俺も無理ある話だと同感ましたわ。
2006/7にも受注してんのな
ttp://www-06.ibm.com/jp/press/20060719001.html
こっちの話題はいまんところ見当たんない感じ
0894nobodyさん
2008/07/12(土) 22:11:11ID:???その発想はいいかもね！
PHPのフレームワークが乱立しているけど、いいとこ取りで自分で組み合わせて使うのがスマートだと思う。
＝大きすぎず小さすぎず、必要十分条件を満たすように使い分けられる時代が来るかな？
0896nobodyさん
2008/07/12(土) 22:14:56ID:???それだけじゃなくて、名前は忘れたけど九大病院にシステム好きなセンセイが居て、
システムの要件としてオブジェクト指向技術をつかったシームレスなシステム化っのが
あったらしい。
で、IBMはVBだってOOPLなんだから、これもOOだって言い張ってた。
結局どうなったかは知らんけど。
スレと関係なくなってるから、ここまでにしておくね。
0897nobodyさん
2008/07/12(土) 23:13:48ID:???どうだろうね。
VB6なら、クラスもインターフェースもあるし、
オブジェクト指向として必要最低限の機能はあるんじゃね？
0898nobodyさん
2008/07/13(日) 08:44:03ID:???ttp://d.hatena.ne.jp/sumim/20040525/p1
0899nobodyさん
2008/07/14(月) 14:03:45ID:???0900nobodyさん
2008/07/14(月) 21:48:58ID:???0901nobodyさん
2008/07/14(月) 21:58:48ID:???PHPやPerlが一番いい例じゃないかｗ
そこまで行くと、何を今更と言ってもいいかと
まあ議論の内容は大事だけどね
0902nobodyさん
2008/07/17(木) 01:56:21ID:r8Tb5l590903nobodyさん
2008/07/17(木) 02:06:39ID:???0904nobodyさん
2008/07/17(木) 09:42:03ID:???Open Close Principle に一致する日本語のページ 約 55,700 件
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
Gang of Fourのデザインパターンは，全部で23個ものパターンがあります．
オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
では，なぜ23個もの多くのパターンになってしまったのでしょうか？
このことは，デザインパターンの中に何かかくされた原理というべきものが存在するということを暗示しています．
それが今回紹介するOpen-Closed Principleです．
Bertrand Meyerによれば，Open-Closed Principleとは次のことを意味します．
「モジュールは拡張性について開いて（Open）おり，修正について閉じて（Closed）いなければならない」
このOpen-Closed Principle -- 「結んでひらいての法則」は，オブジェクト指向設計を考える際，その設計が正しいかどうかの指針を与えてくれるもっとも重要な原理です．
>>903
ネタThanksですｗ
参考になりました(^^)v
0905nobodyさん
2008/07/17(木) 13:41:46ID:???0906nobodyさん
2008/07/17(木) 13:47:12ID:???コンピュータ学園HALでも通っとけ
0907nobodyさん
2008/07/17(木) 20:12:06ID:???> オブジェクト指向には，カプセル化，継承，ポリモルフィズムといった数少ない道具しかありません．
> では，なぜ23個もの多くのパターンになってしまったのでしょうか？
数字はたった10個しかないのに、
ものすごくたくさんの数値パターンがあるのと同じ。
文字はたった26文字（アルファベット）しかないのに、
いろんな小説が作られたのと同じ。
人間は少ないもので、数多くのパターンを表現できるように・・・ではなく、
数多くのパターンを、少ない物で表現可能にしてきたのだよ。進化とともにね。
0908nobodyさん
2008/07/17(木) 20:33:28ID:???代表的なものであるのはまちがいないけど。
デザインパターンの重要な点は、有能なプログラマなら意識的
あるいは無意識にやっている、まっとうな設計に名前をつけたこと。
名前が付けられることで方法論が共有でき、会話やグループプログラミングがスムーズになるから。
0909nobodyさん
2008/07/17(木) 23:40:50ID:???0910nobodyさん
2008/07/18(金) 02:20:52ID:VtO/mWcSと思ってたらこれが元ネタ？
http://ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%AA%E3%83%96%E3%83%BB%E3%83%95%E3%82%A9%E3%83%BC_(%E3%83%90%E3%83%B3%E3%83%89)
0911nobodyさん
2008/07/18(金) 02:33:21ID:???0912nobodyさん
2008/07/18(金) 20:21:15ID:???http://q.hatena.ne.jp/1210442237
0913nobodyさん
2008/07/18(金) 20:43:14ID:???0914nobodyさん
2008/07/18(金) 20:47:51ID:???0915nobodyさん
2008/07/18(金) 21:11:58ID:???0916nobodyさん
2008/07/18(金) 22:09:19ID:???0917nobodyさん
2008/07/18(金) 22:37:15ID:???そのアンケート結果不自然すぎでしょｗ
フレームワーク自体の問題じゃなくて
認知度の問題から、その結果はありえないの。
0918nobodyさん
2008/07/18(金) 22:37:45ID:???もっと恐ろしいというか、どう見てもDelphiですな所。
不作為であの結果はありえないっしょ。
0919nobodyさん
2008/07/18(金) 23:40:48ID:w/EYto110920nobodyさん
2008/07/22(火) 03:55:09ID:???ワロタｗ
0921nobodyさん
2008/07/23(水) 17:01:32ID:???GAEにPerlが載ってPHP静かに脂肪ｗｗｗ
0922nobodyさん
2008/07/27(日) 19:58:30ID:???0923nobodyさん
2008/07/30(水) 15:19:27ID:???なんかよさそうなライブラリやツールがあれば教えてください。
0924nobodyさん
2008/07/30(水) 19:35:58ID:???俺も知りたいな。
うちでは、Excelのテーブル定義書とテストデータ（や初期データ）ファイルから、
誰かが書いたVBAマクロでSQLをテキストファイルにしている。
テーブル定義やデータが変更されたら、データベースごとドロップして再度流し込み。
この辺をフォローしているフレームワークやライブラリってあるのかな？
まあ上記のやり方で、わかりやすくてしかもPHP以外でも使えるのであんまり必要は
感じていないのも事実だけどｗ
0926nobodyさん
2008/07/31(木) 12:52:20ID:???カラム名変わってたらちょっと手を入れるけど、
追加とかなら大抵平気だろ。
つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
0927924
2008/07/31(木) 13:24:55ID:???共通で使うデータ（テストデータ・初期データ）はデータファイルとして
これもExcelにしておく。INSERT文には自動変換。
データのファイルを作るのが結構手間だけど、alterなんちゃらでテーブル
定義を変更し続けて、開発者間での整合が取れなくなるのが一番嫌だから、
あくまでドキュメントベースでやってる。
ただのテスト用データなら、>>926が言うようにそれぞれが勝手にダンプ
すればいいし。
0928nobodyさん
2008/07/31(木) 14:10:50ID:???>924じゃないけど、そんなの先にダンプしとけばいいんじゃないの？
>カラム名変わってたらちょっと手を入れるけど、
>追加とかなら大抵平気だろ。
それを、スキーマが変更されるたびに、手作業で、開発者全員がやらないといけないの?
>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
>開発環境なんだし、PHPであるひつようなんてないだろ、どうせ。
別にRailsが好きなんて書いてないんだけど。
Railsのmigrationはよく出来ていると思ったから、PHPではどうしたらいいかを聞いただけ。
なんかRailsに引け目でもあるわけ? >926
0929nobodyさん
2008/07/31(木) 15:16:19ID:???つーか、RailsってORマッパーなしじゃ使えないのかな。ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
0930nobodyさん
2008/07/31(木) 18:57:07ID:???スキーマ変更が多いなら、たしかに自動化できた方が良いねえ。
でもrailsのmigrationも万能じゃないって言うか、
気をつけて書かないと全ての開発者の手元で動くmigrationにならなかったりもするので
あまりコスト的には変わらない気もするが、、、どうなんだろう。
＞なんかRailsに引け目でもあるわけ? >926
なんで引け目？ 別にないけど。
＞ORマッパーって業務でウェブアプリ作るレベルだと意味無いというか、100%害悪だと思うんだけど。
スキーマ煩雑に変わるような状況だと、それなりにORマッパーは便利。
でも仕様が固まったあとSQLに置きかえないとやばい。
あと、railsだってORマッパー無視して最初から普通にSQL書いて投げられるよ。
それともそういう話ではない？
0931nobodyさん
2008/08/01(金) 23:30:29ID:???>なんで引け目？ 別にないけど。
だったら最初から
>>つか、そもそもそんなにrailsが好きならrailsのmigration使って管理しろよ。
とか書くなよ。
単に、PHPではどうしたらいいかを聞いているのに、"そんなにrailsが好きなら" とか "Rails使え" とか、ばかじゃねーの
ほんと役立たずな926
0932926
2008/08/02(土) 01:11:40ID:???0933nobodyさん
2008/08/02(土) 03:08:43ID:???君の存在が、ですね
0934926
2008/08/02(土) 04:20:19ID:???0935nobodyさん
2008/08/02(土) 08:35:17ID:???0936nobodyさん
2008/08/03(日) 00:58:46ID:kbqBMR/thttp://www.asahi-net.or.jp/~ef2o-inue/download/sub09_010_070.html
こんなかんじのVBAマクロ組んでいるんですか？
Excelでテーブル定義表を作って、VBAでテーブル作成のSQL文に変換する方法は、ドキュメント作りの際には便利そうですね。
0937nobodyさん
2008/08/10(日) 23:58:17ID:56GPwW3r・・・あいやしばらく。
「んなモン、『用途と用件による』に決まってんだろjk」
いや、おっしゃるとおりそのとおり。
でも、向き不向きの議論って、このスレの議論でも結構散発的だったでしょ？
○×△の一覧表なんかあると一応の目安にはなるかなと。
cakeもSymfonyも新しいバージョンになってまだ間もないので、そのあたりもコミでエラい人のご意見をいただければってコトで。
0938nobodyさん
2008/08/11(月) 02:41:11ID:???その過多は各人の環境による。
0939nobodyさん
2008/08/11(月) 10:39:03ID:jwJ3rV7rcakeは1.2、Symfonyは1.1だよね？
特にSymfonyはかなり変わったっていうし
0941nobodyさん
2008/08/12(火) 01:24:10ID:???多いことと少ないこと。多いか少ないか。
「金額の―を問わない」
0943nobodyさん
2008/08/12(火) 16:08:20ID:???0945nobodyさん
2008/08/19(火) 18:24:14ID:???それらもサポートしてるフレームワークってあるー？
0946nobodyさん
2008/08/19(火) 18:48:16ID:/CvuB95r0949nobodyさん
2008/08/20(水) 04:18:01ID:???0950nobodyさん
2008/08/20(水) 05:43:40ID:???0951nobodyさん
2008/08/20(水) 12:54:40ID:???0952nobodyさん
2008/08/20(水) 18:09:39ID:0kYAgOqk途中で消えたりしない？
0953nobodyさん
2008/08/20(水) 19:19:17ID:???0954nobodyさん
2008/08/20(水) 19:33:44ID:???zfは亡き者に・・・
0955nobodyさん
2008/08/20(水) 20:28:11ID:???0956nobodyさん
2008/08/20(水) 20:38:08ID:???オープンソースなPHPやZFの方が寿命長そう。
0958nobodyさん
2008/08/21(木) 00:05:04ID:???少なくとも大幅な仕様変更があるだろうな。
0959nobodyさん
2008/08/21(木) 01:02:09ID:???0961nobodyさん
2008/08/21(木) 06:00:17ID:???ってことでだろ
他のは仕方ないとしても
0962nobodyさん
2008/08/21(木) 13:41:00ID:???他はPEARコーディング規約に則したクラス命名してるの少ないからな。
さすがにZendFrameworkは公式なだけあって名前空間使ってくるだろ。
今までも大胆な仕様変更をガンガンしてきた例から見ても間違いなく…
0963nobodyさん
2008/08/21(木) 17:38:55ID:???お約束です
0964nobodyさん
2008/08/21(木) 19:01:35ID:???0965nobodyさん
2008/08/21(木) 20:12:45ID:???0966nobodyさん
2008/08/23(土) 13:37:02ID:g0UpHeXO0967nobodyさん
2008/08/23(土) 20:50:54ID:R46pd30T0968nobodyさん
2008/08/23(土) 20:54:21ID:???rails like
bake の愉快さ（not 実用性）
宣伝（というかユーザのブログ）
その他
じゃね？
決してドキュメントが親切とかそう言うことは無いんだけどね
0969nobodyさん
2008/08/23(土) 22:11:24ID:???0970nobodyさん
2008/08/23(土) 23:48:25ID:???0971nobodyさん
2008/08/24(日) 00:01:42ID:???構築した後どうするの？
結局RDBMSを知ってるか、それを使うアプリ(PHPでのシステムを含む)を
いじれるか、何か出来ないとどうにもならないんじゃない？
こういうデータがあります、これをデータベースｗで管理したいです、っていう
要件には必ずそれなりの知識が必要になります。構築すればいいってもん
じゃない
Ruby on Rails は極力データベースを隠したけど、それでもRailsの約束ごとも
SQLもわからないんじゃどうしようもない、そう言う感じでよろしくと切に願います
0972nobodyさん
2008/08/24(日) 00:04:05ID:???ちゃんとしたコーディング規約に添って書かれていて、機能も豊富で、
なにげにドキュメントもちゃんとしてたりするけど、
そもそもの目的が「フレームワークを作る」ことにあって実際の現場で
叩き上げられてできたものじゃないのが大きい気がする。
Webアプリケーションフレームワークとして使いたいとは思わないけど、
ライブラリとしてつまみ食いするにはとても良い。
0973nobodyさん
2008/08/24(日) 00:04:43ID:???MS-Access とか、それも難しければ MS-Excelでいいんじゃない？
立派なデータベースだよ。いやマジで
0974nobodyさん
2008/08/24(日) 00:16:08ID:???0975nobodyさん
2008/08/24(日) 00:24:05ID:???Cakeやsymfonyが「現場で叩き上げられてできたもの」かどうかはさておいて、ね
どのフレームワークもはじめは頭でっかちだと思うよ
Zendの場合はその頭は筋がよい頭だと普通に思う
筋がよいといっておかしければ、PHPのアップグレードの方向性に沿っているというか
多分、言いたいことはそれが使う上で使いやすくこなれているかどうかってことだと
思うんだけど、なんでZendはそうならなかったのかっていうのは興味がある
無粋すぎたのかな？
0976nobodyさん
2008/08/24(日) 00:37:38ID:???吐き出すHTMLが綺麗なこと
0977nobodyさん
2008/08/24(日) 00:43:52ID:???というかそれでいいからぜひ開発、進歩を続けてほしいと今でも
思うんだが
サンプルコードとして、一つの指針としての価値は思いっきりあると
思うんだが、「できる」人たちには必要のないものなのかな？
0978nobodyさん
2008/08/24(日) 00:51:28ID:???PEARさえいつまでたってもPHP4な状況に業を煮やして作られたような。
だからPHP5.3がリリースされたら名前空間や遅延的束縛、無名関数を使った
ZF2.0にシフトするんじゃないかと予想している。
閑話休題。
PHP6で搭載予定だった機能のうちUnicodeを除いたほとんどが5.3にも搭載されているのは
嬉しいことだけど、そうなると6がいらない子になってしまいそうで...
0979nobodyさん
2008/08/24(日) 01:03:11ID:???ああ、なんとなくわかる
結局みんな5.3で、6.xが普及するまでまた３年ほどかかるんじゃ
ないかっていうｗ
もうPHPの宿病だとは思うが
いまだに4.xで動かさなきゃいけないとかいう現実をみると
0980nobodyさん
2008/08/24(日) 02:29:26ID:???3年で済むかな・・
0981nobodyさん
2008/08/24(日) 04:06:32ID:???0982nobodyさん
2008/08/24(日) 05:23:46ID:???0983nobodyさん
2008/08/24(日) 05:37:46ID:???クロージャの構文はもっと頭をひねってほしかったと言わざるを得ない。
0984nobodyさん
2008/08/24(日) 12:39:05ID:???あまり使い道はない。
0986nobodyさん
2008/08/24(日) 18:54:49ID:???0987nobodyさん
2008/08/24(日) 19:01:37ID:???？？
array(1, 2, 3) が [1, 2, 3] って書けるように、ってこと？
ただ見た目が変わるだけに思うが、どういうときに嬉しいんだろう
0988nobodyさん
2008/08/24(日) 19:18:49ID:???0990nobodyさん
2008/08/24(日) 19:56:44ID:???欲しいとかいう感じのものよりは価値が低そうだ
無いものねだりとか隣の芝生とかいったりするかも
0991nobodyさん
2008/08/24(日) 20:55:55ID:???それでもエディタが教えてくれるなら別にいいと思うが。普通はインデントとかして
分かりやすくするよな。じゃarray()なら分かりやすいかっていうと、逆にウザいだけだ。
[ 'validators' : [ 'inArray', 'mailaddress'] ]とかすっきりしていいよ。
functionて書くのすらウザいもの。
0992nobodyさん
2008/08/24(日) 21:00:18ID:???0993nobodyさん
2008/08/24(日) 21:12:32ID:???そういう設定系なら、むしろもうテキストで読み込んでパースしたら？
それなら言語関係なく使えるじゃん
その為のJSON、YAML等なんだから
で、そういった「設定」以外でネストしたarray記述を書く部分って、
思ったより少ないよ
0994nobodyさん
2008/08/24(日) 21:33:19ID:???その時点でおかしいってことに気付けよ。
しかし、実装が難しいっていうなら仕方ないけど、もう出来てるんだろ。
何でリリースに取り込まないわけ？
0995nobodyさん
2008/08/24(日) 21:39:34ID:???結構前からずーっと要望している人もいるみたいだけど、うざがら
れている可能性もある。
ある意味Ruby信者みたいな感じに、とかｗ
0996nobodyさん
2008/08/24(日) 21:45:55ID:???【PHP】フレームワークについて語るスレ10【総合】 ← ※本当は11
http://pc11.2ch.net/test/read.cgi/php/1219581817/
0997nobodyさん
2008/08/24(日) 21:52:54ID:???・・・と、妄想してみる。PHP/FIを使ったこともソース読んだこともないけどｗ
0999nobodyさん
2008/08/25(月) 12:24:43ID:???もし短い書き方が導入されたらそっち使うでしょ？
1000nobodyさん
2008/08/25(月) 12:36:04ID:???1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。