そこでPECLですよ

一番速いテンプレートエンジン - Blitz - Do You PHP はてな
http://d.hatena.ne.jp/shimooka/20071111/1194764798

一番速いテンプレートエンジンはPHPそのものに決まってるだろ。

PHPそのものだと、構文がテンプレートっぽくない。

BlitzはPHP拡張として作られているから、PHPそのものといえる。
SmartyもPHPそのものに変換されるから、PHPそのものといえる。

ところでPieceFrameworkはフロー定義を書き換えるたびにクッキー消さなきゃならんというガッカリな仕様は直ったのかな？

テンプレートエンジン派ってデザイナにテンプレート書かせてるんだよな？
それ以外にテンプレートエンジン使ってる奴がいたとしたら救いようがないうつけ者だな

>SmartyもPHPそのものに変換されるから、PHPそのものといえる。
これは違うだろ。うぇぶでざいなあが作る段階でPHPじゃないのだから。

>>656
WEBデザイナー兼WEBプログラマーな私はSmartyを使っておりました。
最近はテンプレートは生PHPで充分ということに気付き、原点回帰しました！

よく知らんのだが、「PHPそのもの」って言ってるやつのFWでも、それはあくまで記法だけで、
スコープを確保するためにファイルを読み込んでeval()してそうな気もするんだが、違うのかな。

それとも、グローバルにオブジェクト（や関数）を置いて、それを参照するのを前提にrequireなの？

requireすると、呼び出し場所のローカルスコープで
実行されるので、別にeval()する必要は無かろう。

っていうか、そんなPHPフレームワークあるの?
RoRはerbでevalしてるが。

ZF勉強していて思った。
MVCはいいけど、そのためにいろんな「専用の」クラスの使い方
を覚えなければいけないし、覚えてもZFのみってことは、
別のFWに変更するときや、ZF自体が消滅（ありえない？）するときには、
その資産がチャラになっちまうんじゃないの？
大規模開発に向いている、プログラミングの標準化ができるってのが
ウリだと思うけど、FW乗り換えなんかを考えるとデメリットも大きいよな。
そんなんだったら、自分のシステムに必要なクラスを自分で作って
充実させていったほうがいいのかな．．．．とも思う。
まあ、その維持管理が大変といえば大変だが、資産が消滅することや
方針変更で別のものに作り変えるときでも、ノウハウが残るから、
長期的なスパンでみるとメリットがあるんじゃないのかなあ。


特にシステム開発環境を選択している人、そういう問題点ってどう考えている？

>>661
俺俺FWは、俺しか使えない。
他人が使うと、学習コストがかかる。
ましてや、俺と仕事するときにしか使えない。

その点、ZF等のFWは既に学んでいる人々がいる。
その人たちと共同で仕事ができる。

独りでできるもんっ♪なら俺俺でFA
既に学習した人たちのTips等を利用したり、
共同で作業したいなら、
既存のFWでいいんじゃね？

ZFが無くなったときの心配は、ZFが無くなってからすればいいんじゃないか?
大体、オープンソースなんだからZF自体が消えてもコード資産はまるまる残るだろう。

まぁノウハウって奴を蓄積したいのならべつにどうぞ

俺俺ラッパー書いてそこからZFなり呼び出すようにしたら
ZFが死んでもなんとかなるじゃん

>>662
確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
その内容を整理して文書にすればいいんじゃないのかな。
それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
無い分だけPHPを使える人は多いし、知らない人もちょいと学習すれば
使えるようになる。

>>663
ZFが消滅してもオープンソースだから残るだろう。
でもセキュリティホールや新しい技術は一切入ってこないよねえ。

>>664
ラッパーという手はあるが、実際簡単にいく？

>>665
なんかもう>>661の中で結論決まってる予感。

> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
だからさ、その心配はZFが無くなってからすればいいってこと。
そんなもん心配していまから俺フレームワーク作るわっていうのなら、
セキュリホールだのなんだのはどっちみち全部自分で面倒みるんだろう?

> 確かに俺俺FWは俺しか使えないけど、共通処理をクラス化したときに、
> その内容を整理して文書にすればいいんじゃないのかな。

その文章を読まないといけないだろ？
初めて会った人が、あんたが書いたオレオレ文書を
すでに読んでいるなんてことはまずありえない。

その点ZFなら読んでいることはありえる。

> それ以外は素PHPでいいわけだから、ZFのようにいろいろな制約が
オレオレFWの制約を受けるだろう。

何の制約もないフレームワークがあったとしたら、それは
フレームワークじゃなくて、ただのライブラリだ。

> 知らない人もちょいと学習すれば 使えるようになる。
使えるということと、開発の早さ・楽さは別の話。

> でもセキュリティホールや新しい技術は一切入ってこないよねえ。
オレオレFWは、すでにセキュリティホールや新しい技術は一切入ってこないよねえ。

