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

斜め読みだけど、結局言い出しっぺ(>>889)の言いたいことは

・サーバサイドと（リッチ）クライアントサイドで同じ言語で記述できれば楽できる
・だからJavaScriptでPHP実装をすることに意味がある

ってこと？
ただここにいる多数の感覚では、わざわざPHPを実装せんでもなあ、と。

それなら、むしろサーバ側でJavaScriptで書ければイイじゃんって>>891とかで
言ってるし、確かにそれでいいと思う。なんで>>889はJavaScriptよりもPHPがいいと
思うんだろう。

現状でも、JavaScriptエンジン組み込んだApacheモジュール(mod_javascript？)とか
あっても不思議はなさそうだけど、誰か作ってないのかな？
もしくはコマンドラインインタプリタとか。それでCGIはできるな >>929 が言うように。
（Windowsはまったく知らないのであしからず）

>>889の為にまとめてみたが、この辺りにちゃんと答えないとただの馬鹿で終わり？

>948
いや、プロジェクトは一つきりじゃないでしょ？
次のプロジェクトで新しいバリデーションコードを書くとき、
コードをコピペするのであれば、それは「よく似た違うコード」を生み出すことになる

結局、コードを主体に考えているからPHPとJS共用コードという発想になるので、
本質的な依存条件を考えた方がいいんじゃないの？という話

>>935
こいつはどう見ても並"未満"なのに、優しいんだなｗ

>>949
すべての勝負がお前の脳内だけで行われてるんだから勝てる奴なんていねーだろｗ

おもろい。
>>891で終わっている話といっている奴がいたが、
ぜんぜん違うや。こりゃ完全に>>891を覆したなｗ

>>952
> 現状でも、JavaScriptエンジン組み込んだApacheモジュール(mod_javascript？)とか
> あっても不思議はなさそうだけど、誰か作ってないのかな？

はるか昔はあった。ネットスケープのサーバーかなにか。
最近また出てきたみたいだが、まだベータ版。
選択しにはならないと思うよ。

>>950
自演恥ずかしいｗｗｗ

>>953
> 次のプロジェクトで新しいバリデーションコードを書くとき、
> コードをコピペするのであれば、それは「よく似た違うコード」を生み出すことになる

なんで？ バリデーションコードをそのまま使えばいいじゃん。

>959
うん、だからそれをするのがバリデータでしょ？
PHPでもJSでもそれを使えばいいんじゃないと言ってるわけ

>>960
だけど、俺が知る限りバリデータでは複雑なチェックはできないんだよね。
未入力チェックとか、正規表現の比較とか、数値の範囲とか、その程度。

ラジオボタンでAの値が選択されているときは、チェックなし。
Bの値が選択されているときはチェックあり。とかできる？

>889がPHPとJS共用のフレームワークを作るということでFA?

>956
いや、後から出てる反論のほとんどは>891で出てる。
それはいいんだけど、やはり実行に移さないことには価値がない

なんでバリデータライブラリって流行らないんだろう。
WEBアプリの入力チェックなんて、定番があっても良さそうなのに。
テンプレートエンジンと比べてえらい寂れようだ。フレームワークに結合されてしまってるのが多いからかな？

HTML_QuickFormも、結局入力がフォームデータ限定でしか使えないし、バリデータ部分だけ切り出せないのかな。
良いのがあるんだったらエロイひとお勧めして。

>>961
そういうのは多分設定ファイルでは無理で、バリデータクラスのサブクラスの指定メソッドに個別処理を書く、とかいう
対処になるんじゃないかなぁ、と勝手にライブラリ仕様を想像してみる。
>>960がどんなのをつかってるのかは知らないけど

後からわかっていたとか言っても
先に（PHPでもJSでも動く）コード書いた奴の勝ちって事だな。

>>963
> そういうのは多分設定ファイルでは無理で、バリデータクラスのサブクラスの指定メソッドに個別処理を書く、とかいう
> 対処になるんじゃないかなぁ、と勝手にライブラリ仕様を想像してみる。

で、そういうメソッドを書くとき、
PHPでもJavaScriptでも動くコードを
書けば楽って事でしょ？彼が言いたいのは。

