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

【PHP】フレームワー� ..

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
Wikipedia項目ﾘﾝｸ
アドホック（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を導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。

大規模開発ってやつについては、言うとおりコード量もあると思う。
なんていうか、大規模開発っていうのはプロジェクト一件あたりの
必要な金、期間や人力がデカいっていうことで。

次ページ