FW乗り換えたら全てチャラっていう前提がおかしな話
WEBアプリのFW全般に対するノウハウってのもあるし
現に今のFWはほとんどMVCベースなわけで
基本的なコンセプトが大きく変わるわけじゃない

個人的なFWを作って使うのも別に悪くはないと思うけど、
オープンソースで開発されているFWが
どれだけレビューされてテストされた上で
リリースされているかよく考えてみるべき

乗り換えたら全部チャラだし俺俺FWの方がいい、
と安易に考える奴は自惚れてるとしか思えない

FWが変わったら覚えた事が全て無駄になる、ってのは
結局表面的な部分でしかFWを扱えてないわけで
FWに「使われている」プログラマでしかないよ

いきなり俺俺は無謀だな
一回メジャーなFW使ってみてから手を出すならともかく

オレオレFWを公開して普及させようと言うならともかく、自分に必要な仕組みだけ
自分で作るのが、そんなに悪い選択とは思わないけど。

単純にZF死んだら困るから自分で作るよ!っていう理由に納得できないだけだろう。

>>669

FW乗り換えでも、MVCの考え方やノウハウは残るが、
現実的にアプリはすべて書き換え。
数十本ならそうでもないが、1000本単位なら相当な手間。
「FWに使われているプログラマ」はいいけど、現実的に手間を
掛けられないというところをわかってないのは問題。
同じFWに縛られ続けていくのはいいが、消滅しちゃったとき
どうやって資産をメンテしていくのか。
そういう意味でチャラって書いた。

だから　>>665　が書いたようにオープンソースであること
を考えると、そういった問題が解決できそうだ。
また多くの人が使ってこなれている面はメリットだよな。


それで、実際どれだけのモンがFWで構築されてんだろ。
cakePHPなんかも有名だが、ZFが出て乗り換えを考える
人もいるだろうし、どうするんだろ。

zfに乗り換える人なんていないでしょ
ショボfwじゃん

どうやって資産をメンテしていくっていうか、
それは普通にソースツリーをフォークしてメンテするだけだろう?

自分でゼロから作るよりは随分と楽だと思うが。

>>673
採用しているFWが変わったからって
既に出来上がってるアプリをそのFWに
全て書き換えるケースなんてそうそう無いだろ
完全な自社コンテンツでアクティブなものか
コンテンツ自体を総リニューアル時に合わせて移行、くらいなもんで
元から運用してるものは普通そのままメンテだろ？
千本単位とかそれこそ非現実的じゃないか？

たとえばsymfony作られたサイト
世界全体でも1000もないだろｗ

とりあえずDISる
↓
少し釣れる
↓
ツンデレ教えて君

こうするとggrksと言われないんですねわかります

数字おおげさに言い過ぎる
↓
突っ込まれる
↓
雲隠れですねわかります

>>676
なるほど、すべて書き換えないケースもあるな．．．．
しかし、千本単位が非現実的なら、「大規模開発」って
謳っているのはどのくらいの規模なんだろうか。

>>677が書いたように、事実上PHPのFWはまだまだ
浸透していない、PHPでの開発は結局小規模なもののみ
ってことなんかな。

>>680
大規模開発って、ふつうプロジェクト数のことじゃなくて、
ユーザ数とか、高信頼性を確保するために大きいシステムを組むってことだろう?

そんなものは、当然一件ごとに何年もかかることがままあるから、
大規模なプロジェクトを千なんてオーダーで抱えてるとこなんてありえないよ。


ていうか、自分が抱えてもいない数のプロジェクトの事と、
(まだつぶれていない)ZFが潰れることを心配して
自分で作った方がいいと思ったの???

どれもこれも、今となっては、PHP4で書き続ける理由に説得力が伴っていないわな。
もうとっくに殆どの環境はPHP5に移行している。
lib/php内やフレームワークのコードだけがPHP4。
自分で書く時、例えば、varなんて使う機会が無い。
そのせいで、細かく曖昧さを指摘する目に見えないエラーがリクエスト毎に何10何100と出ている。

>>681

>>661 ではないけど、大規模開発って言ったら、コード量をイメージするなぁ。
大規模サイトだと、ユーザ数が多いって意味なのかなぁって感じもするけど。

外部のフレームワークの適用については、例えばバグとかセキュリティホールが
あるからバージョンアップしてくださいって言われても、影響範囲が読めないと
二の足踏むし、かといってそのままってのも気持ち悪いし、自作しても知れてる
程度の使い方しかしないのなら、使いたくないってのは良く分かる。

S2Container.PHP5 を勉強しようとセットアップのページ読んでるんですが、解りづらくないですか？
一番初めに書いてあるS2Container.version.tgzを落としてきたら拡張子が.tgになってるし、
＞S2Container.php と S2ContainerSplAutoLoad.php を require して下さい
って何のファイルに書けばいいのか書いてないし・・・。

>>684
pear installコマンドって、ダウンロードした後、勝手にセットアップまでしてくれんじゃないの？