あー。なるほどそういうことか。やっと納得した。

>>964
素でやると物凄く不自由なコードになってそうだｗ
foreachやsprintfが使えないPHPなんて本当に何のメリットもない糞言語だろ。

あと、文字列結合が素直には出来なさそう？
本当に限定された局面のみ有効になりそうだ。PHP.jsってそういうのはうまくやってくれるの？

http://kevin.vanzonneveld.net/techblog/article/javascript_equivalent_for_phps_abs/

このリストを見る限り、sprintfは使えるようだな。

PHPとJavaScriptではオブジェクトの仕組みとかお互い全然違うから、
もしコード共有しようとしたらオブジェクト指向できなくなるし、いちいち二つの環境で確認するのめんどくさい。

YAMLとかでヴァリデーションの条件書いて各実装でそれを実現するのがよっぽどスマートだと思うんだけどな。

少なくともサーバーサイドJavaScriptよりもさらに現実味がないと思うよ俺は。

でも>>961のような、YAMLのバリデーションで
対応できないような場合には使えそうな気もする。

>>967
PHP.jsはPHPの関数をjavascriptに移植しただけ。
JavaScriptでのPHP実装とかじゃない

予想に反して流れが良スレ化しててワロタｗ

>961
俺が使ったことのあるのはCake, CodeIgniter, Piece_Rightだけど、
その程度だったら問題ないし、追加の検証メソッドもサポートしてる。

しかし、やはりコード共用をやるなら、最終的にはコード生成に落ち着くような気がする。
結果的にその方が楽だと思う（例として挙がっているGWTもそういうことだし）。
後は、「実際にやってみて」としかいいようがない。

というか、それならJavascriptでサーバサイドできるよね
PHPとして動くようなJavascriptを書けばいいんでしょ？

それはともかく、同じECMAScript系だとFlex/ColdFusionもある
ActionScriptのフレームワークも揃いつつあるし、
ECMAScriptでサーバサイド・モジュールというのは十分現実的

>>889は今すぐJaxerでググレ。
お望みのものがあるから。

> というか、それならJavascriptでサーバサイドできるよね
> PHPとして動くようなJavascriptを書けばいいんでしょ？

なかなか難しいことを言ってるな。
JavaScriptの場合、オブジェクト指向がデフォだから、
array.push("1"); とか str.length とか良くある関数が使えない。
また、PHPの制約により、＄から始まる変数名じゃないといけないし。

Jaxerってこの間ベータ版が出たばかりのあれ？

【従来のプログラミング作業】
サーバーサイド＝PHPでプログラミング…(1)
クライアントサイド＝JavaScriptでプログラミング…(2)

【php.jsを使ったプログラミング作業】
サーバーサイド＝PHPでプログラミング…(3)
クライアントサイド＝PHPでプログラミングしたコード(3)をphp.jsで動かす。…(4)

(4)php.jsを使うことによって、(2)の手間が省けるという話ですか？
＝バリデータくらいなら作れるのではないか？と。

PHPがJavaScriptの代替になるか？
＝php.jsをテストしてみて、どの程度PHPのコードが動くものか確認しなければなりませんね。

なんだ。PHP.jsを使えば、PHPの一部の関数が、JavaScriptのコード内でも使えるようになりますよ、という話じゃん。
単なる関数名のラッパーか？

php.js の検索結果 約 770,000 件
http://www.google.co.jp/search?q=php.js

PHPで使える便利関数をJavaScriptでも使えるようにする「php.js」 2008年02月05日
http://phpspot.org/blog/archives/2008/02/phpjavascriptph.html
>php.js をインクルードすれば、次のPHP関数と同名かつ同機能を使うことが出来ます。
>JavaScriptに慣れ親しみたいと思っているPHPプログラマの方は、これを元に、JavaScriptに移行していくのも手かもしれませんね。

PHPで書いたバリデーターに、PHPの関数が入っていても、コピペでJavaScriptで使える。
これを手動ではなくて、自動でやれば、コードジェネレーターを使うみたいに楽ができるよね？という話ですか。
そのコードジェネレーターは、もう誰か作ってくれてるの？

