>>299
＞tpl.phpが難しいから学習コストが高いということかな？

少なくともSmartyと比較したら数倍難しいし、
素人のロジックがシステムに混入する恐れがある。
define("DEBUG", 1); とか　$_POST["xxx"] = "debug data!"; とか書かれてたら寒気しない？

＞Smartyで出来る事は理論上すべてPHPで出来る

これは逆じゃないかな。
「symfonyで出来る事は全てPHPで出来る」と言ってるのと同じで、
Smartyは所詮PHPライブラリに過ぎないんだから。

＞ PHPが理解出来ないレベルのへぼデザイナーはbody.phpだけ触らせるしかない
＞「SmartyはわかるけどPHPは触れません」というデザイナーって、結構多いのかな？

仮にPHPが触れるデザイナがいたとしても、
上に書いたようにセキュリティの観点からは、システムに影響を与える権限を与えないのが普通だと思う。
少なくとも外注のデザイナには絶対に触らせたくないよね。

＞tpl.phpは、デザイナーが作るのが理想だが、プログラマーがやっても構わない。

tpl.phpはビューである以上、デザイナが触るべきだと思う。
ロジック的にMVCを分けても、管理体制(担当区分)がわかれていないとエラーが出た時に面倒だから。

そういう意味ではSmartyはその機能性より、
コードの統一性や管理体制に与える恩恵の方が大きいのかもね。

>>300
＞（是非はおいといて）>>278のような事をSmartyで実現したい。
{assign}{capture}{eval}あたりで出来るよ。
コンパイル後のソース見ればわかるけど、assignなんかはコストもほとんど変わらない。

// format.tpl
{assign var="name" value=$name|escape|default:"no name"}
{include file="body.tpl"}

// body.tpl
{$name}

＞MVCで言うと、new Smarty();が書かれるファイルは、
＞モデルでもコントローラでもなく、ビューに属する事になる。

自分はSmarty自体をビューとして考えているかな。
コントローラがビュー(Smarty)を生成し、レスポンスデータを渡す。
ビュー(Smarty)は与えられたレスポンスデータを元に画面を表示する。

↓こんな感じ。
class Controller {
public function action() {
// 実際にはSmarty継承クラスor内包クラスになる
$view = new Smarty();

// 必要な処理をしてビューにレスポンスデータを渡す
$view->setResponse(new Respose(xxxx));

// 整形や表示処理は全てビューにまかせる。
$view->render();
}
}

PHPが書けないデザイナをヘボとか言っちゃう人とは仕事したくないなあ
jspが書けないデザイナもヘボなんだよね？
MovableTypeのテンプレートタグも知らなきゃヘボなのかもしれない
うーん、大変だな

>>298
> PHPは正確にはテンプレートエンジンでは無いんですよ。
そうなんですか？？

> Smartyのテンプレートの中にPHPを直接書く事も出来ますよ。(非推奨ですが)
んんーSmarty内でPHPコードを書くのは本末転倒というか本末転倒ですよね。。

あとカスタムタグ？のサンプルありがとうございます！
http://smarty.incutio.com/?page=foreachgroupというのがおもしろそうでした！

>>304
PHPはプログラミング言語の名称ですよ。

>>303
CSS、HTML、JSあたりを完璧に書けない奴はヘボプログラマなんかねｗ


個人的にはデザイナはPHPとか勉強するヒマあったら、
システムに組み込みやすいスマートなHTMLコーディング技術を学んで欲しいわ。

>>305
そりゃ、そうでしょうとも…！

なるほど、このスレには分業指向の人が多いんだな。

>>301
{php}{/php}でも同様の問題は発生すると思うので、その辺は気にしても仕方ないと思っている。
デザイナーにSSHを使わせないとか、PHPが絶対に動かない環境しか与えないとか、
へぼい人を縛る方向で考えるよりは、へぼくない人と仕事するほうが良いと思ってしまう。

>>302
やっぱり、そうなってしまうよなあ。
上で「それはMVCではない」と言われてから、内心悩んでたんだけど。
Smartyの解説ありがとう。その線で学習コストが等価になれるか検討してみる。

>>303
JavaとかMT(使ってる人いるのか？)のプロジェクトなら、そうだろうね。

>>306
HTML書けません、というプログラマーとは間違っても一緒に仕事しないよ。

というより、Smarty文法がわからないデザイナーと一緒に仕事しないでしょ？
同じことでないの？

>>309
>{php}{/php}でも同様の問題は発生すると思うので、その辺は気にしても仕方ないと思っている。

{php}{/php}タグは禁止に出来ます。

>デザイナーにSSHを使わせないとか、PHPが絶対に動かない環境しか与えないとか、
>へぼい人を縛る方向で考えるよりは、へぼくない人と仕事するほうが良いと思ってしまう。

