何でしょーね、上の PDF でも人を食ったようなテンプレートエンジンがありますが、PHP は元々埋込型なので要らないっちゃぁ要らないですよ。ただかゆいところに手が届かずにそれを求めてテンプレートエンジンを使っています。というかテンプレートエンジンを試すうちに規模の大きい開発ではそちらを選択するようになってきた、とか。
ロジックとプレゼンテーションを別ファイルにしたい、その場合 include でも行けるけど $template->assign.. のようにロジックの側で「何をしているのか」を明確にした文脈のある処理を記述する事が出来る、プレゼンテーションの変更無しにある程度ロジック側で対処出来る事が増える辺りが嬉しいのかも。そこで俺ルールを使うよりは Smarty のようにリソース/採用例の多いテンプレートエンヂンを選択します。
ちなみに今のテンプレートエンジンにはまだまだ不満があります。速度面と仕様面で、速度面は Smarty のようにある程度仕様が固まった所で C で書き直すか、PECL に出す手があります。仕様面については、、自分自身が「こうして欲しい」という要望を持っていてどのエンジンも不満だったり、、もっとデザイナーの側に使いやすく進化出来ます。
デザイン屋の技術力 (スコア:2, すばらしい洞察)
プレゼンテーションとロジックの分業ってのは、絵を作る側
にロジック側に依存した、その言語のタグを埋め込んで
貰うわけだが、はたして今のプレゼンテーション側の作成者に
それが出来ているの(技術力があるか)かが疑問。
結局、紙芝居だけ貰って後はロジック開発者側が、
HTMLにタグを埋め込んでいくと言うの未だに多いのでは
無いでしょうか・・。
(私の周りの環境だけか?)
分業が完全に出来れば生産性もあがるとは思うが、
それってデザイン屋が知っている言語と、
ロジック屋が知っている言語とがマッチして
居なければならないわけですが、貴方(皆さん)の所は
どうですか? 旨くかみ合っていますか?
Re:デザイン屋の技術力 (スコア:1)
一般のGUIアプリケーションでも、ロジックとプレゼンテーションを分離して考えられない技術者が大勢います。というか、UIとロジックという分け方の概念が乏しくて、技術者同士ですら画面イメージのみで機能の説明をしてる事の方が圧倒的に多いのでは?
どの職場に行っても、知識&経験不足というより、目を向ける方向や努力の仕方などの根本的な思想が技術者に不向きな人ばかり。
どうしてこうなってしまったんだろう。
Re:デザイン屋の技術力 (スコア:0)
でも雨後の筍の様に、似た様な概念がさも新しいと言われてもなぁ‥と
思っている方も多いのでは?と、ひとつ提案。
知ってなきゃならない技術って、それ人間が知ってなきゃならないものか?とリストアップしてみたら
Re:デザイン屋の技術力 (スコア:1)
その辺の更新が遅い人に対しては、例えば Dreamweaver + Smarty プラグインのようなツールが代替えになってくれると思います。
まぁ Smarty が大規模とかいう今回のストーリーに合っているかどうかはおいといて。
ちょっと背伸びして手が届く現実という所で Movabletype/2ch-blog ライクなテンプレート型の HTML と CSS だと思っているのですがどうでしょう。
Re:デザイン屋の技術力 (スコア:1)
>HTMLにタグを埋め込んでいくと言うの未だに多いのでは
>無いでしょうか・・。
ウチは逆ですね。
開発者がごくごく簡単なHTMLファイルを作成し(もちろんタグつき)、
それをデザイナーに渡して絵をつけたり色つけたりしてもらいます。
そのとき、「このタグはさわらないでね」とお願いします。
もちろんデザイナーがタグを削除してしまったりすることもあるけど、
その頻度は多くないし、タグさえさわってくれなければデザイナーに
いくらでもHTMLファイルを触ってもらって構わないので、この方法で
落ち着いています。
あと、デザイナーさんもばかじゃないので、タグとかテンプレートとか
教えてあげれば、ちゃんと理解してくれますよ。
というか、JavaScriptのようがよっぽど難しいんですけど。
JavaScriptが理解できるデザイナーなら、タグなんか楽勝ですよ。
ただし、Strutsのカスタムタグはデザイナーさんに不人気です。
<html:input>なんてタグ、ブラウザで表示できないんだもん。
これだけは、<input>に変更してデザイナーに渡し、返してもらったら
開発者サイドで<html:input>に変更しなおしていました。
だから、Strutsは嫌い。
Re:デザイン屋の技術力 (スコア:1)
>開発者がごくごく簡単なHTMLファイルを作成し(もちろんタグつき)、
>それをデザイナーに渡して絵をつけたり色つけたりしてもらいます。
>そのとき、「このタグはさわらないでね」とお願いします。
うちも基本的にこれです。最初はデザインさんが作ったHTMLに
タグを埋め込んで作ってたのですが、2,3度デザイン変更で
難儀したのでこの方法に切り替えました。
今では画面定義とフォーム定義と遷移定義をしたらHTMLから
遷移制御からセッション管理まで全部コードを自動生成させて
DBアクセスやら細かい処理のコードを書き足して開発してます。
最後にデザイナさんがテンプレートHTMLを綺麗にデザインさせたら完成。
後は定義処理を GUI で作ったら完璧だ(笑)
すらど宴会SNS開放中 [e-meet.jp]
Re:デザイン屋の技術力 (スコア:1)
>それってデザイン屋が知っている言語と、
>ロジック屋が知っている言語とがマッチして
現状のやりかたが、寒いんだと思います。
なんで両者が知っている言語がマッチ「しないとならない」んでしょう?
要するに、両者の領分を切り離せるような仕組みを用意してないから悪いんです。
悪い一例としてJSP。いったんHTMLではないJSPなタグを埋め込んだ瞬間に
それはもうHTMLではなくなり、「デザイン屋が触れるものじゃなくなる」
のは原理的に当然です。
JSPフォーマットは、繰り返し型の開発が出来る筈のない形態に、わざわざ自らなってるんです。
あーっと。使ったことないんですが(^^;、最近幾つかある「テンプレート」というやり方だと
どこまで改善されるものなんでしょうか?
余談:
あとはwebアプリ(動的ページ)に、デザイナーが必要なほどの「くだらねー飾り」が多いってのが、なにか間違ってるよな。
PCとかのGUIアプリを見ろ。そうそう飾りなんか無い。それで問題ねーだろ。
それとも「飾りが無いほうが間違ってる」とでも言うつもりなんだろうか?
まあもともと、「web(htmlとhttp)」で「アプリ」を作ろうってのが、何か間違ってるんだが。
もともとwebってそういうことを全然考慮されてない仕組みじゃん。
そうでなきゃ「戻る」を許す理由が無い。アプリの状態遷移と画面の状態遷移を引き離す手段なんてものがさ。
普通のGUIアプリに(常に)「戻る」ボタンがあるか?
余談2:
あとは逆に、巷(?)のhtmlエディタの柔軟性の無さですね。
htmlを逸脱した部分をどう扱う(無視する)かを、柔軟に設定することが出来るエディタならば、
きっと大丈夫なのでしょうけど、世間で騒がれてるサマを見ると、そういうのが主流ではないのでしょうね。
Re:デザイン屋の技術力 (スコア:0)
(以下略)
悪いんだけど,日本語で書き直してくれるか?
Re:デザイン屋の技術力 (スコア:0)
Re:デザイン屋の技術力 (スコア:0)
「日本語で書き直してくれるか」というより、「日本語の文章を理解する能力に乏しくても理解できるよう書き直していただけますか ?」などと表現したほうが、むしろ実情には近そうですね。
Re:デザイン屋の技術力 (スコア:0)
>HTMLにタグを埋め込んでいくと言うの未だに多いのでは
>無いでしょうか・・。
やはり、上記の手段が一番効率がいいのですかね?
今まで関わったものは、全て紙芝居ありきでした。
Re:デザイン屋の技術力 (スコア:0)
で突然 客からの要望で、デザイン屋がHTMLを変更するのが
ロジック屋にとって最悪。何とかしてほしい。
Re:デザイン屋の技術力 (スコア:1)
入出力項目が決まった段階でデザイン屋は外部CSSと外部JavaScriptのみをさわるってしておくといいのかもしれない
現実的にはそれでも難しいと思うけど
ブラウザのCSS対応状況とかあるし
Re:デザイン屋の技術力 (スコア:1)
デザイン屋も時代の変化に対応出来ないと駄目という事で。
そして、多少の知識があれば扱えるような関数などをロジック屋が用意すればいいのかと。
Re:デザイン屋の技術力 (スコア:0)
テンプレート使うべきでしょうね。
テンプレートでいちばん興味あるのは Ruby の amrita です。
(まだ自分で使ったことはないですが。)
Re:デザイン屋の技術力 (スコア:1)
その仮説でもって作ってみた Web Publisher [narucy.com] というツールなんですけど、やっぱ使いやすいなぁと思ってます。今のところサーバサイドの機能を利用できませんが、HTML ドキュメントの自動生成のためのツールとしては利用できます。
(Ruby/Amritaに興味がありましたら、手前味噌ではございますが使ってみてくださいな。)
Re:デザイン屋の技術力 (スコア:0)
Re:デザイン屋の技術力 (スコア:0)
テンプレートをしっかり使える人はJavaに移っちゃうからね。
PHPって、どうしても素人用の言語ってイメージなんだよね。
確かに生産性は高いけど。
Re:デザイン屋の技術力 (スコア:1)
PHP なら今思い出せるだけで
# 釣り?
Re:デザイン屋の技術力 (スコア:0)
私もusersメーリングリストの傾向を見る限り、その印象が強い。
Re:デザイン屋の技術力 (スコア:1)
FAQ の掘り起こしとか、SQLビルダーやコードジェネレーター、マニュアルを兼ねた便利なツール代わり。もしくはヲチスレの肥やし。
下だけ見ても建設的な事はほとんど見つからないと思うんですけど。
Re:デザイン屋の技術力 (スコア:0)
Re:デザイン屋の技術力 (スコア:0)
といったことは出来ますが
Re:デザイン屋の技術力 (スコア:1)
そんなことはないと思うが。何を根拠にこんなことをいうのだろう。
だいたい、Javaのほうでもテンプレートを使いこなしている人は少ないぞ。
たいがいはVelocityやXMLCじゃなくJSPを使っている。
でもまあ、PHPにはinclude()があるから、わざわざテンプレートライブラリを
用意する必要性がうすいのは確か。
---- view.php -------
<html>
<body>
<h1><?= $title ?></h1>
Hello <?= $user ?>!<br>
</body>
</html>
---- main.php -------
<?php
// メインロジック
$title = 'include sample';
$user = 'world';
// HTMLファイルを表示
include('view.php');
?>
PHPでテンプレートライブラリを使っている人、利点を教えて。
Re:デザイン屋の技術力 (スコア:1)
http://www.php.gr.jp/seminar/20030830/doc/beginner-template.pdf
ちょっと探せばざくざく出てきますよ。
何でしょーね、上の PDF でも人を食ったようなテンプレートエンジンがありますが、PHP は元々埋込型なので要らないっちゃぁ要らないですよ。ただかゆいところに手が届かずにそれを求めてテンプレートエンジンを使っています。というかテンプレートエンジンを試すうちに規模の大きい開発ではそちらを選択するようになってきた、とか。
ロジックとプレゼンテーションを別ファイルにしたい、その場合 include でも行けるけど $template->assign.. のようにロジックの側で「何をしているのか」を明確にした文脈のある処理を記述する事が出来る、プレゼンテーションの変更無しにある程度ロジック側で対処出来る事が増える辺りが嬉しいのかも。そこで俺ルールを使うよりは Smarty のようにリソース/採用例の多いテンプレートエンヂンを選択します。
ちなみに今のテンプレートエンジンにはまだまだ不満があります。速度面と仕様面で、速度面は Smarty のようにある程度仕様が固まった所で C で書き直すか、PECL に出す手があります。仕様面については、、自分自身が「こうして欲しい」という要望を持っていてどのエンジンも不満だったり、、もっとデザイナーの側に使いやすく進化出来ます。
まぁ取り敢えず使ってみましょうよ。
んで要らないと思えば使わなければいい。
「PHP なんだからテンプレートエンジンなんか要らないぢゃん」という意見も言い換えれば数あるテンプレートエンジンの中から最速&手間いらずで使えるデフォのテンプレートを選択しているという風にも取れるワケで。
# へべれけ~~、、文章壊れてたらごめんなさい。
Re:デザイン屋の技術力 (スコア:0)
Template-ITのチュートリアル [php.net]を読み、便利そうに感じました
Re:デザイン屋の技術力 (スコア:1)
え、なんで?そのチュートリアルと同じようにすればいいだけだが。
--- view.php ---
<table>
<?php foreach($data as $name) { ?>
<tr>
<?php foreach($name as $cell) { ?>
<td><?= $cell ?></td>
<?php } ?>
</tr>
<?php ? ?>
</table>
書き方が変わるだけで、やり方の本質は同じだよ。
Re:デザイン屋の技術力 (スコア:1)
-- main.jsp --
$data = array
(
"0" => array("Stig", "Bakken"),
"1" => array("Martin", "Jansen"),
"2" => array("Alexander", "Merz")
);
include('view.php');
Re:デザイン屋の技術力 (スコア:0)
あります。(FORM 周りに制御コードが入ったりします。)
# Dreamweaver とか Dreamweaver とか Dreamweaver とか。
# MX 以降は知らないけど。
したがってこの方法ではデザインとロジックを分離したことになりません。
一人で全部や
Re:デザイン屋の技術力 (スコア:1)
テンプレートだっておなじでしょ。
紹介してくれたTemplate-ITのマニュアルにある例:
<html>
<table border>
<!-- BEGIN row -->
<tr>
<!-- BEGIN cell -->
<td>
{DATA}
</td>
<!-- END cell -->
</tr>
<!-- END row -->
</table>
</html>
いっしょじゃん。
それとも、<?php ... ?>は破壊されるけど<!-- ... -->は破壊されないとでも?
#古いDreamWeaverはそうなのかな。
>あと、view.php の方の ?= な書き方はすでに推奨されません。
これはその通りだね。すんません。便利なもんで、つい。
Re:デザイン屋の技術力 (スコア:0)
それはマニュアルのどこに書かれていますか?
<?= expression ?> は "<? echo expression ?>"のショートカットで
SGMLの処理命令ではありません。
上記はPHPマニュアル「第5章基本的な構文」に書かれています。
また、文字列関数郡のecho関数の説明にも同様のことが書かれています。
Re:デザイン屋の技術力 (スコア:1, 参考になる)
> #古いDreamWeaverはそうなのかな。
まさにそういうことです。
正確には <?php ?> の中が破壊されるわけじゃなくて HTML の中の
form のところに影響が出たりします。
Dreamweaver MX 以降ではちゃんと検証していませんが、少なくとも
4 までで再現しました。
# まぁ十分古いかもしれませんが、MX 以降は不要という考え方も
# けっこうありまして。
Re:デザイン屋の技術力 (スコア:0)
# そのおかげで ML が厨な質問であふれ返ったのは有名ではありませんか?
マニュアルを見ているのなら話は早いです。
現在公開されて
Re:デザイン屋の技術力 (スコア:0)
>しばしば。
ちゃんと別にバージョン管理しておくべきです。
そういう文化にない人を信用してはいけません。
すべて自分のためです。