08/04/10 11:14:42
>>329
> フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？
有名どころは全部対応しているが？
mod_rewriteだって、index.phpを隠すためだけに使用されているわけで、
デフォルト設定のまま使える。
mod_rewriteでコントローラ/アクションに振り分けているんじゃないんだよ？
332:nobodyさん
08/04/12 13:05:07
URLﾘﾝｸ(www.modrails.com)
mod_rails登場でmod_php雪崩式に脂肪ｗｗｗ
333:nobodyさん
08/04/12 15:40:54
やっと、mod_phpに追いついただけじゃん
しかもプリインストールされるまではきてないし、
何年遅れだよｗｗ
334:nobodyさん
08/04/12 16:17:48
は？
フレームワークレベルでmodになってるんだからとっくにphpをぶち抜いてるよ
mod_symfonyとかmod_zend_frameworkみたいなもの
ﾌﾟｰﾌﾟﾌﾟﾌﾟ
335:nobodyさん
08/04/12 17:23:23
rubyに手を出すとスレタイすら読めない無能になるのか
336:nobodyさん
08/04/17 16:32:23
MySQLがオープンソースじゃなくなってPHPまた一歩脂肪ｗｗｗ
337:nobodyさん
08/04/17 17:02:10
その理由なら、rubyも死亡だろｗ
338:nobodyさん
08/04/18 06:17:36
まじでMySQL終わりっぽいじゃん
新規開発はpostgresにした方がいいんかな
339:nobodyさん
08/04/18 07:41:13
クローズドになったらMySQLなんて誰も使わないよな
ポスグレも充分に速くなってるから代替効くし
Sunの戦略がわからんわ
340:nobodyさん
08/04/18 09:42:52
クローズドになるとかいってんのお前だけだよｗ
341:nobodyさん
08/04/18 14:07:52
ソースはこれ？↓
MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に
URLﾘﾝｸ(www.technobahn.com)
342:nobodyさん
08/04/18 14:18:22
別にフリーだから使うなんて事はないんだぞ？
趣味ならそれは重要だが。企業レベルじゃあまり関係ない。
SQLServerやらMySQLの有料版が実際使われているのがいい証拠。
企業の場合どっちかというとサポート体制が重要。
金払ってるといざって時サポート呼べるし、場合によっては責任もとらせられる。
無料版だとサポート呼べないし責任は全部自分ところ。
なんでもオープンソース使え使えっていってるのは2流の技術者と、そういうのに疎い有料無料かでしかみれない上役だけ。
現場でわかってるプロの技術者なら有料か無料かなんて選択肢の中ではかなり優先度は低い。
少なくとも、これオープンソースだから使いましょうよ、なんていってる技術者いたらその時点で役立たずのレッテル貼るわ。
その構築するシステムに向いてるかどうかで判断するのならまだしも。
343:nobodyさん
08/04/18 14:52:31
>>342
プロの技術者乙
344:nobodyさん
08/04/18 15:42:02
新機能が追加されないMySQLを使い続けてPHPERジリ貧ｗｗｗ
345:nobodyさん
08/04/18 18:10:17
その理由なら、rubyも死亡だろｗ
346:nobodyさん
08/04/18 18:23:32
RoRはMySQLをポイ捨てしてsqliteに乗り換え済み
先見の明の違いが出たねｗ
347:nobodyさん
08/04/18 18:54:43
ひどいつりだな
348:nobodyさん
08/04/18 19:35:54
sqliteはパブリックドメイン（何しても自由）だから
フレームワークに内蔵してデフォルトにしているだけで
別に良いものだから選んでいるわけじゃないんだけどな。
あくまで開発・プロトタイプ・個人用のもので
複数の人が同時にアクセスするものとしての
本番利用は現実的じゃない。
それにPHPは、sqliteをとっくの昔に言語の標準
データベースとして組み込んでいる。お前に言わせれば先見の明だなｗ
349:nobodyさん
08/04/18 19:41:04
末端の利用者が評論家気取りでグダグダ言ってるなよ。
みっともないｗ
350:nobodyさん
08/04/18 19:55:20
はぁ？ 普通利用しているからことちゃんとした意見言えるわけで。
使ってもいないくせに何か言おうとしているなこいつｗ
351:nobodyさん
08/04/18 20:26:25
>>350
つれたつれた
352:nobodyさん
08/04/18 20:38:46
>>342
一般企業で有償MySQLってなかなかないんじゃないかな？
OracleかSQL Serverでしょう、有償なら。
現場で解ってるプロの技術者には選択肢ないんじゃないかと思う。
俺の周りだけの話だけかもしれないけど。
353:nobodyさん
08/04/18 20:56:40
裾野が狭まるから頂も低くなるんだよ
オープンソースからプロプライエタリに移行して成功した製品あんのかと
354:nobodyさん
08/04/19 01:02:42
> オープンソースからプロプライエタリに移行して成功した製品あんのかと
どうやら、あなたはオープンソースからプロプライエタリに移行したら
失敗するといいたいようですが、そもそも
オープンソースからプロプライエタリになった製品があるのですか？
あと、MySQLはsunが買収したとしても、オープンソースのままなのは
知っていますか？
355:nobodyさん
08/04/19 03:29:45
>>354
オープンソースからプロプライエタリに移行した製品がないという
悪魔の証明に自ら挑むとはｗ
製品を殺す愚策なんだから知られないのは当然
まぁ俺も知らないけどね
本当に無償版の開発を停止して有償版しか出さなくなったら
MySQLは死んでいくと思うよ
356:nobodyさん
08/04/19 07:12:17
>>341を読む限り、「新機能」がCommunityServer版に付かなくなる、とも読めるな
もしメンテ（および機能改良）が続くんなら別にいいかなと、無理矢理楽観してみる
357:nobodyさん
08/04/19 08:21:08
ウェブシステムの性格的に、信頼性が低くても安い方がいいってことでApacheとかMySQLとかPHPとかが流行ってるわけだからな。
金かかるんだったら、ポスグレにして、その分自分の収入にする罠。
358:nobodyさん
08/04/19 09:19:18 Pd4VwcNb
くだらん書き込みが続いてるなぁ。
ApacheもMySQLも信頼性が低いってー事はないぞ。PHPについてはシランが。
あと、普通にPHPでwebプログラムを組める奴は必然的にPHPとJavascriptという風に複数言語使えるようになってるからそこから更にrubyとかいうことになってもそんなにコストかかるわけじゃないと思う。
俺もrubyについては手をつけてないが、Cやらpythonやらに手をつけてるし。
PHP脂肪とか言われたら他の言語使えばいいだけだって気づかないんかね。
# あと、ここはフレームワークのスレかと
359:nobodyさん
08/04/19 09:21:27
>>355
あんた、悪魔の証明が何かわかってないんじゃね？
360:nobodyさん
08/04/19 13:03:25
>>354
RHELとか？
成功というのが何を指してるかわからないけど。
361:nobodyさん
08/04/19 18:10:16
URLﾘﾝｸ(d.hatena.ne.jp)
Community Server開発継続でPHP余命一年延びるｗｗｗ
362:nobodyさん
08/04/20 01:52:32
src php 捨てたい
けどまだ時期尚早だよな
363:nobodyさん
08/04/22 22:01:35
URLﾘﾝｸ(blog.ohgaki.net)
Ruby1.9以下のWEBrickにディレクトリ遷移攻撃脆弱性があってPHP脂肪ｗｗｗ
364:nobodyさん
08/04/22 23:27:24
URLﾘﾝｸ(d.hatena.ne.jp)
誰かこれ参加しろよ
365:nobodyさん
08/04/23 03:25:02
Delphi for PHPってどうなんだろう
「データベースに特別なコードを書かずとも容易に接続できるようにした」
とかいう説明読むとフレームワークと認識してもいいように思うけど
366:nobodyさん
08/04/23 10:30:22
>>365
フレームワークの定義って、データベースアクセスが簡単かどうかってよりも
アクションのディスパッチャがあるかどうかだと思う。
367:nobodyさん
08/04/23 21:37:32
そりゃMVC一通りあるんじゃないの？使ったことないから分からないけど
368:nobodyさん
08/04/24 20:18:05
URLﾘﾝｸ(blog.ohgaki.net)
Pythonのセキュリティー警告してたらSPAMにメールアドレス使われたみたいだ
Python厨タチわりー
369:nobodyさん
08/04/24 20:21:21
Python厨だけにGoogle App Engine使って配信したのかもな
370:nobodyさん
08/04/25 06:21:16
そんな攻撃的な信者はphperにもrubyistにもいないよな
phythonerﾔﾊﾞｽ
しかも単なるセキュリティー情報で誹謗中傷ですらねーし
371:nobodyさん
08/04/28 10:48:30
フォームヘルパーって使ってます？
せっかくMVCなのにテンプレートに関数入れるなんて、とっても矛盾してると
思うのですが・・・
そういう需要もあるってだけなんですかね
372:nobodyさん
08/04/28 11:49:40
Viewのロジックじゃん
MVC=Viewの動的要素を一切省こうってわけじゃないよ
373:nobodyさん
08/04/29 00:07:53
確かにプルダウンとかラジオボタンのHTMLをコントローラ（やモデル？）でつくって
準備するのはなんだかなーだ
分担としては間違いなくViewの仕事だろう。ヘルパーって言うのが微妙なんだけどな
374:nobodyさん
08/04/29 01:49:36
だからViewHelperはViewの範疇なんだっての
高校生か？
375:nobodyさん
08/04/29 09:35:20
URLﾘﾝｸ(www.sabel.jp)
またフレームワークが増えましたよ、と。
376:nobodyさん
08/04/30 02:52:49
DIにアスペクト志向にアノテーション……採用前評価がめんどくさそうなw
採用検討／評価するにしてもうちはGW終わってからだなー。
おまえら頑張れ
377:nobodyさん
08/04/30 04:53:29
symfonyってcodeigniterの何倍くらい重い？
378:nobodyさん
08/04/30 15:03:38
rubyてmysql使うのにもmakeとかしなきゃいけないのか・・俺脂肪
379:nobodyさん
08/04/30 16:29:31
ふつー gem install mysql
380:nobodyさん
08/05/01 17:01:00 1aec6u7x
ethnaがシンプルでよかったので
社内システムの標準FWに採用しました。
381:nobodyさん
08/05/01 20:29:40
ethnaってまだ開発続いているの？
382:nobodyさん
08/05/02 00:35:33 ulIGiMsU
地味に続いてるよ。
383:nobodyさん
08/05/02 14:05:51 ulIGiMsU
新しいバージョンでるみたいだね。
384:nobodyさん
08/05/02 14:35:04
symfonyはcodeigniterの3倍遅いみたいね
同じパフォーマンスをあげようと思ったら3倍のリソースが必要か…
385:nobodyさん
08/05/02 14:58:16
単純に機能とスピードのトレードオフだろう。
386:nobodyさん
08/05/02 16:54:39
URLﾘﾝｸ(jp.techcrunch.com)
twitterがRoRを放棄でPHP復活ｗｗｗ
387:nobodyさん
08/05/02 16:57:33
RoRがスケーリングに対応できないというが
それならRoRをパクっただけのPHPのFWが対応できるのか？
388:nobodyさん
08/05/02 17:16:29
全部erlangで書きゃいいのに
389:nobodyさん
08/05/02 17:16:36 mpl3PtrU
phpは素で書けば速いもんな。
390:nobodyさん
08/05/02 18:38:44 ulIGiMsU
エスナも早いよ
391:nobodyさん
08/05/02 20:08:53
ciはソースに今どき閉じタグが書かれているのがイモ
392:nobodyさん
08/05/02 20:50:58
閉じたり閉じなかったりで動きが変わる事自体がイモじゃね
仕方ないんだろうけどさ
393:nobodyさん
08/05/02 21:29:55
>>391は所得も知能も底辺に位置する者の喚き声だなｗ
394:nobodyさん
08/05/02 21:37:21
なんで？
395:nobodyさん
08/05/02 21:38:49
>>393の頭には虫がわいてんだろうなww
396:nobodyさん
08/05/02 22:22:41
ソースに今どき開きタグが書かれているのがイモ
397:nobodyさん
08/05/02 23:34:45
>>396
それは激しく思う。というか閉じタグをとっぱずすなんてどう考えてもバッドノウハウじゃねえかｗ
少しは疑問に感じろよPHPerども
398:nobodyさん
08/05/03 03:55:15
閉じタグを書かない俺ってＧＥＥＫ！
399:nobodyさん
08/05/03 03:59:36
ciはsystemディレクトリの中にapplicationディレクトリが入ってるのがイモ
そこは分けとけよ
400:nobodyさん
08/05/03 04:42:11
>>398はもっと評価されるべき
401:nobodyさん
08/05/03 06:16:41
しばらくsymfony使ってて
久しぶりにci触ったら身軽でいいわ～
402:nobodyさん
08/05/04 23:06:36 QrBYi/l0
結局 中小規模だとどれがおすすめ？？
CakePHP
-> DBと密接すぎる
CodeIgniter
-> セッションがクッキーに保存される
とどっちも肝心なとこがいまいちだった…
403:nobodyさん
08/05/04 23:10:28
>>402
ちゃんと使えば？CIのセッションについては、DBに保存することもできたと思うけど。
っていう自分はドキュメントよんで評価して改良してっていう手間がもうしんどくて、
guesswork classic をカスタマイズしたものを延々つかってるけど
404:nobodyさん
08/05/04 23:13:41
>>403
うん DB使うときはそれでいいんだけど
使わないときがね…
小規模だと CakeかCIがよさげなんだけどね
その改造する手間がね… orz
guessworkもためしてみるかな
405:nobodyさん
08/05/05 00:52:06
CakePHP ってそんなにDBと密接だろうか？
usesプロパティにnull代入すれば
それで終わりじゃね？
406:nobodyさん
08/05/05 01:19:43
>>405
それで一応できるけど
modelは必須なのが前提だし…
DB使うにしても密接すぎて融通きかない感じかな
はまれば楽なんだけどね
407:nobodyさん
08/05/05 03:33:55
普通に作ればモデルを作るのが当たり前なんだが・・・。
まあ経験をつめ。
408:nobodyさん
08/05/05 09:50:45
変態セッションがいやなら$_SESSION使えばいいじゃない
409:nobodyさん
08/05/05 12:22:34
>>407
DBやファイル扱わない場合だってあるじゃん・・
410:nobodyさん
08/05/05 12:31:02
たとえば？
411:nobodyさん
08/05/05 13:45:56
それはどのFWを使うかというより、
FWを使うべきかどうかを検討する規模の開発だと思う。
生PHP+何かしら必要なライブラリで事足りそう。
412:nobodyさん
08/05/05 15:29:14
>>407
自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？
オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。
413:nobodyさん
08/05/05 17:17:56
内部の処理をモデルの中に隠せばいいのでは？
414:nobodyさん
08/05/05 19:08:40
だって、最適なSQLって画面とか機能ごとに違うことが多いじゃん。
画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。
っていうか、モデルとしてのメリットがほとんどない。
415:nobodyさん
08/05/05 19:21:04
MVCを勉強しなおしてね。
416:nobodyさん
08/05/06 01:40:18 Db+mgkTm
CIのルータが変態なので自前ルータを書いてるんだが
hoge/moge/
と
hoge/moge
を同一と判定すべき？しないべき？
417:nobodyさん
08/05/06 01:45:13 iGu8GQhf
すべき
418:nobodyさん
08/05/06 01:54:34
だよな
ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな
419:nobodyさん
08/05/06 03:21:15
どちらでも同じコンテンツにアクセスできることが望ましいと思うが、
どちらかに転送した方が良いと思われ
420:nobodyさん
08/05/06 16:53:07
質問スレで知ったんだがRhacoってどうなの？
和製フレームワークっぽいけど
このスレで出たことないよね？
421:nobodyさん
08/05/06 16:54:23
どうも和製はなぁ。
結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。
422:nobodyさん
08/05/06 16:56:00
Rhacoのオフィシャルサイトがなんか重いなァ
パフォーマンスでないのかな？
423:nobodyさん
08/05/06 16:59:32
結構作り込んである印象
なんでまったく話題に出なかったんだろ？
424:nobodyさん
08/05/06 17:36:05
>>416
それって他のFWもそうじゃない
その辺があまいのばっかだよなあ
425:nobodyさん
08/05/06 17:47:31
CIがあまいだけでは？
426:nobodyさん
08/05/06 17:48:55
>>418
おいおい。index.htmlを忘れているぞ。
hoge/moge/ だとmogeフォルダのindex.html（設定による）を参照すべきだろう？
427:nobodyさん
08/05/06 17:55:43
>>426
>>417-418は、まさにそう言ってるんだと思うが？
428:nobodyさん
08/05/06 18:14:00
いや、少し考えてみた。
URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か
で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな
429:nobodyさん
08/05/06 18:15:28
/hoge/mogeでも/hoge/moge/でもどっちでも
mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな
430:nobodyさん
08/05/06 18:16:27
なんかかぶったｗ
431:nobodyさん
08/05/06 18:20:13
>>430
結論は反対だけどねｗ
432:nobodyさん
08/05/06 18:22:19
ん？同じだろ？
433:nobodyさん
08/05/06 18:24:06
426…最後の/で判断するよ派
428・429…最後の/で判断しないよ派
これであってる？
434:nobodyさん
08/05/06 18:30:18
ってか
フレームワークのルータに/hoge/moge/index.htmlが渡ることって考えにくいな
素のリソースはmod_rewriteの設定で直接アクセスされるだろ
435:nobodyさん
08/05/07 00:29:19
/foo/barへのアクセスは
1./foo/barがファイルであるか確認
2./foo/bar/へリダイレクト（301 Moved Permanently）
が正しい動作のはず。
436:nobodyさん
08/05/07 01:08:20
何を基準にした「正しい」動作なの?
437:nobodyさん
08/05/07 01:32:49
俺もｵﾓﾀ。いったい何を基準に正しい・正しくないを議論しているのか…
独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?
438:nobodyさん
08/05/07 02:53:40
パスが変わるのでしないべき
妥協点はスラ付きへリダイレクト
が正解
439:nobodyさん
08/05/07 03:22:12
>>438に賛同。
SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 → URLﾘﾝｸ(pmakino.jp)
440:nobodyさん
08/05/07 06:16:35
なるほど
たしかにSEO的にリダイレクトする方がいいな
㌧㌧
441:nobodyさん
08/05/07 06:36:20
>>414
乗り遅れたけど、いい事言ってるなあ。
>>407とか>>415は流行に流されて本質を見失ってるな。
俺はテーブルと一対一になるモデル「じゃない」モデルクラスを作って対処してる。
442:nobodyさん
08/05/07 06:50:57
>>441
日本語が読みきれん。どっち？
テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる
前者だろうとは思うけど、一応。
443:nobodyさん
08/05/07 09:21:36
はぁ。テーブルと一対一にならなくても
モデルはモデルだろ。
444:nobodyさん
08/05/07 09:47:29
むしろ、テーブルと1:1になることを前提にするのは、内部構造に対する抽象化が制約されるという意味で、
モデリングとして不適切だと思ってる。
だから自分的には >>443 は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。
445:nobodyさん
08/05/07 09:56:24
クラスで使う例外って
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ
446:nobodyさん
08/05/07 12:42:06
特定のフレームワーク上でのお作法の話ならずれてるかも知れんが、
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
447:nobodyさん
08/05/07 14:16:49
俺はタイプヒンティング使ってcatchするのに結構使うな
448:nobodyさん
08/05/07 20:53:16
>>446
せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？
449:nobodyさん
08/05/07 21:11:53
>>448
例外の中でエラーコードを使うこと言うこと。
クラスの型で判別してないだけで、例外は使ってる。
450:nobodyさん
08/05/07 21:14:56
>>449 タイプミス訂正
例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。
451:nobodyさん
08/05/07 21:59:18
>>445
class なんとか_かんとか_Exception extends なんとか_Exception
{}
だけみたいなファイルが増えてくのはやっぱバカバカしいな
452:nobodyさん
08/05/07 23:57:23
というかPHPのtry catchはゴミすぎて使う気になれませんよｗ
453:nobodyさん
08/05/08 00:14:58
結局catch ～～ で分岐するか、instanseof で分岐するか、
$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
454:nobodyさん
08/05/08 00:29:40
MVC要らんな。
長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
455:nobodyさん
08/05/08 00:42:41
>>454
プログラマとしては気に入らないけど、現場レベルだとコピペ嵐の方が修正時の影響範囲が
限定的だから現実的だというのは、認めないわけでもない。
カラシニコフ的アーキテクチャとでも言うべきか。
456:nobodyさん
08/05/08 00:55:28
>>454
修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
457:nobodyさん
08/05/08 02:02:54
PHPの場合、try catchの例外処理機構が駄目なんじゃ無くって、組み込み関数がエラーで例外吐かないのが糞。
458:nobodyさん
08/05/08 04:09:14
>>454
なるほど
ベタ書き→PHP
MVC→他の言語
と使い分けてもいいかもね
PHP以外なら何がいいだろ？
459:nobodyさん
08/05/08 05:17:56
俺もPHP使ってるけど確かにそういうことを考えたりする。
>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
460:nobodyさん
08/05/08 06:45:47
テストのしやすさとか
開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
461:nobodyさん
08/05/08 08:00:22
実利を求めたらオブジェクト指向に落ち着くだろ
462:nobodyさん
08/05/08 08:20:17
どうだろうね。プログラマは確保できるけど能力的には怪しいっていう環境なんかだと、
エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
463:nobodyさん
08/05/08 08:43:03
PHPの特徴はPHPとHTMLが混在できるということだよな。
この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
464:nobodyさん
08/05/08 09:39:12
> 別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
465:nobodyさん
08/05/08 09:40:21
Rubyは言語自体入ってなかったりバージョンが古いし、
466:463
08/05/08 10:10:38
>>464
そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
467:nobodyさん
08/05/08 11:24:56
ベタ書き＝PHP＋XREA
MVC＝Python＋Google App Engine
がいいかな？
468:nobodyさん
08/05/08 11:33:59
悪くないんじゃね。適材適所？
GoogleAppEngineは本サービスの内容次第だけど
469:nobodyさん
08/05/08 12:49:25
FWと独立したORMがもっとでてこねーかな
好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
470:nobodyさん
08/05/08 12:54:43
直SQLで十分。
471:nobodyさん
08/05/08 13:01:46
ﾃｨﾝﾎﾟﾆｰの新しいヘルパって
クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
472:nobodyさん
08/05/08 13:20:40
>>466
本末転倒になってね？
PHPの（いけてない）特徴を消すのが何が悪いの？
473:nobodyさん
08/05/08 14:41:46
いけてないPHP？
綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
474:nobodyさん
08/05/08 14:52:22
開発言語なんて自由に選べるものでもないし、
サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
475:nobodyさん
08/05/08 15:13:05
>>473
まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
476:nobodyさん
08/05/08 21:45:25
>>475
で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
477:nobodyさん
08/05/08 22:39:24
まあ極端にならんと。
どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
478:nobodyさん
08/05/09 00:59:50
自分が楽な作り方を選べばいいじゃん。
一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
479:nobodyさん
08/05/09 02:21:08
プログラムとは一言でいえば「データ＋処理」
それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
480:nobodyさん
08/05/09 03:21:13
インプットチェックで異常があったらフォームを再表示みたく、処理結果によって表示するページが
異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
481:nobodyさん
08/05/09 13:09:55
フレームワーク使うべきかどうかってそういう次元の話じゃなくて、
単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
482:nobodyさん
08/05/09 21:42:19
>>475
>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
483:nobodyさん
08/05/09 22:56:26
「話はそれからだ」ってのは「理由は聞かないで下さいっ >_<」って意味なんだから、そっとしといてやれよ。
484:nobodyさん
08/05/09 23:11:23 a3XtheQg
>>482
>>475じゃないけどsymfony+smarty使ったことあるかい？
しかしMVCは良いとしてもO/Rマッパはなんとかならんもんかね
485:nobodyさん
08/05/10 01:24:53
>>484
あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
486:484
08/05/10 03:06:24
>>485
>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
487:nobodyさん
08/05/10 10:23:21
小さいのを作るにはフレームワークを使わなくても出来るけど、
大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
488:nobodyさん
08/05/10 10:26:41
>>485
> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
489:nobodyさん
08/05/10 11:47:06
JavaのApache Wicketというフレームワークは
テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
490:nobodyさん
08/05/10 12:08:18
即席で作るだけなら生書きの方が速いことも多いが
保守を考えるとフレームワーク使わないときついだろ
491:nobodyさん
08/05/10 22:09:04
>>485
> ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしい理由は？
DAOとしての面ではあるテーブルに対する操作が一つのクラスに集約されるから見通しが良くなるが。
492:nobodyさん
08/05/10 22:28:21
SQLって単体のテーブルごとにアクセスするものではないからだと思う。
パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
493:nobodyさん
08/05/10 23:26:26
>>492
結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
494:nobodyさん
08/05/11 00:27:11
runkitでaopみたいなことしたかったけど
セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
495:nobodyさん
08/05/11 00:39:19
俺485。おまいらレスありがとう。
でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
496:nobodyさん
08/05/11 00:43:17
俺は485なんだけど441でもある。
>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
497:nobodyさん
08/05/11 00:50:47
つーか休まないと日本語処理能力が低下しまくっていかんな。
>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
498:nobodyさん
08/05/11 01:04:31
一対一でマッピングされてるからって
そのテーブルに対して「のみ」のモデルじゃない
499:nobodyさん
08/05/11 03:58:08
いまだにsmartyとか言ってる意味がわからん
検討にすら値しないだろ
500:nobodyさん
08/05/11 04:09:26
結局viewヘルパってどれがいいんだろうな？
・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
501:484
08/05/11 05:00:31
>>495
>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
502:nobodyさん
08/05/11 08:41:33
>>484
>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
503:nobodyさん
08/05/11 08:51:20
>>498
そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
504:nobodyさん
08/05/11 09:50:03
モデリングの時点でオブジェクト間の関連は定義されるんだから相性が悪いということはないと思うけどな。
設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
505:nobodyさん
08/05/11 13:40:27
オープンソースのフレームワーク開発ってどういうビジネスモデルなんだろ？
symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
506:nobodyさん
08/05/11 14:20:23
ひょっとしてそれはギャグで（ｒｙ
507:nobodyさん
08/05/11 14:24:05
いやギャグじゃないよ
どこからか金が環流しないと時間と労力投入できないじゃん
508:nobodyさん
08/05/11 14:44:30
>>502
お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ
それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ
509:nobodyさん
08/05/11 14:49:35
デザインとロジックの無意味な議論うぜぇ
510:nobodyさん
08/05/11 15:03:35
>>508
>>502じゃないが、デザインとロジックの分離のレベルは
WicketやMayaaレベルを言ってるんだろう。
俺も分離するならそのレベルが妥当だと思う。
逆にそのレベルで分離できないなら、
開発者には必要とされてもデザイナには使いにくいことに変わりないと思う。
511:nobodyさん
08/05/11 15:25:06
>>510
んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
そもそも一番のメリットは上に書いたがテンプレートにロジック書くようなｳﾝｺ野郎を排除するところだし。
512:nobodyさん
08/05/11 15:54:25
>>511
>んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
>.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
すまんが主語は何だ。smartyが、か？
WicketやMayaaはテンプレートがHTMLなので（独自タグや{if}等が無い）、
HTMLしかしらないデザイナも扱いやすいし、
HTML編集ソフトでテンプレートを読み込んで修正しやすいのがメリットなんだが、
そんなメリットは必要ないってことか？
513:nobodyさん
08/05/11 15:55:42
RDB使ってる時点でSQL便利は自明
SQLイヤならOODB使うしかない
514:nobodyさん
08/05/11 16:05:35
Javaのテンプレートには、PHPのSmartyよりも優れたものがあるんですね。
参考になります。
ついでにPHPにも移植してください。
Wicket
URLﾘﾝｸ(www.wicket-ja.org)
Mayaa
URLﾘﾝｸ(mayaa.seasar.org)
515:nobodyさん
08/05/11 16:19:02
>>513
そう、SQLってかなり完成度高いんだよね。
SQLで拾った値でインスタンス作っても作らなくてもいいんだけど、
拾うためにインスタンス作るのに何のメリットがあるのか。
SQLをラップするのって、正規表現が分からない人向けに正規表現エンジンをラップして
簡単なテキスト検索エンジンを作ってるような気持ち悪さを感じる。で、正規表現をつかう
抜け道も用意してありますみたいな。
516:nobodyさん
08/05/11 17:42:48 tIr1XyIc
>>512
先生、WicketやMayaaをsymfonyと連携させる方法を教えてください＞＜
smarty使わないので教えてください＞＜
517:nobodyさん
08/05/11 17:43:09
sage忘れちゃったよ
ごめんね
518:nobodyさん
08/05/11 17:49:27
SMTPのプロトコルが分からない人向けにその部分をラップして
簡単にメールを送信するmail()関数がある。で、プロトコルしゃべる
抜け道も用意してある。
SQLラップするのも正規表現ラップするのも同じ。ライブラリとはそういうもの。
519:nobodyさん
08/05/11 17:52:41
SMTPはプロトコルとしての完成度高く無いじゃん。ただの規格。
520:nobodyさん
08/05/11 17:58:59
>>519
ん？完成度が高いものはラップする必要なく、低いものはラップして当たり前ということ？
521:nobodyさん
08/05/11 18:49:51
ラップの必要性の比較で言えばいうまでもなくそうだろ
522:nobodyさん
08/05/11 19:01:31
まぁ抜け道が前提のラッパーを見て、何も感じないなら、それはそれで才能だと思う。
PG/SIerとしては、そっちのほうが幸せかもしれん。
523:nobodyさん
08/05/11 19:19:10
>>521
で、その完成度の高い低い、ラップすべきしないべきは誰が決めんの？
結局自分の趣味趣向で言ってるだけなんだよなぁ。
524:nobodyさん
08/05/11 21:01:26
>>501
> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
クビにするべきだろう。
> デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレートを渡すという事は、責任を渡すという事と同義だよ。
> 使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
こう言ってるって事は、理不尽さを感じながら妥協をしていて、それを愚痴ってるんだと思うんだが、
たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
たとえば、ウンコ書くプログラマが居る可能性がある時に、
そのプログラマが極力コードを書けないように制限する事は困難だと思う。
制限を課す事に手間を割くくらいなら、生産性のある作業に注力した方が良いんでないかい。
525:nobodyさん
08/05/11 22:06:59
>>524
なんかもう精神論じゃん。
フレームワークを改良するって発想がそんなに嫌かね。
526:nobodyさん
08/05/11 22:15:43
>>524
本当にプログラマ？
すぐクビにするとかテンプレート渡す＝責任を渡すとか
到底社会人の発想とは思えないんだが。
サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
527:nobodyさん
08/05/11 22:19:14
RubyでもWicketの仕組みを実装する動きがあるみたいだな…
528:nobodyさん
08/05/12 00:11:47
SQLが便利ってマンセーしてる人って、文字列およびプログラム内のデータ管理に
自信のある人なんだなーって素直に感心してる俺ｗ
とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
されてないの？
まあ「MVCのモデル」ってレベルではなく、DBIインターフェイスレベルの話ではあるん
だけどｗ
529:nobodyさん
08/05/12 00:52:56
SQLを一切書かずORMだけでRDB使えてますか？
SQLより速くてインピーダンスミスマッチのないORMがあったら教えて！＞＜
分類 / 基礎となる計算モデル / 例
1. 手続型言語 / チューリングマシン / C, Java
2. 問合せ言語 / 関係モデル / SQL
3. 関数型言語 / ラムダ計算 / Lisp, Haskell
4. 論理型言語 / 一階述語言語 / Prolog
（2～4は、非手続型言語）
↑1～4のどれでも使えるようにしておいた方がいいよ
＝RDBを使ってる人はSQLも必須スキル
つURLﾘﾝｸ(www.amazon.co.jp)
530:nobodyさん
08/05/12 01:12:44
うーんなんだろ。全然違う部分で話しちゃってるのは自覚してる
「SQL」って言っちゃうと、結局最終的に「文字列」に落とし込まなきゃいけないのが
違和感があるのかも
メソッドの引数とかオブジェクトのプロパティとかなら抵抗ないのに・・・
PerlやRubyで /\A"[^"]+"\z/ みたいなリテラルで書くことの出来る正規表現を、
文字列として "/\\A\"[^\"]\"\\z$/" って書かなきゃいけない歯がゆさみたいなｗ
だから、変数的な部分をプレースホルダにしたprepare(), execute() インターフェイスが
あれば、それで良いのか。それなら、変数的な部分以外はけっこうソリッドに組み立て
られる、と考えて・・・でも、やっぱりパラメータの数が変わったらプレースホルダの数も
変わるし・・・
いかに簡単にSQLを組み立てるかっていうツールとしてのモデルの効能が、あんまり
問題になっていないから書いてみたっていうだけ。低レベルだとは思うけど
531:nobodyさん
08/05/12 01:35:11
いいだろ文字列で。どうせ大したもん作ってねぇくせにぐだぐだ言うな
532:nobodyさん
08/05/12 02:19:06
ORマッパーが流行った理由は2つあると思う。
1つはJOINを駆使したりサブクエリーを使うような、（比較的）高度なSQLを書ける人が少なかった。（複雑な処理はホスト言語で処理する。）
もう1つはORマッパー＝オブジェクト指向を連想させ、オブジェクト指向って言葉だけをやたらもてはやすような風潮に乗っかった。
533:nobodyさん
08/05/12 03:49:51
O/Rマッパーで書けるような簡単な処理は
SQLで書いてもすぐ書ける罠
534:nobodyさん
08/05/12 03:51:14
結局、O/Rマッパーは、SQLに慣れてる人なら
あまり意味ないってことでいい？
535:nobodyさん
08/05/12 03:56:57
なんだかんだ言って、Java的な発想なんだろ？＞ ORマッパ
ActiveRecordとかはシンプルでいいと思うけど、やりすぎ感っての？あるんじゃね？
APIが全てで、文字列としてのSQLを流し込むっていう感覚があんまり無いって感じで。
（C#とかの.net系でもO/Rマッパって使うのならごめん）
でも、PHPになじむかどうかは別問題なんだろうとは思う
536:nobodyさん
08/05/12 04:10:33
DBとベタベタにしないためにラッパー書くのは無駄じゃないと思うけどね
537:nobodyさん
08/05/12 06:31:54
>>532
私見だけど、メモリ中のオブジェクトをそのまま永続化させて使用するための
手段として RDBへの格納するのが良いのではないかっていう考え方があって、
でも現実には永続化よりもデータベース的な検索のほうが重要なことがはっきりして、
結局ラッパーとしてだけ生き残ったって感じではないかと思う。
まぁ、そうした抜け殻のようなツールとし出来上がった後、現場では >>532みたいなな
流れで流行ったんじゃないかと。
538:nobodyさん
08/05/12 07:26:54
>>528
>とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
>あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
>されてないの？
思うに、「フレームワークのパワーを生かした」開発においては、そういう小難しいことは、
基本的にやらない、もしくは極力避けるんじゃないかね。
フレームワークが力を発揮するのは、単機能な画面が多数あるようなシステムだと思う。
そうした前提においては、動的なSQLを嫌ったとしても、それは普通な判断だと思うし。
539:nobodyさん
08/05/12 23:55:26
PHPTALというのがあってだな。
URLﾘﾝｸ(tracfort.jp)
540:524
08/05/13 02:06:31
>>525
いや、sfSmartyViewPluginは間違いなくsymfonyにとって改悪だと思うわ。
>>526
権限と責任が乖離している時点で、体制を考え直すべきだよ。
仮に、よほど信用出来なくて悪意があってとても偉いデザイナーと仕事をしてるとしても、
MVCやORMという概念や、symfonyやsmartyという実装は、
プログラマーとデザイナーの「責任の所在」を明らかにするための方法論では無いと思う。
>>528
俺はORMには否定的だけど、SQLを抽象化する事には肯定的。
541:nobodyさん
08/05/13 02:11:29
自分がsmarty使うかと言えば使わないが
因習的に使い続けてるところもあるだろ
そういうところのために出来ただけじゃねーの>smartyplugin
いちいち目くじら立てるようなものでもない思うが
542:524
08/05/13 02:23:12
>>541
うん。>>484が偉そうにsymfony+smartyが完璧だと言ってたので、
そりゃねーよ、って反論してるだけだ。
よく考えればスレ違いな主張に相手してる気がするので、smartyに構うのは以後控えるわ。
543:nobodyさん
08/05/13 08:44:20
>>524
>> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
>
>クビにするべきだろう。
大賛成。お金をもらう仕事に、なんでウンコな人間を混ぜなきゃいけないの?
>たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
そうそう。それができない環境はプロとして仕事すべきじゃない。
>>526
> 本当にプログラマ？
> すぐクビにするとかテンプレート渡す＝責任を渡すとか
> 到底社会人の発想とは思えないんだが。
なんで? 使えない人間は教育し、それでも使えなければクビでいいじゃん。あんたどこの公務員よ?
> サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
> 分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
分業することと、ウンコを混ぜる話は別だろ。それをいっしょくたにしているおまえがウンコ。
544:nobodyさん
08/05/13 10:54:49
ORマッパーが流行った理由は3つあると思う。
1つはJOINを駆使したりサブクエリーを使うようなSQLから生成されるデータを扱うにはハッシュの配列では使いにくかった。
SQLには方言があり簡単な文でさえダブルクォーテーションとクォーテーションの意味が違うなど複数のDBMSに対応しづらかった。
もう1つはORマッパー＝オブジェクト指向であり、ただのデータの出し入れに過ぎないSQLに様々な付加価値をつけることが出来た
（たとえばバリエーションなど）
545:nobodyさん
08/05/13 11:43:53
>>543
厨房乙。
546:524
08/05/13 13:10:19
>>545
あまり恥ずかしい書き込みをするなよ。
>>544
それは全部PDOの利点でもあると思う。
PDO != ORMなので、ORMの利点だとは言えないと思う。
CreoleとPropelの違いを理解した上で、
Propelの機能として好ましいと感じる部分は、
propel-generate-modelとBasePeerのクエリ生成部分かな。
BasePeerははっきり言って複雑なSQLは全く書けないけど、
でもまあ、そのあたりの機能だけ流行れば良かったのに、と思うよ。
547:nobodyさん
08/05/13 15:35:20
さくさく人材切る大量と度量があるのはいいことだが
首にできる権限がある奴に限って現場見てねえんだよなぁ
548:nobodyさん
08/05/13 16:32:21
俺俺form処理クラス書いてるが
フォーム要素が多次元配列になる時のバリデーションが
きれいに書けないよう・・・
値はコンポジットパターンになるのに
errorはchildだけじゃなくて親も持つとか複雑過ぎ
549:nobodyさん
08/05/13 19:27:51
>>546
544はPDOの利点ではない。PDOはフェッチしたデータの加工をしないし、SQLの方言の抽象化もしない。
550:nobodyさん
08/05/13 21:12:36
SQLの結果セットは2次元の表にしかなり得ない。連想配列ですべて解決する。
551:nobodyさん
08/05/15 02:42:52
Rubyは引数が一つの時()を省略できるのに
PHPは省略できないんですかぁ？
ださーい
552:nobodyさん
08/05/15 17:59:00
>>551
VBなら引数がいくつでも()を省略できるぞ！
カッコイイだろ！
ただし戻り値が無い場合ね
553:nobodyさん
08/05/15 18:06:07
Rubyでもできますよーだ
VBなんて中二みたいの名前の言語使いませんよぉ
ださーい
554:nobodyさん
08/05/15 18:06:50
>>550
返ってくるデータが二次元の表だけって面倒だよね。
たとえばアドレス帳があったとして、電話番号を複数登録できるようにしたい。
まあ、普通は正規化する。んで、それを取得すると
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
こうなる。階層的に取得できたらどんなに使いやすいか。
555:nobodyさん
08/05/15 18:07:41
()が省略できる言語は
ダサいって流れじゃないのか？ｗ
VBやRubyはダサい。
556:nobodyさん
08/05/15 18:13:49
できるかどうかならできた方が当然良い
関数と変数の区別をはっきりつけたいから使おうとは思わないけど
557:nobodyさん
08/05/15 18:30:45
きっちりルール決めて統一してくれたほうがいい、って意見もあると思うぜ
558:nobodyさん
08/05/15 18:36:25
その辺はコーディング規約でやるべきじゃないの？
いろんな人がいるだろうし
559:nobodyさん
08/05/15 18:37:54
>>554
PDO使えばできる
560:nobodyさん
08/05/15 18:52:47
あれは賛否両論だろ。
引数省略に付随する問題も一緒に抱えるのに
手放しで喜ぶ馬鹿は死んだほうがいい
561:nobodyさん
08/05/15 21:30:45
>>559
できねーよ
562:nobodyさん
08/05/15 21:31:41
>>561
できるーよ
563:nobodyさん
08/05/15 23:37:08
>>554
それがリレーショナルDBだから。
オブジェクトで扱いたいなら、ORMじゃなくって、OODBを使えばいいんだよ。誰も使ってないけど。
もっともその例って、単なる配列のデータ構造を表してるだけで、オブジェクトとは関係ないと思うけど。
564:nobodyさん
08/05/15 23:50:37
>>563
そりゃ、元のレスが
> 連想配列ですべて解決する。
だからだろうね。
RDBの結果なら連想配列で全て表すことができるっていうだけの書き込みに対して、
それが便利なのか？っていうつっこみなんだろうと思った。
>>554が例に挙げてる様なデータなら、多次元の配列で処理する人も多いだろうし
O/Rマッパとはまた違う次元の話の様な気もするｗ
565:nobodyさん
08/05/16 00:41:02
というか、そんな陳腐な工夫を語れるような小さくて整ったデータベースしか扱ってないんだな、おまえら。
566:nobodyさん
08/05/16 00:51:22
PHPですよ？しかも（主に配布されてる）フレームワークのスレ。
そんなに複雑でビジネスロジックとその他もろもろの制約によって
アドホックばりばりのシステムの話なんてするところじゃないじゃ無いか
567:nobodyさん
08/05/16 05:20:25
PHPでビジネスロジックや「そのたもろもろ」の制約を必要とするよーな設計するか？
そういう制約が意味あるのって、DB専門班とぎっちぎちに分業するようなケースだしなあ。
null拒否くらいならデバッグの意味はあると思うけど
PHPみたいな上層で使うモンなら正規形も凝らんでそ
制約意識するくらいなら処理ロジックや自前キャッシュ手法に凝った方が百倍マシ
PHPが生かせるケースじゃない
なんか元コメ辿ると、bindやprepare使えば十分だろ的な思惑も感じるけど
568:nobodyさん
08/05/16 17:52:55
言語で設計が決まるわけじゃない
569:nobodyさん
08/05/16 19:19:07
むずかしいことばのかいせつ
アドホック - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
アドホック（ad hoc)は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。
ヨーロッパ諸語では様々な語句と組み合わせて用いられている。
ad hoc quering アドホック・クエリ
情報科学分野の用語。
アドホック・クエリを使えば、カスタマイズされたクエリを簡単に作成することが可能になる。
通常、データベースの原理やSQL 文を深く理解していなくても、GUIを使って行うことができる環境が提供されている。
ただし、このような方式のクエリが多用されるとデータベース システム全体のパフォーマンスにも影響が出かねないため、直接に"生"のデータベースを対象とするのではなく、"生"のデータベースを定期的に複製したものを対象にクエリを作成する、というようなことも行われる。
そのような複製は「データウェアハウス」などと呼ばれることもある。
570:nobodyさん
08/05/16 19:20:35
アドホックとは - はてなダイアリー
URLﾘﾝｸ(d.hatena.ne.jp)
アドホック あどほっく
【ad hoc(羅)】取ってつけたようであるさま。
この意味より，「恒久的でない」とか「反復的でない」ような形容に使われる
571:nobodyさん
08/05/16 22:43:59
>>562
どうやって？サンプルコード示して。
572:nobodyさん
08/05/16 22:47:17
マニュアル読めーよ
573:nobodyさん
08/05/16 22:53:58
ま、そーやって逃げるのは分かってたからいいけど
574:nobodyさん
08/05/16 22:59:30
低脳おーつ
575:nobodyさん
08/05/16 23:36:11
お前、ほんと残念なやつだな
576:nobodyさん
08/05/17 00:30:15
しょーもない煽りあいｗｗｗ
577:nobodyさん
08/05/17 00:50:50
反応するおまえもだよｗ
578:nobodyさん
08/05/17 03:55:36
PEAR使う時ってラップしたクラス書く？
そのまま使う？
579:nobodyさん
08/05/17 04:45:21
時と場合によーる
580:nobodyさん
08/05/17 09:38:16
PDOで階層構造表現できるの？まじ？
581:nobodyさん
08/05/17 13:16:01
マジ。ただし、O/Rマッパーが必要
O/Rマッパー最高！！！
という流れですね。わかります。
582:nobodyさん
08/05/17 13:43:24
>>581
それはPDOだけでは不可能で、
PDO無くてもORMがあれば可能という話ではないのか。
583:524
08/05/17 19:36:50
>>549
そうだね。
「ハッシュの配列では扱いにくい」と言ってるってことは、
PDOが連想配列で返すのを不便だと感じているという事だもんね。
俺は>>550と同意見だった。
オブジェクトが返ってくる事自体にまったく利点を感じないのだ。
データベースエンジンの差異を吸収するのはORMの副産物だと思うし、
それをやってくれるORMじゃないライブラリは好きなので、
やっぱり俺は世にあるORMにはあまり意義を感じていないのかも知れない。
バリエーションって何？
584:nobodyさん
08/05/17 21:39:55
>>583
そもそもオブジェクト指向に意義を感じてないんじゃない？
585:nobodyさん
08/05/18 00:27:53
オブジェクト指向で分析→設計→実装するとき、オブジェクト指向プログラミングの形とマッチしますね。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
モデリングの過程がオブジェクト指向じゃないと、あまり劇的に便利という実感は湧かないかな？
586:nobodyさん
08/05/18 00:44:42
>>583
RailsのARとか使ったことあるの？
587:nobodyさん
08/05/18 02:08:18
公開されたキモゲータウンのフレームワークがPerlで作られててPHP脂肪ｗｗｗ
588:nobodyさん
08/05/18 04:15:22
むしろ歓喜しているように見える
589:nobodyさん
08/05/18 08:26:46
ひさびさに脂肪ネタ来たｗ
590:nobodyさん
08/05/18 18:14:47
CSSもDRYを求められるよな
単にデザインセンスだけでなくプログラマ的な素養が必要
お前らのデザイナはDRYでびゅーちふるなCSSを書けるの？
それともお前らが手直しするの？
591:nobodyさん
08/05/18 22:23:00
なんでそれをこのスレで聞くん？
592:nobodyさん
08/05/18 22:31:44
>>590
因みに俺のところでは手直しも指導も回答も全部俺がやっている。
つうか、エディタを使う作業は、たいがい俺に回ってくる。
一度も書いたことがないASをいきなり書けたら天才呼ばわりされた。
ほとんど使わないエクセルでマクロをいきなり書いたときもそうだった。
冗談じゃない、感心するなら金くれと言いたい。
うぇぶでざいなー（笑）の100倍は貰って当然だろ、本気で。
593:nobodyさん
08/05/19 00:14:19
DBの結果セットをそのままクラスにするなんてJava屋の発想だな。もしくはアカデミックな人の発想だ。実戦的じゃない。
ウェブアプリって、一覧画面なら連想配列の配列、詳細画面なら連想配列でDBから情報を取得して、HTMLという静的な状態に移す、ほとんどはそれで済む話。
複雑なロジックを伴うクラスが必要な場合だけクラスにすればいい。そういうクラスはDBからだけで構成されるわけじゃない。ORMからさらにDAOと2重にラップする必要はない。
594:nobodyさん
08/05/19 22:23:22
まあぶっちゃけJavaには連想配列はないから、どうやったってオブジェクトにはなるんだけどな
それをモデルとして便利にする方向はある意味自然か
595:nobodyさん
08/05/20 17:15:34
Zendが身売り準備開始してPHPリアルに脂肪ｗ
596:nobodyさん
08/05/20 17:39:18
これか、
URLﾘﾝｸ(jp.techcrunch.com)
PHPそのものはともかく、ZendFrameworkとかは影響うけるかもね。
597:nobodyさん
08/05/20 17:46:06
買収先「ZendFrameworkぅ？なんだこの糞FWは！？捨てろ！
ってなるに500ペリカ
ZFなんかを使っていた先見の明ない奴ら涙目ｗｗｗ
598:nobodyさん
08/05/21 11:31:16
もしPHPが有料の製品になったらどうする？
俺は捨てるｗｗｗ
599:nobodyさん
08/05/21 15:22:14
なるわけねえだろ。さすがに。
600:nobodyさん
08/05/21 15:48:10
Microsoftが買収したら、なにやらワケが判らぬフレームワークが前提になって、
そのフレームワークの機能はIISでしか動かないみたいなのはあるかもよ。
あぁ、想像しただけで嫌だ。
601:nobodyさん
08/05/21 22:30:45
MSにはASP.NETという洗練されたフレームワーク、VisualStudioという高機能なIDEがある。ガキのおもちゃのようなPHPと一緒にするな。
602:nobodyさん
08/05/21 23:44:23
ASP.NETってどこで使われてるの？
GoogleとかYahooとかAmazonとか楽天とかMixi見たいな大手で。
もちろんMicrosoftのサイトは除いて。
直感だけど、MSのフレームワークが前提になったらPHPは確実に死ぬと思う。
603:nobodyさん
08/05/22 00:36:44
>ASP.NETってどこで使われてるの？
うちJavaに次いで.net/レガシーASP案件が多いよ
でもASPはイントラ用途での案件ばっかりだな
IISに.netにMSSQLにPowerShellにVSSと、MSモノで固めた場合は
けっこういい環境だと思うんだけどねー。
MSモノだけやる訳じゃないせいか、誰もVisual Studio使ってないけどw
つまり、MSモノで固められるケースが限られるのが問題なんだろう。
レン鯖とかでも（Javaともども）機能制限しにくい故にユーザに提供しにくいしな。
その隙間をPHP需要が埋めているんじゃないかい。
604:nobodyさん
08/05/22 01:06:04
ASP.NET → PHP.NET
まさかのM$大逆転
605:nobodyさん
08/05/22 01:06:57
>>603
結局さ、ASP.NETが良いのってSIerにとってでしかないと思うんよ。
小さく使われる、汎用性がないプログラムとしてと言うか。
そういう前提がなければ PHPなりPythonの方が有用だから、大手のサイトでは
ＰＨＰやPythonなんかが使われてるじゃかなろうかと思ってる。
仮にＭＳに買収されたら、PHPはPHPらしさを残せるかのかなぁ。かなり不安。
606:nobodyさん
08/05/22 01:11:58
VisualBasicの後継はVisualPHPで
607:nobodyさん
08/05/22 01:22:14
どうVisual・・
っていうかDreamWeaverとかじゃねえのそれ
608:nobodyさん
08/05/22 13:40:13
ASP.NETくらい作りこまれたフレームワークはない。コミュニティベースのフレームワークとは出来が違う。VisualStudioもそうだけど。
ただ、イントラ以外の、一般のウェブサイトの場合、結局凝ったデザインを実現するための泥臭い部分に多くの労力を割かれるので、ASP.NETのメリットは薄れる。
後は、LAMPみたいに全部無料ではないので、中小規模の場合、LAMPを選択することが増えるだろうな。
609:nobodyさん
08/05/22 15:06:08
実際、WEBアプリ業界って言ったら、Windowsサーバに抵抗感があるというか触ったことのない
会社・技術者も多いんだけどね。特にCGI等の設置運用あたりからぽこぽこ出来た会社はｗ
610:nobodyさん
08/05/22 15:43:18
泥臭い部分で真価を発揮できない作りこまれたFWとかｗ
そういう仕事を片付けるためのFWじゃねーのかよ
コミュニティベースかそうじゃないかで
出来が云々とかいかにもMSのバカ顧客らしい発想だ
その作りこまれたFWとやらで死ぬまで
綺麗で泥のないアプリを作りつづけてろ
611:nobodyさん
08/05/22 16:11:39
>>608
想像だけど、 確実にMS は Yahoo みたいな超大規模なところには、ほとんど無料で使えるような
営業をかけてると思う。仮に Yahooのサイトが ASP.NETで運用されれば、広告効果大きいし。
だから、ASP.NETが PHPとかPythonより大規模なサイト構築に向いていれば、使ってないはずがない。
パフォーマンスの問題か、セキュリティに対する透明性の問題か、生産性の問題化は判らんが、
大規模なサイトにおいては ASP.NETは PHPとかPython以下という評価がされているだけだと思う。
中規模なところには普通にしか販売しないだろうから、ASP.NETはイントラみたいな小規模なところでしか
使われない気がする。SIerとしては、そっちのほうがマーケットが広いだろうから、そんなに悪い話でもないけど。
612:nobodyさん
08/05/22 17:50:15
MS製品はしょっちゅうトロイとか埋め込まれてる印象
613:nobodyさん
08/05/22 23:15:21
いや、大企業ほどIISの比率が高いから。金がかけられるところはJavaやASPが多い。
Apacheが強いのは予算のないところとか、２ちゃんみたいにひたすらウェブサーバの数を増やしたい大規模なサイト。
614:nobodyさん
08/05/22 23:18:13
補足しておくけど、大規模なサイトと予算の大きなサイトは別物だから。
615:nobodyさん
08/05/23 00:01:10
でも結局ネットでビジネスやってるようなシステム運用に詳しくて、大規模なトラフックがあるところは
あんまりASP.NETを使用してないんでしょ？やっぱ本質的な問題があるんじゃないの。
事例見ても、イマイチぱっとしないし。
URLﾘﾝｸ(www.microsoft.com)
616:nobodyさん
08/05/23 00:55:23
実際MSを全面的に信用してる奴は少ないと思うよ。
本質的な問題、とやらがあるのかどうかは判らんけど、
「ソースが公開されてていざとなれば力技が効く」世界とは180度方向性が違うからねえ。
その事例のリード文で処理規模謳ってるのはセガダイレクトくらいか
「.aspx」で終わるURLぐぐるといろいろ出て来るけど、大規模サービスって感じのはないなー。
リネ2のwebとかJR東の運行情報とかパンヤのwebとか地図閲覧サービスとか
まあそれなりに規模あって安定性が望まれるサービスも垣間見れるね。
致命的な弱点があるようには見えないな
オープンソースじゃない事、ってのは一つの理由になると思う。
617:nobodyさん
08/05/23 01:25:55
htmlエスケープどういう方針でしてる？
俺は文字列と、文字列が入った配列を再帰的にエスケープして、
オブジェクトはそのままviewに渡してるけど
618:nobodyさん
08/05/23 06:55:54
>>617
本質的にはhtmlを生成するときにその場でコンテキストにあわせてエスケープするのが適当だよ。
htmlに入れ込むといってもテキスト要素として入れ込む場合と属性値としてクオートの中に入れるばあいなんかに分かれるから。
619:nobodyさん
08/05/23 10:28:17
日本はApacheのシェアが高い。
日本は今でもApacheしか対応してないレンタルサーバ屋が多いけど、アメリカは昔からレンタルサーバ屋がIISとApache両方対応してた。
Fortune1000を対象にしたシェア調査が少し前に話題になったけど、大企業のコーポレートサイトなど、予算のかけられるところはJavaやASPが強い。
PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
620:nobodyさん
08/05/23 10:29:53
ApacheやLinuxのカーネルハックできる人材なんて、その辺のウェブ屋にはまずいないから。オープンソースか否かなんて関係ない。
621:nobodyさん
08/05/23 10:52:28
誰もWebServerとしてIISが劣るとは言ってないんだが、何を言ってるんだろ。
それにしても2回に分けて書くのは芸風か。
622:nobodyさん
08/05/23 13:01:37
>PHPで名もないウェブサイトしか作ってないと、そういう実感はないだろうけど。
↑俺のことですねｗ
Webアプリは、PHPとJavaしか使ってない★
ASP.NETじゃないと実現できない機能は今のところ無し(・∀・)
どうしてもASP.NETじゃないと無理なら手を出しますが、他の実現方法を探すかな？
…というかMS製品しか使っていない客には当たったことないです（ラッキー！？）
623:nobodyさん
08/05/23 13:04:32
大手のSIerではPHPを使う案件はやってないんですか？
大手＝PHPを使わない企業という定義でOKですか？
そんなわけねーだろｗｗｗｗｗｗ
624:nobodyさん
08/05/23 13:14:15
PHP→名もないウェブサイト→人生負組みのツールでもいいじゃん
自分が便利だと思ったら使えばいい
他人の判断、他人の価値観を気にして、他人に認められたいと思う演技を続ける人生は、勝ち組じゃない
奴隷じゃないなら、最後は自分の判断で決めろ
…俺はRuby、Pythonの準備をしときますｗ
625:nobodyさん
08/05/23 13:28:14
>>623
Javaなんかだと顧客側が動作環境を WebsphereとかWeblogicに限定してるところ
は多いでしょ。SI案件だとフリーの環境は一切使いたくないってのは普通だし、
そういう客のほうがカネ払いもいいだろうし。
ただ、そういうのは技術的な判断じゃないから、これをもって技術的にも良いはずって
言うのは愚かしいと思う。
626:nobodyさん
08/05/23 17:03:53
>>618
よくいるよな、おまえみたいな無知ｗ
属性値はいわばRCDATAなのでHTMLエスケープに関してはPCDATAと全く違いなし。
現在のほぼ100%のUAが、属性値もエスケープされていることを見込んでパースしている。
627:nobodyさん
08/05/23 21:22:09
>>626
618じゃないけど
RCDATA、PCDATAという用語は初めて知った。
参考になったよ、ありがとう
データ形式一覧
URLﾘﾝｸ(bakera.jp)
#PCDATA (構文解析対象文字データ) の解説
URLﾘﾝｸ(bakera.jp)
PCDATA は Parsed Character Data の略で、「構文解析対象文字データ」です。
RCDATA (置換可能文字データ) の解説
URLﾘﾝｸ(bakera.jp)
Replaceable Character Data、「置換可能文字データ」です。
628:nobodyさん
08/05/24 00:03:21
>>626
じゃあ、その上で、
どの時点でどのような処理をしてエスケープすればよいかを具体的に教えて。
629:nobodyさん
08/05/24 22:02:37
>>626
RCDATA言いたかっただけなんですね、
ええ、わかります。
630:nobodyさん
08/05/24 22:37:13
まるごと Ruby! 発売でPHP斜陽の感ありありｗｗｗ
631:nobodyさん
08/05/25 11:29:57
YahooとMicrosoftの仲人はPHP？
PHP on IIS - MicrosoftがPHPをフルサポート
URLﾘﾝｸ(www.microsoft.com)
【Special Seminar】 PHP on IIS - あなたの可能性を広げる、Windows 環境へ -
URLﾘﾝｸ(msevents.microsoft.com)
632:nobodyさん
08/05/25 13:35:47
P++
633:nobodyさん
08/05/25 16:38:21
>>626
javascriptのエスケープはコンテキストによって、
ブラウザによって必要とされるものは違うでしょ。
「HTMLエスケープ」っていう言葉が悪い気はするけど。
634:nobodyさん
08/05/25 22:06:40
>>633
どう違うの
635:nobodyさん
08/05/26 04:04:46
>>633
遠回しに言ってんじゃねーぞハゲ
HTMLエスケープはHTMLエスケープであって
それ以上でも以下でもない
636:nobodyさん
08/05/26 09:16:56
>>634
>>635
URLﾘﾝｸ(www.google.co.jp)
637:nobodyさん
08/05/26 09:25:06
テンプレートでデフォルトでhtmlspecialcharsされるようにしてる。
ユーザ入力でタグの中に何かを出力する場合(ほとんど無いけど)は、
ホワイトリスト方式。
638:nobodyさん
08/05/27 23:55:46
フレームワークのせいで後々のメンテの度に長時間取られる。
PHPなんて、なーんも考えずに工夫せずにコピペ最強でサクっと済ませられる「フレームワーク」なんだがな。
639:nobodyさん
08/05/28 01:02:34
規模によるって
話を単純化し過ぎ
640:nobodyさん
08/05/28 01:55:54
そうだよなぁ。
規模がでかいと、謎エラーの出所が分かんない場合あるよね。
何回も呼んでるフレームワークの関数で、止まる時とかさ。
大概人的ミスだから、CVSとかで誰がやったか、すぐにばれるんだがな。
そんな時はブーブー文句垂れるおｗ
641:nobodyさん
08/06/06 02:37:05
FW使うとメモリ喰うから
apacheのプロセス数が増えるとメモリが圧迫されてmemcacheが消えるね
一台の鯖で稼働できるプロセス数かなり減らね？
642:nobodyさん
08/06/06 07:32:19
一番メモリ食わない言語って何？
やっぱPerl?
643:nobodyさん
08/06/06 08:14:24
アセンブラ
644:nobodyさん
08/06/06 08:18:17
今時アセンブラでウェブアプリ書いてる奴いるわけねーだろ
はてなもPerlだし、やっぱPerlなのかな？
645:nobodyさん
08/06/06 08:56:45
軽いと言われるciですら、現在メモリ700KB
1リクエスト毎にドラクエ4の全容量以上のメモリを食うって一体…
646:nobodyさん
08/06/06 08:57:39
perlも良いフレームワークがあればもっと流行るんじゃない？
まぁ、続きは向こうで。
【Perlフレームワーク】Catalystを語る人
ｽﾚﾘﾝｸ(php板)
647:nobodyさん
08/06/07 08:06:42
PHPの場合、ウェブフレームワークがすべてのモジュールを内蔵していて、外部に独立してるのはせいぜいSmartyくらいだけど、
Perlの場合、Catalyst含めて、独立したモジュールが集合して構成されるので、PHPのようなウェブフレームワークとは意味が違ってくる。
648:nobodyさん
08/06/07 12:29:05
Perlでライブラリとして提供されてるものが
PHPでは関数やエクステンションで提供されてるだけの話で
本質的にはたいして変わりなくね？
649:nobodyさん
08/06/07 19:46:49
PHPはテンプレートエンジンもORMも、フレームワークごとにバラバラだから。
650:nobodyさん
08/06/07 21:25:56
なんでSmartyもしくはFlexyを敬遠するのかな、とは思ったことがある。
大体だれかが野良クラスで対応するじゃない。
パフォーマンスにしたって、それ以外の部分でがっつり重いFWも結構あるし。
もうViewクラスを作るのはほぼ共通なんだから、Zendがなんか作ってくれ
ないかな。if と foreach と変数展開（オブジェクトのメソッド呼び出し含む）と、
スクリプトでregisterしたヘルパメソッドのみが使えるとかいう感じで。
PDOみたいに組み込みクラスで速ければ、とりあえず俺は多分それを使う
651:nobodyさん
08/06/08 13:31:14 oe9fgjbi
そこでPECLですよ
652:nobodyさん
08/06/08 23:13:03
一番速いテンプレートエンジン - Blitz - Do You PHP はてな
URLﾘﾝｸ(d.hatena.ne.jp)
653:nobodyさん
08/06/09 02:02:29
一番速いテンプレートエンジンはPHPそのものに決まってるだろ。
654:nobodyさん
08/06/09 13:52:03
PHPそのものだと、構文がテンプレートっぽくない。
BlitzはPHP拡張として作られているから、PHPそのものといえる。
SmartyもPHPそのものに変換されるから、PHPそのものといえる。
655:nobodyさん
08/06/09 14:03:38
ところでPieceFrameworkはフロー定義を書き換えるたびにクッキー消さなきゃならんというガッカリな仕様は直ったのかな？
656:nobodyさん
08/06/09 14:28:34
テンプレートエンジン派ってデザイナにテンプレート書かせてるんだよな？
それ以外にテンプレートエンジン使ってる奴がいたとしたら救いようがないうつけ者だな
657:nobodyさん
08/06/09 17:37:34
>SmartyもPHPそのものに変換されるから、PHPそのものといえる。
これは違うだろ。うぇぶでざいなあが作る段階でPHPじゃないのだから。
658:nobodyさん
08/06/10 00:15:51 00QPcxQH
>>656
WEBデザイナー兼WEBプログラマーな私はSmartyを使っておりました。
最近はテンプレートは生PHPで充分ということに気付き、原点回帰しました！
659:nobodyさん
08/06/10 05:28:42
よく知らんのだが、「PHPそのもの」って言ってるやつのFWでも、それはあくまで記法だけで、
スコープを確保するためにファイルを読み込んでeval()してそうな気もするんだが、違うのかな。
それとも、グローバルにオブジェクト（や関数）を置いて、それを参照するのを前提にrequireなの？
660:nobodyさん
08/06/10 09:31:44
requireすると、呼び出し場所のローカルスコープで
実行されるので、別にeval()する必要は無かろう。
っていうか、そんなPHPフレームワークあるの?
RoRはerbでevalしてるが。
661:nobodyさん
08/06/10 11:18:10
ZF勉強していて思った。
MVCはいいけど、そのためにいろんな「専用の」クラスの使い方
を覚えなければいけないし、覚えてもZFのみってことは、
別のFWに変更するときや、ZF自体が消滅（ありえない？）するときには、
その資産がチャラになっちまうんじゃないの？
大規模開発に向いている、プログラミングの標準化ができるってのが
ウリだと思うけど、FW乗り換えなんかを考えるとデメリットも大きいよな。
そんなんだったら、自分のシステムに必要なクラスを自分で作って
充実させていったほうがいいのかな．．．．とも思う。
まあ、その維持管理が大変といえば大変だが、資産が消滅することや
方針変更で別のものに作り変えるときでも、ノウハウが残るから、
長期的なスパンでみるとメリットがあるんじゃないのかなあ。
特にシステム開発環境を選択している人、そういう問題点ってどう考えている？
662:nobodyさん
08/06/10 12:12:38
>>661
俺俺FWは、俺しか使えない。
他人が使うと、学習コストがかかる。
ましてや、俺と仕事するときにしか使えない。
その点、ZF等のFWは既に学んでいる人々がいる。
その人たちと共同で仕事ができる。
独りでできるもんっ♪なら俺俺でFA
既に学習した人たちのTips等を利用したり、
共同で作業したいなら、
既存のFWでいいんじゃね？
663:nobodyさん
08/06/10 12:15:11
ZFが無くなったときの心配は、ZFが無くなってからすればいいんじゃないか?
大体、オープンソースなんだからZF自体が消えてもコード資産はまるまる残るだろう。
まぁノウハウって奴を蓄積したいのならべつにどうぞ
664:nobodyさん
08/06/10 12:27:28
俺俺ラッパー書いてそこからZFなり呼び出すようにしたら
ZFが死んでもなんとかなるじゃん
665:661
08/06/10 13:05:21
>>662
確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
その内容を整理して文書にすればいいんじゃないのかな。
それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
無い分だけPHPを使える人は多いし、知らない人もちょいと学習すれば
使えるようになる。
>>663
ZFが消滅してもオープンソースだから残るだろう。
でもセキュリティホールや新しい技術は一切入ってこないよねえ。
>>664
ラッパーという手はあるが、実際簡単にいく？
666:nobodyさん
08/06/10 13:13:11
>>665
なんかもう>>661の中で結論決まってる予感。
667:nobodyさん
08/06/10 13:17:29
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
だからさ、その心配はZFが無くなってからすればいいってこと。
そんなもん心配していまから俺フレームワーク作るわっていうのなら、
セキュリホールだのなんだのはどっちみち全部自分で面倒みるんだろう?
668:nobodyさん
08/06/10 14:27:18
> 確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
> その内容を整理して文書にすればいいんじゃないのかな。
その文章を読まないといけないだろ？
初めて会った人が、あんたが書いたオレオレ文書を
すでに読んでいるなんてことはまずありえない。
その点ZFなら読んでいることはありえる。
> それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
オレオレFWの制約を受けるだろう。
何の制約もないフレームワークがあったとしたら、それは
フレームワークじゃなくて、ただのライブラリだ。
> 知らない人もちょいと学習すれば 使えるようになる。
使えるということと、開発の早さ・楽さは別の話。
> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
オレオレFWは、すでにセキュリティホールや新しい技術は一切入ってこないよねえ。
669:nobodyさん
08/06/10 14:50:32
FW乗り換えたら全てチャラっていう前提がおかしな話
WEBアプリのFW全般に対するノウハウってのもあるし
現に今のFWはほとんどMVCベースなわけで
基本的なコンセプトが大きく変わるわけじゃない
個人的なFWを作って使うのも別に悪くはないと思うけど、
オープンソースで開発されているFWが
どれだけレビューされてテストされた上で
リリースされているかよく考えてみるべき
乗り換えたら全部チャラだし俺俺FWの方がいい、
と安易に考える奴は自惚れてるとしか思えない
FWが変わったら覚えた事が全て無駄になる、ってのは
結局表面的な部分でしかFWを扱えてないわけで
FWに「使われている」プログラマでしかないよ
670:nobodyさん
08/06/10 15:11:29
いきなり俺俺は無謀だな
一回メジャーなFW使ってみてから手を出すならともかく
671:nobodyさん
08/06/10 16:42:19
オレオレFWを公開して普及させようと言うならともかく、自分に必要な仕組みだけ
自分で作るのが、そんなに悪い選択とは思わないけど。
672:nobodyさん
08/06/10 17:28:40
単純にZF死んだら困るから自分で作るよ!っていう理由に納得できないだけだろう。
673:661
08/06/10 17:29:20
>>669
FW乗り換えでも、MVCの考え方やノウハウは残るが、
現実的にアプリはすべて書き換え。
数十本ならそうでもないが、1000本単位なら相当な手間。
「FWに使われているプログラマ」はいいけど、現実的に手間を
掛けられないというところをわかってないのは問題。
同じFWに縛られ続けていくのはいいが、消滅しちゃったとき
どうやって資産をメンテしていくのか。
そういう意味でチャラって書いた。
だから >>665 が書いたようにオープンソースであること
を考えると、そういった問題が解決できそうだ。
また多くの人が使ってこなれている面はメリットだよな。
それで、実際どれだけのモンがFWで構築されてんだろ。
cakePHPなんかも有名だが、ZFが出て乗り換えを考える
人もいるだろうし、どうするんだろ。
674:nobodyさん
08/06/10 17:32:43
zfに乗り換える人なんていないでしょ
ショボfwじゃん
675:nobodyさん
08/06/10 17:35:53
どうやって資産をメンテしていくっていうか、
それは普通にソースツリーをフォークしてメンテするだけだろう?
自分でゼロから作るよりは随分と楽だと思うが。
676:nobodyさん
08/06/10 19:10:47
>>673
採用しているFWが変わったからって
既に出来上がってるアプリをそのFWに
全て書き換えるケースなんてそうそう無いだろ
完全な自社コンテンツでアクティブなものか
コンテンツ自体を総リニューアル時に合わせて移行、くらいなもんで
元から運用してるものは普通そのままメンテだろ？
千本単位とかそれこそ非現実的じゃないか？
677:nobodyさん
08/06/10 19:46:40
たとえばsymfony作られたサイト
世界全体でも1000もないだろｗ
678:nobodyさん
08/06/10 21:11:39
とりあえずDISる
↓
少し釣れる
↓
ツンデレ教えて君
こうするとggrksと言われないんですねわかります
679:nobodyさん
08/06/10 21:26:00
数字おおげさに言い過ぎる
↓
突っ込まれる
↓
雲隠れですねわかります
680:661
08/06/11 09:37:45
>>676
なるほど、すべて書き換えないケースもあるな．．．．
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。
>>677が書いたように、事実上PHPのFWはまだまだ
浸透していない、PHPでの開発は結局小規模なもののみ
ってことなんかな。
681:nobodyさん
08/06/11 09:58:12
>>680
大規模開発って、ふつうプロジェクト数のことじゃなくて、
ユーザ数とか、高信頼性を確保するために大きいシステムを組むってことだろう?
そんなものは、当然一件ごとに何年もかかることがままあるから、
大規模なプロジェクトを千なんてオーダーで抱えてるとこなんてありえないよ。
ていうか、自分が抱えてもいない数のプロジェクトの事と、
(まだつぶれていない)ZFが潰れることを心配して
自分で作った方がいいと思ったの???
682:nobodyさん
08/06/11 23:15:02
どれもこれも、今となっては、PHP4で書き続ける理由に説得力が伴っていないわな。
もうとっくに殆どの環境はPHP5に移行している。
lib/php内やフレームワークのコードだけがPHP4。
自分で書く時、例えば、varなんて使う機会が無い。
そのせいで、細かく曖昧さを指摘する目に見えないエラーがリクエスト毎に何10何100と出ている。
683:nobodyさん
08/06/11 23:37:36
>>681
>>661 ではないけど、大規模開発って言ったら、コード量をイメージするなぁ。
大規模サイトだと、ユーザ数が多いって意味なのかなぁって感じもするけど。
外部のフレームワークの適用については、例えばバグとかセキュリティホールが
あるからバージョンアップしてくださいって言われても、影響範囲が読めないと
二の足踏むし、かといってそのままってのも気持ち悪いし、自作しても知れてる
程度の使い方しかしないのなら、使いたくないってのは良く分かる。
684:nobodyさん
08/06/12 00:08:14
S2Container.PHP5 を勉強しようとセットアップのページ読んでるんですが、解りづらくないですか？
一番初めに書いてあるS2Container.version.tgzを落としてきたら拡張子が.tgになってるし、
＞S2Container.php と S2ContainerSplAutoLoad.php を require して下さい
って何のファイルに書けばいいのか書いてないし・・・。
685:nobodyさん
08/06/12 00:18:48
>>684
pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの？
で、PEARのディレクトリってPHP5を入れた時点でパス通ってて、
ソレを、これから加工と思ってる空のPHPにrequire_onceで例に書いてあるとおりに書けばいいんじゃないの？
違うの？
686:nobodyさん
08/06/12 04:04:39
>>685
個人的に、pearコマンドを使わないインストール方法をきちんと書いてくれないFWは信用できない。
S2Containerは触ったこと無いけど。
最初からPEAR必須ライブラリも把握できるし、必要最低限の設定等がわかっていれば、環境を
変えるときも対処しやすいと思う
687:681
08/06/12 12:13:00
>>683
つまり、アップデートのパッチを調べる労力 > 自分で書く+メンテする労力
ならば自分で書いてもいいってことね。で、コード量が少ないなら
書くのもメンテするのもたいした労力はいらないからそれもあり、と。
まぁそういう理由なら納得できる。
個人的にはFWを導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。
大規模開発ってやつについては、言うとおりコード量もあると思う。
なんていうか、大規模開発っていうのはプロジェクト一件あたりの
必要な金、期間や人力がデカいっていうことで。
688:nobodyさん
08/06/12 13:50:39 5LtH7vFx
JavaもどきのFW使うなら、素直にJava使えばいいと思う
Seaserは簡易版のTeedaに期待
689:nobodyさん
08/06/12 23:10:10
Webのページ上でボタン押したり、何かした時の処理は、
全部 Ajax 経由でいいと思う。
何かする度に、フォームの全ての値がサーバに送られて
画面全体がリロードされるのって変すぎる。
で、Ajaxと一体になってるフレームワークって何かありませんか？
690:nobodyさん
08/06/12 23:17:19
>>689
極端な意見ｷﾀｰ
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞｗ
で、そんなFWはこれから大流行するだろうから、しばらくのんびり待ってたら？AIRとかもあるしね
691:689
08/06/12 23:58:39
>>690
作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。
Ajaxから戻ってきたデータによって、JavaScriptで画面上の
変化部分を更新するとか、ある程度自動でできる仕組みがあると嬉しい。
更新したデータは、セッション変数で保持してればいい。
かと言って、ブラウザにプラグインが必要になるような技術もいやだな。
今のWebと親和性をなるべく保ちながら、より自然な開発がしたい。
もうちょっと真剣に探してみるかな。
692:nobodyさん
08/06/13 00:15:02
>>690
>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。
どうしてもその手の処理が必要な時は
「ユーザに断ってから」Applet立ち上げれば今時でさえ通じるもんだ
他不要
693:nobodyさん
08/06/13 00:25:04
>>691が感じている違和感がどの辺にあるのかよくわからないけど
サーバサイドはPHPで、クライアントはJavaScriptなりFlash(ActionScript)なりっていうのが
面倒ってこと？
>>691で書いているくらいやりたいことが決まっていれば、例えばW3CとECMAScript標準に
完全準拠の理想フレームワークなら、作ろうと思えば作れるかもね
どのみちデザインのためにHTMLで小細工しなくちゃいけないなら、それがやりにくい様なフォー
ムデータの扱いを強要するFWは結局流行らないだろうと思う
Ajaxを含むJavaScriptやFlashの技術は、まさにクライアント依存の妥協案というか手法というか、
っていう部分なんだから、それをサーバ側の組み方と違うと言って敬遠していては現状何も作れ
ない、とみんなそう思ってるんじゃないかなあ
だから、俺は今日もしこしこ正しいかどうか解らないJavaScriptを書きますよ、と。
694:691
08/06/13 01:22:41
>>693
違和感ってのは、>>689に書いた内容です。
画面の一部を変更したい時でも、画面全体に影響があるので、
プログラムがそれを考慮した構造になり、分かりにくいものになってしまいます。
GETとPOSTを分けたりすると、更に分かりにくくなります。
WindowsのGUIプログラミングのような開発ができたらいいなと。
イベントドリブンで感じで。
サーバサイド言語 + JavaScript (Ajax含む) でそういう仕組み
になってるフレームワークがないかなと思ったんですよね。
今の自分の作り方が悪いだけかもしれませんが。