DIでいいじゃん

>>549

＞ >>522
＞ > 後からスケールアウトしやすく設計されているフレームワーク
＞
＞ 実際、無いよなあｗ
＞
お前はFWを使いこなせてないだけ。

>>552
はいはい僕ちゃんは使いこなせてて凄いでしゅねー

おまいら仕事しろよ

>>549は>>522が言ってる「スケールアウト」を勘違いしてそう

>>549
レスありがとう
自分自身の感覚になってしまうけど、
CakeにしろSymfonyにしろ（この２つしか例に出せないゴメン）、
十分にスケールアウトを考慮した設計になってると思うよ。
でも逆に言えば、サーバ一台で完結させるような場合には、どうしてもオーバーヘッドが出て来るよね

むしろ本当に書き捨てでいいアプリならば、これらを使わずに
「俺俺」や「素のPHP」でもいいと思う。というかむしろそうする。

>>555
ん？
俺は>>522読んで、（アクセス規模に対する）スケールアウトという言葉の用例が、
DBレプリケーションやmemcacheにかかってるんだと思ってた。

>>556
アクセス規模が増えてDBレプリケーションやmemcacheを使いたくなった時に、
Cakeやsymfonyだと簡単に移行できるかどうかって話だよね？

>>511と同じく、個人的にはそうは思えなかったけど、改めて調べてみると、
CakeではDBレプリケーション対応は簡単みたいだね。Propel13はダメだ（反論求む）
それに後付けのmemcache対応はどっちでも難しい。（反論求む）
sfSuperCacheも後付けで使うには設計を直す必要があるし（反論求む）
URIの変更もsfRouteやroutesだけの設定じゃ厳しい（ずれてる？）

PHP最高（反論求む）

>>557

ZendFWを勉強してみたら良い。君の言う問題は全て解決する。

ZFは他のFWに比べると書くコード量が一回り増えるけどなｗ

>>560
そこがFWとして魅力を感じないよね・・
CakePHPのライブラリとして使うと結構その辺を補えるという話を聞くけど

memcacheなんてもともとシンプルなんだから自分でクラス書けばすぐじゃん
dbの分散化対応は面倒くさいけど

memcacheってほんの数行のサンプルコードしかみてないんだけど
たんに良くあるキャッシュコードでファイルに保存する代わりに
メモリに保存してるだけだろ？

PHPってやっぱりドイツの普及率が一番低いのかな？
ドイツ発のフレームワークってないし

イギリス発とかフランス発とかのフレームワークなんてあるのかい？

フレームワークは全部韓国発ですよ？

symfonyはフランス発だよ

ドイツ発PHPフレームワーク誕生！その名もadolf

>>559
kwsk

>>562
DBレプリケーションも、それ前提で自作すりゃ簡単だろうさ。
memcacheもそうで、key-value型のホルダを先に作っておけば移行は容易。

でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。

>>569

>でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
>それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。

>>562は、この点↑を含めて、既存のDBアクセス周りをラップする
クラスを作ればいいんじゃね？って言ってるんだと思うぞ

それに何でもかんでもmemcache頼みってのもどうかと思うぞ
DB周りのメモリチューニングとか、あるいはオンメモリDBを使うとか
その辺は検討したのか？

>>571

> それに何でもかんでもmemcache頼みってのもどうかと思うぞ

ごめん、memcacheの話は自分が最初に振っちゃったので、
>>549 (>>569)関係ない。
自分は>>549 (>>557) 読んで、まあ確かに、config書き換えですぐに対応出来る訳ではないよなーと
思った。

もうそろそろkey-value方式の
フレームワークが出ても良いと思うんだ。

>>573
普通にCakePHPは対応してるでしょ

違うか普通にキャッシュとして対応してるのか

>>575
そういうこと。

キャッシュではなくモデルがkey-valueを基礎としているフレームワーク

O/Rつかってリレーショナルなデータをオブジェクトに変換するより
楽じゃないかと思うけどな。