で、PEARのディレクトリってPHP5を入れた時点でパス通ってて、
ソレを、これから加工と思ってる空のPHPにrequire_onceで例に書いてあるとおりに書けばいいんじゃないの？

違うの？

>>685
個人的に、pearコマンドを使わないインストール方法をきちんと書いてくれないFWは信用できない。
S2Containerは触ったこと無いけど。

最初からPEAR必須ライブラリも把握できるし、必要最低限の設定等がわかっていれば、環境を
変えるときも対処しやすいと思う

>>683
つまり、アップデートのパッチを調べる労力 > 自分で書く+メンテする労力
ならば自分で書いてもいいってことね。で、コード量が少ないなら
書くのもメンテするのもたいした労力はいらないからそれもあり、と。
まぁそういう理由なら納得できる。

個人的にはFWを導入した時点で自分で書く+メンテしてもいいと思える
コード量を越える気がするけど、そこはまぁヒトそれぞれ。


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

Webのページ上でボタン押したり、何かした時の処理は、
全部 Ajax 経由でいいと思う。
何かする度に、フォームの全ての値がサーバに送られて
画面全体がリロードされるのって変すぎる。
で、Ajaxと一体になってるフレームワークって何かありませんか？

>>689
極端な意見ｷﾀｰ
っていうかそれならもうMS製品で作っちゃえよ・・・
その方向で少し間違えると、キーを押したりマウスを動かしたりするたびにリクエストの発生する
糞サイトになるぞｗ

で、そんなFWはこれから大流行するだろうから、しばらくのんびり待ってたら？AIRとかもあるしね

>>690
作ってて違和感あるんだよね。なんだかばかばかしい。
.NETって言われるだろうなと思ったけど、MSに閉じた技術ってのがね。

Ajaxから戻ってきたデータによって、JavaScriptで画面上の
変化部分を更新するとか、ある程度自動でできる仕組みがあると嬉しい。
更新したデータは、セッション変数で保持してればいい。
かと言って、ブラウザにプラグインが必要になるような技術もいやだな。
今のWebと親和性をなるべく保ちながら、より自然な開発がしたい。
もうちょっと真剣に探してみるかな。

>>690
>AIRとかもあるしね
あれは勧めちゃいかんわさ。MSの.net以上の勘違い製品。

どうしてもその手の処理が必要な時は
「ユーザに断ってから」Applet立ち上げれば今時でさえ通じるもんだ
他不要

>>691が感じている違和感がどの辺にあるのかよくわからないけど
サーバサイドはPHPで、クライアントはJavaScriptなりFlash(ActionScript)なりっていうのが
面倒ってこと？

>>691で書いているくらいやりたいことが決まっていれば、例えばW3CとECMAScript標準に
完全準拠の理想フレームワークなら、作ろうと思えば作れるかもね

どのみちデザインのためにHTMLで小細工しなくちゃいけないなら、それがやりにくい様なフォー
ムデータの扱いを強要するFWは結局流行らないだろうと思う
Ajaxを含むJavaScriptやFlashの技術は、まさにクライアント依存の妥協案というか手法というか、
っていう部分なんだから、それをサーバ側の組み方と違うと言って敬遠していては現状何も作れ
ない、とみんなそう思ってるんじゃないかなあ

だから、俺は今日もしこしこ正しいかどうか解らないJavaScriptを書きますよ、と。

>>693
違和感ってのは、>>689に書いた内容です。
画面の一部を変更したい時でも、画面全体に影響があるので、
プログラムがそれを考慮した構造になり、分かりにくいものになってしまいます。
GETとPOSTを分けたりすると、更に分かりにくくなります。
WindowsのGUIプログラミングのような開発ができたらいいなと。
イベントドリブンで感じで。
サーバサイド言語 + JavaScript (Ajax含む) でそういう仕組み
になってるフレームワークがないかなと思ったんですよね。
今の自分の作り方が悪いだけかもしれませんが。

>>694
イベントドリブンって言葉だけに反応すると、
PRADOとか、PHPのフレームワークはイベントドリブンらしいよ。

後、Ajaxだと、AjaxCoreとかってフレームワークがあるみたいだけど、ここら辺組み合わせたらなんかできるのかな。

まあ、HTTPやHTMLはビジネスアプリケーションを実装するために考えられたものじゃないからな。
Windowsフォームのアプリケーションと同じことをウェブに求めるのは無理がある。
凝ったウェブデザイン（というか、普通のエンドユーザ向けウェブサイトで求められるデザイン）を、DOMによるCSSの操作だけでデザイン対応するのは相当無理がある。
そこまで機能性を求められるアプリなら、.ウェブアプリじゃなくてNETのアプリにするのが妥当と思うし、マルチプラットフォームにしたいならJavaでも使えばいいと思う。

>>696
だが不可能ではない。
そして確実に流れはそちらに向かっている。

向かってねー与。

PhotoShopがFirefoxのプラグ印になるといいね。