逆になんで必要の無い権限を与えるの？それによるデメリットは考慮しないの？
まっとうなセキュリティの考え方だったら「必要な権限以外は与えない」のが常識だと思うんだけどね。
最低限の権限で不便させない環境を提供出来ないシステム屋こそへぼい人だと思う。


参考までにいくつか質問させておくれ

　・プロジェクトの人数とか連携手法やらバージョン管理方法は？
　・テンプレートPHPでエラーが出たら誰の責任になるの？
　・テンプレートに使ってるPHP系のライブラリとかは？

>>310
デザイナーに権限を与えたくないなら、HTMLだけを納品させて、
コードレビューとサーバへの設置はプログラマーがやればいいじゃん。

デザイナーにサーバへの書き込み権限を与えた時点で、
（仮にあらゆるコマンドの実行をサーバ上で絶対に行えなくしたとしても）
デザイナーはシステムの正常動作責任を一部負う事になるのは間違いない。
たとえば、必要なパラメタを渡さなかったとか、ファイルを消しちゃったとか。

だから、あらゆる操作をサーバ上で絶対に行えなくすることのメリットは、
デザイナーがサーバを壊さないようにする、という程度に過ぎないので、
それなら優秀で信頼のおけるデザイナーと仕事したほうがいいんじゃないの？　と思う。


質問の答えだけど、製品が完成しなかったらチーム全体の責任。
デザイナー主導の案件でもプログラマー主導の案件でも、
インタフェース定義の必要性は発生し、それは両者（主に主導側）の責任になる。
Smarty単体ではシステムの仕様テストは行えないので、
「言われたとおりのSmartyテンプレートだけ書くからあとは知らないよ」というデザイナーは、
HTMLだけしか書かないデザイナーと大して変わらない。

なので俺はそういうデザイナーとは仕事してないし、
もしデザインを外注する事があっても、Smartyの学習を促す事は無いと思う。

あえて擁するなら、へぼプログラマーと連携する時には、Smartyは役に立ったな。
あれを安直に使えば、嫌でもビューとロジックが分離出来るから。
でも今はフレームワークを使うのが普通なので、そのメリットは感じられなくなった。

超極端な例として、>>310の議論にとって最も良い条件を考える。

・顧客がWebデザインを自分で更新したいと要望している
　実力はへぼかも知れないが、お客様なので無碍にも出来ない
・プログラム開発も初期デザインも業者が行い納品する
・サーバは業者が貸与するので、壊されないように配慮しなければいけない
・ssh権限は与えず、ftpsでテンプレートファイルだけ更新できるようになっている
・プログラムの動作責任は業者が負わないといけない
・テンプレート更新内容のチェックに業者の人的コストは割けないので、
　更新はノーチェックで行い、システムが正常動作しなくなった責任は顧客に負わせなければいけない
・テンプレートにはプログラムから変数を埋め込まなければいけない
・顧客はSmartyの心得と導入への理解がある
・Smartyのうち危険なタグをすべて洗い出し、設定で使用を禁止している
・テンプレートでエラーが出てもセキュリティ的に不適切な出力は行われないよう設定されている

それでも

・パラメタエラー
・クロスサイトスクリプティング

の問題は残り、特に後者はインタフェース側で検出する事が出来ない。
お客様が |escape を書き忘れただけで。
なので>>302の仕組みがあれば、完全に縛ることが可能だろうか、と思った。

でも、ここまで極端な事例でもない限り、デキル人を探した方が早いなぁ。
顧客には任意の静的HTMLを特定箇所にinclude出来る仕組みのみを提供するとか。
Smartyを縛るより、俺俺テンプレートエンジンのほうが早いじゃん、とか。

とにかく難癖つけてSmarty叩きたいのはわかったけど、
結局君がSmarty使いこなせてないだけじゃんｗｗ
100%の対策なんて無いんだから、対策しないって言ってるだけって事に気付けｗｗ

＞デザイナーに権限を与えたくないなら、HTMLだけを納品させて、
＞コードレビューとサーバへの設置はプログラマーがやればいいじゃん

　デザイン修正の度にやるんすか。

＞デザイナーにサーバへの書き込み権限を与えた時点で

　当然、テンプレートディレクトリとシステムディレクトリで権限分けてるし。
　ファイルに関しても基本的にはSVN経由で、本番には手動デプロイですよ。
　消される恐れがあるとわかってて何故権限を与える？ｗ

＞Smarty単体ではシステムの仕様テストは行えないので、

　わぁ、きっと君のところはMVC分けが出来てないんですね＞＜
　フレームワーク使えば大丈夫とか思ってるんですね＞＜