ストレージとして、barkleyDBのようなkey-valueなデータベースだけじゃなく
ファイルやRDBにも格納できる設計で。

>>571
> 既存のDBアクセス周りをラップするクラスを作ればいいんじゃね？

DBの結果セットをmemcachedに移行するというアプローチは、
自分でやった時はうまくいかなかったなあ。
結局、ご指摘の通りにオンメモリにして逃げちゃった。

なので、簡単に後付けで移行出来る方法があるなら良いなぁと思ったし、
無いんでないかなーと>>549で言っちゃった。

>>573-576
東京なんちゃら対応のなんちゃらモジュールがCakePHPで動くらしいね。
Cakeはよくよく調べてみるとみんなで結構何とかしちゃってる感がある。

チャットプログラム作ってって言われた。相手はシロートさん＆レンタルサーバってコトで、PerlかPHPの二択にほぼ決定。
Perlは正直「使える」程度なんでPHPにしようと思うんだが、Pearを使わないでファイルコピーで設置完了することが可能なFWってあるかな？
一応SymfonyはSandbox使えば可能なのは知ってるが、流石に少々重たいかと思ってね。

・・・ま、「チャットごとき素のPHPで書けよ」ってのは御説ごもっともなんだがｗ、
どうもバリデータやHTML／SQLサニタイズを手で書くのは億劫になってね。
FWに慣れすぎたかもｗ

FWに慣れすぎた人の質問とは思えないｗ

もしかしてPEARしか触ったことないんじゃ？

>>578
いまどき PEAR 使う FW はない
簡単なプログラムなら CodeIgniter でいいんじゃない？

PEAR(笑)
smarty(笑)

ちいたんで萌え萌えチャットを（ｒｙ

>>578
ぜったい釣りだろ、お前w

あまりにもトンチンカンな PHP 知識。dankogai 疑惑。

lol

どうせ個人的に使うチャットだろうし
全部１クラスにまとめたようなレトロな作りにしても十分じゃね
FTPでアップロードして権限振ったらすぐ使えます、のほうがいいような相手なんでしょ

大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ

つか、578の場合レンタルでも探したほうがいいんじゃねｗ
そっちのほうが間違いなく多機能で安全で優れてるとおもうぞ

>578
fitzgerald。本体が269行しかない。
http://www.moongift.jp/2009/06/fitzgerald/
バリデータは存在しないので自分で書かんといけないが。
一番面倒な、入力を一括してフィルタリングする機構はあるのでさほどの手間はない。

あと、エスケープ/サニタイズが面倒なのはお前が阿呆なだけ。
面倒ならエスケープしてからビューに渡す関数とか作れよ。

関数を作るのもめんどくせえー

まともなプログラマなら、小規模用の俺俺ライブラリくらい持ってるだろｗ
FWに慣れたっつーより、FWが無ければ何も出来ないの間違いじゃね？

正規表現とかもかけないんじゃね？ｗ

「相手はシロートさん」にﾜﾛﾀ
おめーも大差ないですよっと

PHP使いにまともなプログラマっているの？

いるわけねーだろ

まともという言葉がどこをさすのかによるだろうな

何度目だよ

Regexクラスとかできちゃいそうだよね

まともなプログラマは言語に依存せず、要件に見合ったコードを書く
PHPかどうかは関係無いし、PHPにも職人クラスのPGはいる。


ただ勘違いした「シロートさん」比率が、他の言語より圧倒的に多いｗｗ

Pealのにわかプログラマに比べればまだマシだけどな

PHPはどうしても冗長だからな。

PHPは取っつきやすいからな。
で、上達するに連れ、言語仕様に不満が出てくる。
そして、他の言語へ移る。

Web用言語の登竜門みたいなもんだから、仕方ないべ。
今更Perlから入る人も少ないでしょうし。

グローバル関数をクラスライブラリ化して、型宣言もアリにして、
OO言語に生まれかわらんかな。

既存のグローバル関数で発生したエラーを例外処理化したライブラリはないかな?