>>933
>半分正解。答えは、PHPとJavaScript。
http://jp.youtube.com/watch?v=yOS4GJf60gw
「はい！ここ、テストに出ま〜す♪」

>>975
http://www.google.co.jp/search?q=Jaxer
Jaxer の検索結果 約 222,000 件

Jaxerのスレはまだないのかな

PHPと連動させるならJSを生成するPHP書いた方がまだまし
JSでPHP関数のクローンを使うという発想が気持ち悪い
PHPは少なくとも「積極的に書きたい言語」ではないし

>>963
一回書こうとしたことあったけど
バリデーションて複数の層と、それなりに密接に関わるから
だんだんそれ自体がミニFW化していくんだよね
コントローラでは判定とaction分岐、
ビューではFormコンポーネントや値、エラーメッセージの生成や管理nado
なかなかキレイにまとめるのはむずかしす

kohanaはまだ早いかなー
気になるのは
ビデオチュートリアルでhello worldなんかを作ってるあたり。
そこはブログっぽいのとか作っとかなきゃダメだろ。
そこここにセンスのなさを感じて
ださいコードや構造になっているんじゃないかと危惧してしまう

http://www.hige-chen.com/hogeron

ヒゲチェンはcakephpで作られてるらしい

kohanaはCodeIgniterベースみたいだから大丈夫じゃない？
しかし、CIの普及も十分とは言えないのに、なぜ派生プロジェクトが…

ci軽くていいんだけどね

pythonなんかはライブラリの読み込みは自分でやるわけだ
phpでもautoloadに頼らず
自分でinclude_once()するのが一番いいんじゃね？

PHPってArrayのタイプヒンティングだけあって
StringとかIntがないのって何なの？
頭おかしいの？

それはフレームワークのスレとPHP言語仕様のスレの区別が付かないようなもので、
特におかしいことではありません。

>>989
そもそもarrayのtype hintingすら5.1っつー中途半端なタイミングで入れられたんだ

大絶賛中言語PHPではIntegerのタイプヒンティング入れた日にゃ
初心者がリクエストパラメータそのまま引数に投げて
型が違うよっておこられるんだけどうわーんな惨状を回避するためさ、嘘だけど

実際でもstringとintegerの区別に関しては
何故か寛容なPHPだからあながち100%嘘でもなさそうなのがPHPの凄い所

あれ？Arrayのタイプヒンティングできたっけ？と思ったら5.1からできるようになったのね

>>991
少し前、ちょうどそんな感じでphp.internalがフレームしてた。（なんかまた再燃してるっぽい）
除算しただけでいつの間にかintがfloatになってた、みたいな罠もあるので
厳密なスカラーのタイプヒンティングは嬉しくないかも。
int, float, 数値文字列まで受け入れる「numeric」なら妥協できるようなやっぱりキモいような。
まあ、外部から来るスカラーはバリデーション通しとけってことで。

型が割とファジーだからなんとなくでも通るけど
ハマっちゃうと慣れてない人は良く分からないだろうな
そういう意味ではちょっとでも型違うとエラーになる方が
分かりやすいしハマりにくい
さすがMatzにDISられる言語だけある

あれ？rubyってタイプヒンティングできたっけ？

rubyだとraiseとkind_of?でチェックするとか。
そもそもruby界隈だと型チェックでduck typing殺す意義が疑問視されそうだ

$ php -a
でpythonみたいに対話的に使えるの初めて知った
Ruby脂肪ｗｗｗ

PHPでCとPerlとJavaとPythonとRubyとJavaScriptの関数が使えるライブラリ作って
クライアントサイドのJavaScriptでも動くようにすればPHP最強。

関数だけかよw　そいつぁ凶悪だ

> $sosuu = array(2, 3, 5, 7);
> 　for($i=1; $i<10; $i++) {
> 　　if(in_array($i, $sosuu)) {
> 　　　foo($i);
> 　　}
> }

へぇ。これってJavaScriptとしても実行できるのか。
言われてみればわかるけど、目からうろこ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。