＞・パラメタエラー
＞・クロスサイトスクリプティング
＞の問題は残り、特に後者はインタフェース側で検出する事が出来ない。
＞>>302の仕組みがあれば、完全に縛ることが可能だろうか、と思った。

　default_modifiersやフィルタって知ってます？　

＞Smartyを縛るより、俺俺テンプレートエンジンのほうが早いじゃん、とか。

もうSmarty叩きはいいからさ
その安全で扱いやすい俺俺テンプレートエンジンを見せてよ。
君の主張は前提と具体性がないから水掛け論だよ…。

まさか専門学校生じゃないとは思うけど質問に具体的、箇条書きで答えてくれよ。

・プロジェクトの人数は？
・連携手法は？
・バージョン管理方法は？
・デプロイ方法は？
・使用しているPHPライブラリは？
・使用しているフレームワークは？
・使用している俺俺テンプレートエンジンは？

こんなに活発に意見交換があるのに、
どうしてココは『隔離スレ』なの？

名目はともかくスレ独立してるのはありがたいので別にいいや。

>>313
煽っているように見えて>>311と同じ事を言っているように見える。
なので異論は無い。むしろ、まったくその通りだと思う。

>>314
default_modifiersは初めて知った。
nodefaultsと組み合わせれば、symfonyのescaping strategyに近い所まではいけるな。
escapeはプログラマーの責任でもなくデザイナーの責任でもなく、
フレームワークが基本的に便宜を図る、という解釈をすれば、悪くない思想だと思う。

後半については答えても意味が無いと思うし、
別にSmartyを否定する事が主目的で発言している訳ではないと言っている。

世の中にはSmartyを使うのに明らかに向かない案件もあるし、
そんなシチュエーションをわざわざ取り上げてSmartyを否定しても仕方が無いだろ。

逆に「Smartyを使うならこんな規模や状況やツールに最適だよ」という意見があれば、
それは主張してくれればいいと思う。

>>317
default_modifiersは問題がある(ソースに手を入れれば回避可能だが)から使わないって話なら聞くが
Smartyを3年使ってて知らないってどんだけ・・・

そもそもなんでこのスレにいるん？

>>317
＞世の中にはSmartyを使うのに明らかに向かない案件もあるし、
＞そんなシチュエーションをわざわざ取り上げてSmartyを否定しても仕方が無いだろ。

本当にそう思ってるなら196から出てくる発言はありえないと思うんだよね。

シチュエーションも取り上げずに、否定だけされても納得は出来ないじゃない？
「俺ならこうする」って意見も無しにダメだしされてもなぁ…default_modifiersすら知らないみたいだし、
単にSmartyの事知らないだけですよね？
議論では無く、相手を論破する事が目的になってませんか？
なんでこのスレにいるん？

>>313と>>311が同じに見えるって、どんだけ読解力無いんだお前は…
相反する事言っているのに、なんで>>313に対しては異論唱えないんだ。

simplateのメンテに貢献したほうがマシな気がしてきた。

>>318
そうだっけか。じゃあ使い物にならないから忘れたのかな。
いずれにせよSmarty使ってた頃は、そこまでいじる気自体が無かったな。

>>319
俺ならこうする、という意見も、具体的なコードも書いたし、
Smartyを否定する事が主目的でも無いし、Smartyのわからないところは質問した。
発言する前にきちんと流れを読んでくれ。
直近の議論は294,299,301,309,310,311だ。

>>320
> 当然、テンプレートディレクトリとシステムディレクトリで権限分けてるし。
> ファイルに関しても基本的にはSVN経由で、本番には手動デプロイですよ。
> 消される恐れがあるとわかってて何故権限を与える？ｗ

という意向と>>311との違いは状況判断の部分だけ。
俺は手動デプロイなんていちいちしたくないので、
信頼のおける優秀なデザイナーと仕事をする。
だけど、信頼のおけないデザイナーと仕事せざるを得ないなら、
>>313の言うようにするのもわかる。
前提とか本人の置かれている状況が違うだけなので、特に反論は無い。

それとも、
「デザイナーには完全な制限と束縛を課して徹底的に管理しろ」
というのが一番言いたいことなのかな？
Smartyを使ってデザイナーを檻の中に隔離するんだ、みたいな思想なのかな。

俺が何故このスレに居るのかとよく問われるので、
お言葉に甘えさせて戴き、整理させていただく。

俺が思う結論
・Smarty文法 {$name} のPHP文法 <?=$name?> に対する優位性
　→メソッドチェインはSmarty文法が少し短いが、習得コストに大差は無さそう。
　→short_open_tagを使いたくない/使えない場合はPHP文法が長くなるが同上。
・Smarty関数 {hoge} のPHP関数 hoge() に対する優位性
　→車輪の再発明をする必要が無いのが利点。
　→なので別のライブラリやヘルパーなどでも良い。
・Smartyのdefault_modifiersを使いビューのHTMLを安全にすること。
　→設計と実装は不完全だが、フレームワークに任せるという考え自体は良いかも。
・ビュー用の変数構築とビューのHTMLファイルを分ける意義
　→Smartyで実現するには{assign}{capture}{eval}を使えば可能。
　→デザイナーに変数構築をやらせる前提では二度手間に感じる。
　→プログラマーが変数構築を担当可能な所には意義があると思うし、
　　default_modifiersの不具合をフォローすることも出来そう。
・Smartyはデザイナーがシステムを壊さないよう完全に束縛できるか
　→100%束縛したり管理するのは不可能そう。
　→PHPコード実行の抑止の為にテンプレートエンジンを使うのは一応有効。

何か主張されたのかも知れないと思っていること
・Smartyや他の手段を駆使してデザイナーをシステムから隔離する事自体の意義
　権限とリポジトリの管理と手動デプロイを常に徹底すれ
　→俺は優秀なデザイナーを使うかHTMLで納品させるというアプローチ。
　　手動管理はめんどくさいし、たとえ客でも保守費用払わなかったらやりたくない。

だめだこいつ…芯の通った主張が一つもないから、結局何に結論づけてるのかもわからん。
「…で？」としか言えないわ。

default_modifiers忘れてただけとか言い訳が恥ずかしすぎるｗｗｗ
結局使いこなせてないだけに一票。

「俺の環境ではSmartyが馴染まない」とか、凄くどーでもいい事なんで
こんな所でファビョってないで自作エンジンの制作作業に戻るんだ。

ここは君みたいな優秀なプログラマやデザイナが来ちゃいけない場所なんだ。
な。

>>324
一体どんな環境なら馴染むの？

>>325
使いこなせればどんな環境でも馴染ませられるよ。
出来ないのはヘボプログラマくらいだろうね。

君は何がしたいんだい？
Smartyを使う気がないなら、こんなスレにいる必要無いんじゃないのかな？

PHPにて

for(i=0;i<6;i++){
echo "$_POST[$i]";
}

みたいなことをsmartyでやる場合、

{section name=i loop=5}
{$smarty.post.i}
{/section}

だと受けとれません。

$_POST[i]　としてもだめなようで、
ループしてる回数を、POSTで受けとった配列のキーに割り当てるには
どう書けばいいんでしょうか？

あげます。

書き方くらいちゃんと見なされ

マニュアル見てる？

chown nobody:nobody /var/www/html/smarty/templates_c/
chown 770 /var/www/html/smarty/templates_c/
chown nobody:nobody /var/www/html/smarty/cache/
chown 770 /var/www/html/smarty/cache/

<?php

require_once(SMARTY_DIR . 'Smarty.class.php');

$smarty = new Smarty();

$smarty->template_dir = '/var/www/html/smarty/templates/';
$smarty->compile_dir = '/var/www/html/smarty/templates_c/';
$smarty->config_dir = '/var/www/html/smarty/configs/';
$smarty->cache_dir = '/var/www/html/smarty/cache/';

$smarty->assign('name','Ned');

//$smarty->debugging = true;

$smarty->display('index.tpl');

?>
と持っていったのですが、どうしてエラーがでるのかわかりません。
教えてください

自己解決しました。
疲れました

もしかして、smarty使ってローカルでテストすると、
それが完成したアカツキには、レンタルサーバーにも
smartyをアップロードしないと動かないの？？

そりゃあレンタルサーバーにsmartyがインストールされてるかどうかだろ
されてなきゃ自前でアップロードしろ

>>338
一体何をincludeするつもりなのか

smartyってのはカスタム関数が便利なんだよ
そんで、そのカスタムタグつくったから適当に使ってよ、とクライアントに投げるの。
好き嫌いは有るけど、生phpより見やすいわけね。
OK?

>>338

たいがいのフレームワークはそうなんじゃないの

>>341
テンプレートエンジンの理想型だよな。
PGにもデザイナにも優しい。
Smarty3で速度面が大幅改善されるっぽいので期待している。

>>343
テンプレート側で連想配列を簡単に作れる関数ができるとうれしい。
まあプラグインで作れることは作れるんだが

Pearでカレンダーやメニューを作成してテンプレートに出力させたいんだが
このような場合、みなさんどうしてます？

テンプレート側でphpファイルを読み込んで出力させることは可能なのでしょうか？

これってDjangoみたいなテンプレートの継承ってできないの？

>>348
簡易的なモノなら簡単に作れるから自作すれ。