コンテンツとデザインの分離

コンテンツとデザイン ..

2:名無しさん＠お腹いっぱい。
01/05/27 18:46 PLEgfcrY
外部htmlファイル読み込みで片付くものと思われ。

3:名無しさん＠お腹いっぱい。
01/05/27 19:07 rsikQ/Ns
<%～～%>でいいじゃん

4:名無しさん＠お腹いっぱい。
01/05/28 06:25 QyrSaBKA
テンプレートをつくって、置換するのはどうよ。

<html>
<head>
<title>%%%%TITLE%%%%</title>
</head>

こんな感じのやつで。あとで%%%%TITLE%%%%を変数と置換。
>>2がいうとおり、このテンプレートを外部から読むか、内部に入れるかは自由。

5:名無しさん＠お腹いっぱい。
01/05/28 11:45 /loPusng
XML と　XSL で分ければ？

6:名無しさん＠お腹いっぱい。
01/05/28 13:11 yQtftbTo
おいらは内部派だからprintの嵐大好きだよ

7:名無しさん＠お腹いっぱい。
01/05/28 13:19 XZfJcTNc
PerlのHTML::Templateは？
あれ好きなんだけど。

8:名無しさん＠お腹いっぱい。
01/05/28 14:39 9UeTzpnc
PerlのText::Templateでやってた...
HTML::Templateの方が便利かな?
試してみよっと

9:1
01/05/28 18:15 ucUrq.A6
なるほど、PerlにはHTML::Templateなるものがあるんですね。
これは便利そうです。
#でも、最近はPerl使ってないんだよねぇ。

Javaあたりだとどんな方法があるでしょうか?
JSP + Beanでゴニョゴニョ。なんてまどろっこしい方法なんて誰も使いませんよね(^^;

自分はXMLCに注目しているのですが、HTMLの操作をすべてDOMで行わなければ
ならなかったりで、今ひとつ食指が動きません。

10:1
01/05/28 19:17 ucUrq.A6
あ。PHPだとこんなのあるらしいですよ。

PHP4テンプレートクラスライブラリ
URLﾘﾝｸ(zato.nu)

これもタグ置換型ですね。

11:名無しさん＠お腹いっぱい。
01/05/29 03:46
HTML::Templateって、それ自体がなんか言語っぽくなってて、
なんか新しい言語を覚えなきゃいけない風でやなんだけど、実際どう？
友人が使ってるのをちょっと見ただけだからよくわからんが。

12:名無しさん＠お腹いっぱい。
01/05/29 16:32 pjNjykSQ
JSP でコードと HTML がごちゃごちゃしてきたら拡張タグライブラリ
を作る。

<oresama:valueOf name="foo" />

みたいなの。JSP だと結構うまいこと分離できるよ。多少の知識は
いるけどね。

13:名無しさん＠お腹いっぱい。
01/05/29 18:53 oi4kyUtI
>>11
テンプレートのタグ？それともメソッドの使い方？
どっちにしてもそれほど難しくないよ。

14:名無しさん＠お腹いっぱい。
01/05/29 19:01 99dLOuS2
HTML::Template
URLﾘﾝｸ(search.cpan.org)

15:名無しさん＠お腹いっぱい。
01/05/30 02:43 n7P1SKLk
PerlのHTML::Templateは、コメントタグ形式でも表記できるのが
面白いと思った。
<td>名前</td><td><TMPL_VAR NAME=name></td>は
<td>名前</td><td></td>でもオッケー

16:Ｐマン
01/05/30 03:55 owRJ.xHA
class HTMLClass {

　var $htmldata ;

　function HTMLClass( $htmlfile ) {
　　$htmldata = file( $htmlfile ) ;
　　$this->htmldata = "" ;
　　for( $ii=0; $ii<count( $htmldata ); $ii++ ) {
　　　$this->htmldata .= $htmldata[$ii] ;
　　}
　}

　function output( &$data ) {
　　$str = $this->htmldata ;
　　reset( $data ) ;
　　while( list( $key, $val ) = each( $data ) ) {
　　　$str = ereg_replace( "@" . $key . "@", $val, $str ) ;
　　}
　　echo $str ;
　}
}

サンプルクラス。

$tmp = new HTMLClass( "a.html" ) ;
$repdat["data"] = "hogehoge" ;
$tmp->output( $repdat ) ;

@data@ を hogehoge に置換。もっと短く出来ると思うけど
適当にこんな感じなのはいかがでしょう？

17:名無しさん＠お腹いっぱい。
01/05/30 22:36 aom7mYQI
Dreamweaverのテンプレートは？
編集可能領域だけをPerlから変更するようにして使っているよ。

18:15
01/05/31 09:31 DL2pokUM
>>17
それもいいね。
ファイルを1行ずつ読んで、Dreamweaverのコメントにマッチしたら
置換する、というやり方でしょ？

俺はPerLのHTML::TemplateでつかうHTMLファイルを
.tmplにして、それをDreamweaverで編集してた。
モジュールのインストールがいらないから、そっちの方が良いかも。

ただ、疑問なのは、例えばテンプレート内にあるフォームの中に
データを埋め込むとき。
<input type="text" name="sample" value="ここに埋め込む">

こんな時は、ソース編集でvalueにDreamweaver形式のコメントを
打つの？

19:ちょこら
01/05/31 16:26 zuNYGVLg
>>17
お、俺もそれでやってる。
あと、>>18みたいなケースのときはコメントを置換するようにしてる。

を$hogeに置換すんの。
自分でライブラリ作ったから同じスクリプトを
テンプレートかえるだけで使いまわせていいよ。

20:17
01/05/31 17:10 iOzcc6dM
テンプレートのコメントは利用せず、編集領域内に
{$hogehoge;}と入れて、これを置換している。

あまりCGIが得意じゃないんで、恥ずかしいけど
↓こんな感じ。(藁

$postdata{ "hoge" } = $line[ 1 ];
$postdata{ "hoge2" } = $line[ 2 ];

print insertTemplate( './main2.htm', %postdata );

sub insertTemplate
{
local( $filename, %form ) = @_;
local( @lines, $line );

open( FILE, "< $filename" );
@lines = <FILE>;
close( FILE );

$line = join( '', @lines );

$line =~ s/\{\$(.*?)\}/$form{ $1 }/gs;
$line;
}

21:名無しさん＠お腹いっぱい。
01/06/15 12:53 erdVYa/Y
とりあえず、これ読んどけ
URLﾘﾝｸ(jakarta.apache.org)

22:名無しさん＠お腹いっぱい。
01/06/15 15:11 6nOh67xE
Perl信者はこうじゃなくちゃ！

sub template_expand{
　　　　my($filename) = @_;
　　　　my($text, $trans);
　　　　local $/;
　　　　local *IN;
　　　　local *echo = sub { $trans .= join "", @_; };

　　　　open IN, "< $filename" or return;
　　　　$text = <IN>;

　　　　$text =~ s{<\?perl\s+(.*?)\s*\?>}{ eval($1);$trans }egsm;
　　　　close IN;
　　　　return $text;
}

23:名無しさん
01/06/21 18:42 fZd90uYU
本命はCocoonでしょ、やっぱり。

24:名無しさん＠お腹いっぱい。
01/06/21 18:51

25:sage
01/06/22 16:25 FGxLT2Ws
FastTemplate使え。Perl用とPHP用がある。

26:25
01/06/22 17:03
sage失敗ごめんなさい。↓PHP版の配布サイト
URLﾘﾝｸ(www.thewebmasters.net)

27:名無しさん＠お腹いっぱい。
01/06/22 19:22
XSLTでマルチクライアントなんてほんとにできるんですか？

28:名無しさん＠お腹いっぱい。
01/06/22 22:06 QfivNl3k
このスレッド名、妙な感じがするのは私だけかな～。
デザインとロジックの分離じゃなくて？

29:名無しさん＠お腹いっぱい。
01/06/22 22:36
>このスレッド名、妙な感じがする

ホントだ（ｗ

30:名無しさん＠お腹いっぱい。
01/06/22 22:51 NESmv9PY
>>4の

<html>
<head>
<title>%%%%TITLE%%%%</title>
</head>

の形のだと、HTMLしかわかんない俺とかでもデザインのカスタマイズがしやすい。

31:名無しさん＠お腹いっぱい。
01/06/29 15:03
「プロフェッショナルPHPプログラミング」にうまい使い方が載っていたのでFastTemplate使ってみた。
php4だと配布サイトに載っているパッチをあてないと上手く動かなかったけど。

テンプレートを入れ子にできるので部品化・使い回しできるのがイイ。

32:1
01/06/29 15:51 8ZDmK9dU
>>31
Smartyもいいですよ。
>>10であげたテンプレートクラスが霞んでしまうほどの出来です。
(作者さん失礼…)

URLﾘﾝｸ(www.phpinsider.com)

33:名無しさん＠お腹いっぱい。
01/07/02 01:54 X8cwHu0A
URLﾘﾝｸ(www.linkclub.or.jp)
URLﾘﾝｸ(www.linkclub.or.jp)

この「Perltag」はhtmlファイルにサブルーチンや
変数を直接書くことができます。
「Perltag.pm」。これこそがデザインとロジックの完璧な分離だと
思いますが皆さんはどう思いますか？
※ちなみに作者ではないです。

34:名無しさん＠お腹いっぱい。
01/07/02 02:08 7NP//cxc
> htmlファイルにサブルーチンやhtmlファイルにサブルーチンや

分離？逆じゃない？

35:名無しさん＠お腹いっぱい。
01/07/02 02:17
eperlの方がマシ。
eperl使うならPHPとかJSPで略。

36:名無しさん＠お腹いっぱい。
01/07/02 02:22 GjfjvDNA
>>35
むしろeRubyの方が(以下略

37:名無しさん＠お腹いっぱい。
01/07/02 22:55 1TJMjc3E
>>32
Smarty って仕様でかすぎない？ってあんまり見てないんだけど。
最初、自分で作ろうと思って、いろいろ他のを見たけど
よくよく考えたら、PHP でこれをすると、HTML 内に処理を書けるって
いう言語自体の優位性が無くなってしまうね。

38:1
01/07/03 17:00 0lIoca6w
>>37
Smartyではドキュメントにも書いてある通り、絶対にHTML内には
<?PHPタグは書かないことを前提に設計されてますので、Smartyの
設計者たちにとってはHTML内に処理を書くことのメリットよりも
デメリットの方が大きいと考えたのでしょう。

Smartyでは、HTMLテンプレートの解釈にかかるオーバーヘッドを
減らす為に、HTMLテンプレートをPHPにコンパイル(?)してから実行
しているのですが、面白い仕様ですね。(EnhydraのXMLCと同じ)

39:1
01/07/03 17:05 0lIoca6w
でもこのSmarty、なぜか日本語の情報が見事なまでに皆無です。
だーれも使ってないのかな。

それとも、テンプレートという考え方にはそれほど需要がない?

40:37
01/07/04 01:02
>>39
職場は Servlet のプロジェクト一色でフレームワークや EJB の
ことはみんなスキルがあるが、PHP や Perl のテンプレートの
ことを話したら、最初、JSP + タグライブラリと同じだという意見も
あったが、基本的にテンプレートはWYSWYG で編集できることを
目的としている点で方向性が違うということを言ったら
目から鱗という人間が多かった。

Java でも Jakarta のサブプロジェクトでテンプレートが
あるにはあるみたいだけど、あまり聞かないね。

需要はあると思うけどなぁ。

41:名無しさん＠お腹いっぱい。
01/07/06 18:03
>>37
Enhydra使えばまったく問題ナシ

42:1
01/07/06 20:34 9bX.xTlk
>>41
Enhydraの目玉であるXMLCですが、DOMってすごく煩雑なんですよね。
思想は理解できるのですが、現実とのギャップが埋め切れて無いような
気がします。DODSも然り。

あと、Javaサーブレットの場合は静的コンテンツの扱いが煮え切らない
部分がありますね。(これは自分が慣れてないせいかも)

43:名無しさん＠お腹いっぱい。
01/08/06 01:12 of8Q373o
あげておこう。

44:ナナ萌え(ﾟдﾟ)ｳﾏｰ
01/08/07 00:13
<% ～ %> にASPを書くんじゃなくて
%> ～ <% にHTMLを書くと思ったほうが
ソースが綺麗になるよ☆

45:コメント無しさん
01/08/07 15:45
>>41
@ITの記事に、「デザインとプログラムの分離を果たした開発の例」みたいな
のがあって、実際にそのサイト見てみたら
「凝ったデザイン+ほぼプログラムレス」
「しょぼいデザイン+プログラムたくさん」
っていう感じで、ほんとに分離できてるのか謎だった。

46:名無しさん＠お腹いっぱい。
01/08/07 15:47
ページ中のコードの量にもよると思うが。
っていうか分離してないじゃん。

47:う。
01/08/07 16:01
46>>44ね。

48:ナナ萌え(ﾟдﾟ)ｳﾏｰ
01/08/08 01:10
うん。分離は諦めた（藁
DWの吐くASPのコードはえぐい。
特にDB操作関連、逝ってよし。

49:名無しさん＠お腹いっぱい。
01/08/08 23:50 svrEP0oc
デザインとプログラムの完全分離、実現したよ。

CGIをCで書いて、ちょっとしたテクで出来た。
うちはデザインハウスだから、ASPとか嫌われるんだよね。
デザイナーが全部創りたがるから（ｗ

50:名無しさん＠お腹いっぱい。
01/08/09 00:15
>>49
素人さんいらっしゃーい

51:ナナ萌え(ﾟдﾟ)ｳﾏｰ
01/08/09 01:32
>>49
どんなテク？

52:名無しさん＠お腹いっぱい。
01/08/09 03:49 xE5lKX6Y
知りてぇっ。

53:名無しさん＠お腹いっぱい。
01/08/09 15:40
デザイナーにC言語を覚えさせた、って言うのはどうだろう。

・・・・実際は>>4だと思うが。

54:名無しさん＠お腹いっぱい。
01/08/18 02:38 bwvOb6EE
XSQL ＆アクションハンドラ　+ XSL

javaばんざい！
でもXSLって、結構ややこしーよね。

55:名無しさん＠お腹いっぱい。
01/08/20 12:26 aorICbHM
>>54
っちゅーか激しく汚いよね＞ XSL
なんでマークアップ言語をプログラミング言語にしたがるかなって感じ。

56:名無しさん＠お腹いっぱい。
01/08/22 00:16 sfZGtIL6
URLﾘﾝｸ(www2.will-ltd.co.jp)

こんなもん売るなよ... ダサい上に高すぎ。
どんな会社かと思ったらSPAM送信ツール売ってる会社だったのね。
# ってかこっちも高すぎ（大笑い）

57:名無しさん＠お腹いっぱい。
01/08/23 00:28
>>55
＞なんでマークアップ言語をプログラミング言語にしたがるかなって感じ。
これは意味わかんねーけど、XML加工ってパフォーマンス最悪だよな。
どうやったって遅くなる。
これってハードと回線の発展まつしか解決策はねーのか？

58:55
01/08/23 10:53 696IfwN6
>>57
ゼロからparsesするタイプだと結構そうなりますね。EnhydraとかはDOMツリーをキャッシングして使いまわしてパフォーマンス上の問題を回避しようとしてる。
何度もparseするコストを下げるために、DOMを永続化したりとparse結果を使いまわすことで大分回避できそうな気がする。

なんか昔のRDBMSを見てるみたいだ。確実にガンガン改善されてゆくんだろうけど、XMLを使うってことは富豪プログラミングの極みなのかも。

> これは意味わかんねーけど、
うん、ちょっと判りにくい言い回しかも。単に激しく読みにくいと感じているだけです。慣れていないだけなのかなぁ。

59:名無しさん＠お腹いっぱい。
01/11/30 23:53 wIXh/fr5
つーか、Struts使えば？

60:名無しさん＠お腹いっぱい。
01/11/30 23:59
>>56

UltraDeveloperの方が数段上の機能を持ってるぞ。
ちゃんと研究してんのかな。(W

61:名無しさん＠お腹いっぱい。
01/12/07 19:09
漏れはとりあえずWebObjects使ってる。
Perl->MS-ASP->Servlet&JSP->WebLogic->WebObjectsという流れ(笑)
DB連携は楽チンつーか、極楽つーか、今まで漏れがやってきたことは、いったいなんだったんだろう？

62:名無しさん＠お腹いっぱい。
01/12/25 00:00 NlMRZ7tX
linuxjapanに出てたけど、
このwalrusっていうの使ったことある人いる？
URLﾘﾝｸ(www.brain-tokyo.jp)

なんかけっこうよさげなんだが、このデモがちょっとイタイ。
URLﾘﾝｸ(210.155.146.159)

63:名無しさん＠お腹いっぱい。
01/12/25 00:29
>>62
なかなかｲｲんじゃねぇの？
っていうか、デモはシンプルなほうがいいと思うが。
派手なデモとか、そゆのがいいなら．ＮＥＴとかヤレよ（ワラ

64:名無しさん＠お腹いっぱい。
01/12/25 02:14 rO3objig
>>62
この発想、ｲｲ（・∀・）ね。
ドリームウィーバーみたいなソフトでHTML使う人にとっても
こっちのほうが、HTML::Templateみたいな独自タグよりも使いやすいかなあ？

65:62
01/12/25 10:24 w8XWyZY6
俺も機能はいいと思ってるけど、
デモでゴルゴとか言ってるとちょっとひいちゃうんだよな。

66:名無しさん＠お腹いっぱい。
01/12/25 11:31 qH/nvcoM
HTML::Template は... another htmllint とかだとアウトになるし、
ブラウザでプレビューしてもまともなのにならなかったりするのが欠点。

例) <a href="<tmpl_var var="url">">url</a>

>>62 みたいに、id="..." を使うってのはあたりかも。
でも if とかどうやって実装したらいいんじゃろ。

ロジックの分離って意味では、if は邪道なのかな。

ロジックとデザインの分離っていっても、
デザイン部がプログラムであってもいいわけだよね...?

67:　
01/12/25 12:53
xml吐けばいいじゃん

68:名無しさん＠お腹いっぱい。
01/12/25 13:59 qH/nvcoM
>>67
XSLT かけるデザイナーがいるならね。

69:名無しさん＠お腹いっぱい。
01/12/25 14:45 sJRfrNmi
>66
vanguard_compatibility_mode - 1に設定すると、モジュールは通常の書き方に加えて、%NAME%のような<TMPL_VARS>を見ることを予定します。

70:名無しさん＠お腹いっぱい。
01/12/25 14:54 qH/nvcoM
>>69
%NAME% でも HTML lint は怒るような。
親切なHTMLエディタだったら入力時に % を %25 に変換しちゃうだろうし。

<a href="%URL%">hogehoge</a> -> <a href="%25URL%25">hogehoge</a>

71:名無しさん＠お腹いっぱい。
01/12/25 14:56 rO3objig
>>70
むむ。
filterで[%TMPL_VAR NAME='NAME'%]みたいなのにしてるんだけど、
これも変換されちゃう...?

72:名無しさん＠お腹いっぱい。
01/12/25 15:35 qH/nvcoM
手書きでやるぶんにはなんだっていいけど、
URL には生の % は入れちゃダメっていわれてる以上、lintにかけたら怒られるし、
ユーザが % いれたら %25 にするのはエディタの仕事だよね。
実際そういうことするエディタがあるのかどうかはしらんけど。

&tmpl_hogehoge; とかかってに定義しちゃうとか考えたけど、これも変換されちゃうし...

<a href="$url$">hogehoge</a> とかだと大丈夫?

73:名無しさん＠お腹いっぱい。
01/12/25 16:10
>>68
でも、HTMLの流れからいくと正論でない？
今は違っても視野に入れるべきでは

74:名無しさん＠お腹いっぱい。
01/12/25 16:20 qH/nvcoM
>>73
うーん..

プログラム->XML->XSLT->HTML(+CSS)

ってのが将来像だよね？

75:技術板から出張
01/12/25 18:10 4aLznFCR
Velocityってどう？
URLﾘﾝｸ(jakarta.apache.org)
URLﾘﾝｸ(www.ingrid.org)

76:名無しさん＠お腹いっぱい。
01/12/25 21:48
>>75
いいも悪いも、Model2になってしまうと
決まったBeanから値を引っ張るだけなので、
VelocityだろうがFreemakerだろうが好みでしかないと。

サブレット系で使うにしたら、Turbineと一緒に考えんと
単品ではたいした事できひんよ。
TurbineでIntakeService使えばStrutsみたいな
ちょっとエレガントなフォームのハンドリングはできるけど。

基本的には引っ張り出すモデルで使用するので
「ちょっとした分岐」にSTLのタグ使いたくない場合にいいかと。
うちのクライアントは#ifとかで分岐を書いた方が
わかりやすい、ということでVelocityで作りました。
ただ、基本的にはロジックとプレゼンを分離しないものなので、
複雑なものを制御しようとするとすっごい見づらい。

Ankiaみたいな使い方はアリやと思いますけど。

77:76
01/12/25 21:58
ｽﾏｿ
Anakiaね↑

78:名無しさん＠お腹いっぱい。
01/12/26 00:08 BDPI+m4w
ロジックとデザインを完全に分離するとしたら、
if とか loop ってのは除外すべきなのかな。
ここに表がはいって、ここにはタイトルが入って...
みたいなのがデザイン？
それとも表を構築するのもデザイン側？

79:名無しさん＠お腹いっぱい。
01/12/26 00:11 sJEz3Q/y
>>78
表にどんな内容を動的に組み込むか。。というのがコンテンツ
表のレイアウトそのものがデザイン。ってのはどうよ?

80:名無しさん＠お腹いっぱい。
01/12/26 09:16 FQ1ZqMYK
>>74
> プログラム->XML->XSLT->HTML(+CSS)
>
> ってのが将来像だよね？

その場合、デザイナーの仕事って何なの？
これからはデザイナーはXSLT勉強しろってこと？

81:名無しさん＠お腹いっぱい。
01/12/26 13:10 0snM5bma
>>80
そこは、マーベラスなデザインプログラムを誰か作ってくれることを希望するしか。

今現在だって、他はどうかしらんけど
少なくとも HTML::Template で凝ったことしようとすると、
HTML エディタじゃ破綻しちゃう。

XSLT ってデザインの範疇?

82:名無しさん＠お腹いっぱい。
01/12/26 14:30 k+572McB
っていうことは現状では、
XSLTはプログラマが書くしかないと。
デザイナーが書いたHTMLをバラして
コードのあちこちに埋め込んでいくような方法しかないと。

そんならxml吐くよりHTML直接吐いた方がマシ。

83:名無しさん＠お腹いっぱい。
01/12/26 14:40
「XSLTはデザイン用の言語としても使える」という感じ？

84:名無しさん＠お腹いっぱい。
01/12/26 14:56
実際にXSLT（とXPath）を理解できるデザイナーなら
簡単なSQLとかスキーママッピングぐらい分かりそうなもんだよな。

実際細かいとこ（空白処理とか）も考えるとデザイナーが１から
XSLT書くってことはなかなかなさそうに思う。
で、部分的なXSLTモジュールが増えて管理しきれず破綻すると。
これ最強。

ユニークなソースを複数のマークアップに変換することこそ
XLSTの意義なわけで。
それでいてそこらへんのプログラマが「よーしパパ独自モデル
作っちゃうぞー」なんて言って作ったＸＭＬに普遍性があるわけなく。
まぁ、俺みたいな底辺のWEB屋は
フツーのテンプレートで十分ってこった。

85:名無しさん＠お腹いっぱい。
01/12/27 10:30 T+mNc+4X
XSLTもJSPとかと同じ運命にあるんじゃない?
どんどん構文増やしてプログラマブルになっていく。結局まったく新しい文法覚えなきゃなら
ん分だけJSPなどの方がましという結末。俺はループで表を埋めることだけサポートした単
純な文字列置換テンプレート使ってるけど。

86:名無しさん＠お腹いっぱい。
01/12/30 04:15
XSLT/XSLエディタが出てくるんじゃないの？
動的なデータ変形によるレイアウト変更とかをデザインと見なし、それが
重要かどうかはデザイナの主観だけど（というかそういうツールでは無理。）
そのままxmlをCocoonにStreamに通すとXalanを使った場合と比べて表現の
自由が失われるわけで、要は、その表現が目に見える部分がデザインなのか
データなのか、それともデータをパラメータとしてレイアウト可変があるのか
を判断することが重要。テンプレートを文字置換を行うのは見ていてあまり
カッコよくないから、せめて静的なPageを作成できるWYSWYG-XSLエディタを
作ってCocoon+Servlet+XSLで十分では無いのか。

と言ってみる。

87:名無しさん＠お腹いっぱい。
01/12/30 14:12 neJVFUng
>>86
よく意味がわからんのだけど、XSLエディタを作れっていいたいわけですな。

88:名無しさん＠お腹いっぱい。
01/12/30 17:13
URLﾘﾝｸ(www.mediafusion.co.jp)
\27kだって。
たかいね。

89:名無しさん＠お腹いっぱい。
01/12/31 17:56 7TaOdc8L
コンテンツとデザインとロジックの分離、って方向に修正しよう。

なんか MVC モデルを地で行ってるな...

90:名無しさん＠お腹いっぱい。
01/12/31 18:23
.NETでできるらしいね。どうでもいいけど。

91:名無しさん＠お腹いっぱい。
02/01/01 10:16 2xu8/Vnp
>>66
テンプレートに埋め込んだ状態で正しいHTMLになるんだから
吐き出し結果さえ通れば良いんじゃないの

92:名無しさん＠お腹いっぱい。
02/01/01 19:11 zfxUv0cU
>>91
それだと、正しいHTMLであることを前提にしたツールが使えない。
きっちりした HTML エディタとか、検証ツールとか。

93:名無しさん＠お腹いっぱい。
02/01/05 21:53
WO使え

94:名無しさん＠お腹いっぱい。
02/01/05 22:14
うむ、完全なデザインとロジックの分離ができるのって、WOだけだな。
あとは流行りの寄せ集め。
ただし、WOはいくら良くてもマイナーだ。ﾄﾎﾎ

95:名無しさん＠お腹いっぱい。
02/01/06 05:15
URLﾘﾝｸ(www.w3.org)
ってどうよ？

96:名無しさん＠お腹いっぱい。
02/01/08 03:12
>>94
WO、なんで Mac でしか動かないんジャー。

97:名無しさん＠お腹いっぱい。
02/01/08 04:33
>>96
WebObjectsの稼働環境は下記の通り。

【開発環境】
　Windows2000、Mac OS X

【運用環境】
　Java2 SDK 1.3.x and JDBC2.0ドライバがあれば、一応なんでもOK

98:名無しさん＠お腹いっぱい。
02/01/13 21:25
>>94

Cocoon2ならXML+XSLT+XSPと分離できているがどうよ？

99:名無しさん＠お腹いっぱい
02/01/13 23:34
>>98
WOと平行してXMLベースの開発もやってんだけど、まず開発効率の点で比較にならん。
Cocoon2も、技術的には面白いとは思うので、オモチャとしていじってはみたい。

100:名無しさん＠お腹いっぱい。
02/01/14 07:22
なんにしても、この分野はまだまだこれだってのは出てないよね。

>>98
XSP はんてはじめてきいたよ。
JSP みたいなもんなのかー。

101:名無しさん＠お腹いっぱい。
02/01/14 17:33
>>99

そうなのか。漏れもCocoon2は触り始めたばかりだしWOも知らないから
殿辺がWOと比較したときに差がつくのか氏りたいな。

102:名無しさん＠お腹いっぱい
02/01/14 22:20
>>101
XSP、動的にXML生成してくれるのは興味深い。
でもこれ、XML文書の中にJavaのロジック入れちまうような感じだろ。
基本的にゴリゴリとやる作業多いし、DBとの連携もコードをゴリゴリ書かなきゃならん。
まぁこれはこれでハヤリに沿ってると思うが（ｗ
JSPなんかもそうだけど、めんどくさくない？

WOの場合は、クライアント側に吐かれるのはHTML。
HTMLテンプレート内に、動的なHTMLを生成するタグを組み込むんだ。
基本的なWebオーサリングと、動的なWeb上のオブジェクトを組み込むためのツールがある。
動的にHTML生成するオブジェクトには、一般的なHTML要素に加えて、
繰り返し処理、条件判定付き処理なんかも含まれてる。

DB側は、テーブル構造をリレーション含めてJavaクラスにマッピングしちまうｵﾌﾞｼﾞｪｸﾄを作ってくれる。。
メソッド叩けばDBアクセスするようなソースを自動的に生成してくれる機能もある。
この辺のﾛｼﾞｯｸとWebのｲﾝﾀﾌｪｰｽの接続は、ﾋﾞｼﾞｭｱﾙにできるぞ。
単にDBから条件検索して取得したデータをWebに吐くような処理なら、ほとんどソース書く必要なし。

興味があったら
URLﾘﾝｸ(www.apple.co.jp)
でも見てみれ。

巷のApp鯖やJSP/Servletなんかもあれこれ評価してみたけど、漏れ的には今のところ、
鯖側App作る技術的なら、WOが一番すげぇと思う。ｱﾎﾟｰｼﾞｬﾊﾟｿはクソだが（藁

ﾐｶｶの社内ﾍﾞﾑﾁｬ１号企業（社長は光ﾌｧｲﾊﾞの構造発明した博士）が、WOで作ったｱﾌﾟﾘが、
ｾｶﾞのﾊﾞｰﾁｬﾌｧｲﾀと共に、ｽﾐｿﾆﾔﾝ博物館に展示されてる。
日本製のｿﾌﾄｳｪｱでｽﾐｿﾆﾔﾝに殿堂入りしてるのは、この２作だけだと。

103:名無しさん＠お腹いっぱい。
02/01/15 16:59
>>102

DBの連携はServletでやってXMLを出力させて、Cocoon2のGeneratorに
割り当ててる。OracleのXDKとか使えば簡単にXML生成出来るから。
XSLTとXSPはPresentationの整形に使ってみたりしているので、
JSPと違って面倒くさいとは感じない。漏れは結構感動した。

WOはWebで見てみた。面白いね。正にObjectという感じがして印象はいいね。
ただVとCが綺麗に分離されているようには感じなかった。バインドだけを独立して
メンテナンス出来る仕組みがあるなら大丈夫だと思うけどね。

でも今までWOは知らなかったので、ちょっとずつ調べてみるよ。ありがとう。

104:名無しさん＠お腹いっぱい
02/01/15 20:12
>>103
漏れの説明が全然足りてないと思われ（ｗ
VとCは、結構綺麗に分離されてると思う。

まぁとはいえ、結局WOも繭２+XSLT+XSPも道具であって目的じゃないから、
目的に応じたツールを使えばいいだけだよな。
政治的な理由で理不尽な道具を使わされたりってこともあるけど（ｗ

漏れも知識を広める目的で、繭２あたりもﾍﾞﾑｷｮｰしてみる。

105:名無しさん＠お腹いっぱい。
02/01/16 00:37
>>104

いやいや、漏れがちゃんとドキュメントを読み込んでないだけだ。ｽﾏｿ
でもすごいねWOって日本語ドキュメントが公開されているんだねー。
英語のドキュメントと格闘しているとこういうのは嬉しくなるよ（藁

>まぁとはいえ、結局WOも繭２+XSLT+XSPも道具であって目的じゃないから、
>目的に応じたツールを使えばいいだけだよな。
>政治的な理由で理不尽な道具を使わされたりってこともあるけど（ｗ

禿しく胴衣。漏れもたまたま繭２（っていいなこれ）を氏って感動しただけで
仕事になるかは不明だが、色んな道具を勉強しておかないと目的に合うものが
あっても使えないしと思って触り始めたところだった。WOも勉強してみるよ。

106:名無しさん＠お腹いっぱい。
02/01/18 17:29 yclowW7G
上の方に出てたWalrusっていうのを使うと、
URLﾘﾝｸ(210.155.146.159)
このページが

URLﾘﾝｸ(210.155.146.159)
これだけで表示できるって言うんだけど、本当かな。

107:名無しさん＠お腹いっぱい。
02/02/16 11:32 kVRJZgu9
XMLとXSLTでページを作って、javaかなにかで、HTMLにして吐き出す
って方法を考えてるんだけど、やっぱりデザイナーにはつらいっす。

デザイナーにXSLT覚えさせるんじゃなくて、プログラマーに
デザイン覚えさせた方が、手っ取り早くて確実だと思うよ。

108:名無しさん＠Ｅｍａｃｓ
02/02/16 11:48 xWyhCOfA
107はプログラマとデザイナーどっち?

109:名無しさん＠お腹いっぱい。
02/02/16 12:10 KRm5UaCt
プログラマーとデザイナーは必要とするセンスが全然違うよ。
ひとりで両方やったらどっちも中途半端になると思うけどな。

110:名無しさん＠お腹いっぱい。
02/02/16 12:24 uSHa0cBb
XSLT ってなんか違う気がする。なんか。
デザインしてるっていうよりプログラム書いてるような感覚。
HTML が細切れで現れるあたり、へなちょこ Perl スクリプトと似てる。

どうせクライアントサイドじゃまともに使えないんだし、
それだったら自分の使いやすい言語使って XML を整形したほうがはやそうだ。

111:名無しさん＠お腹いっぱい
02/02/16 13:13
デザイナーが直感的にXSLTを扱えるツールなんて、ムリだろ。
プルグラマーにデザインはやらせられないし。（畑が違うんだよね）

うちとこ、海外本社がXML+XSLTでUI作成するエンジン作ってるけど、
ブラウザに直食わせ＆MS-XML依存という、超破綻システム。
IEでしか表示できず、Webブラウザベースである意味が無い。
いっそVBでいいじゃんと思ってしまう。

112:名無しさん＠お腹いっぱい。
02/02/17 19:54 u6FvlsM9
そういや、普通のプログラムの方の UI ってプログラマが設計してるんだよね。
UI 専門チームでやってるんだろうけど。

そういう意味では、紙じゃなく "Web" のデザイナーって時点で
プログラムぐらい書けなきゃいけないのかもね。
データベース設計とかそういうコアな部分だけプログラマが作るってのはどうだろ。

結局、現在の HTML 周りで完全にコンテンツとデザインを分離出来て、
かつ実用的なシステムは無いってことになっちゃうのかな。

悲しいな。

113:名無しさん＠お腹いっぱい
02/02/17 23:42
>>112
コンテンツとデザインてよりは、UIとロジックを分離という面で、
Webアプリケーションサーバと、その開発環境、ということに限定するなら、
１つだけ存在する。
アップルのWebObjects。
日本ではビジネスとしての環境は劣悪だけどな。アップルJPがダメだから。

114:名無しさん＠お腹いっぱい。
02/02/21 09:04 2RVX4IAG
>>113
前々から興味はあって、WebObjectsスレも見てはいるんですが…
メイン環境が Linux なんで開発環境が動かない。無念。

Zope なんかはどうなんだろう。

115:名無しさん＠お腹いっぱい。
02/02/21 13:44 PWLuAunJ
>>106 のwalrusっていうのもコンテンツとデザインの分離はきれいにできてるぞ。
実績ではWebObjectやZopeに遠くおよばないけどな。
日本人が開発してるからサポートは期待できるかも。

116:名無しさん＠お腹いっぱい
02/02/21 18:02
>>114
Linux用VMwareでも入れれ。もしくは、開発用Win用意して、VNC使うとか（ｗ

>>115
サポートもそうなんだけど、やっぱり運用環境にかかるコストと、
負荷分散、障害復旧の仕組みやコストも重要なんだよね。
負荷分散は、WebObjectsはひじょーに楽。
アプリ側の変更いらないし。

ｱﾎﾟｰのサポートは、まったく期待できないのが鬱。
とはいえ、海外のMLとかでは十分な情報があるから、さほど心配はいらねんだけどね。

117:名無しさん＠お腹いっぱい。
02/02/22 06:47 0Wx4juTv
>>116
負荷分散が楽っていうのは、
１）WEBサーバ---アプリサーバ---DBサーバ　の３台構成が楽にできる
２）１）の各階層をそれぞれ複数マシンで構成できる

のどっち？　

118:名無しさん＠お腹いっぱい
02/02/22 11:19
>>117
もちろん後者。
Web鯖自体は、WOで負荷分散ってわけにはいかないけど、
アプ鯖は、負荷上がってきたら別鯖立てて運用ツールに鯖を登録、
あとは立てた鯖にアプのインスタンスを増やしてあげる設定をするだけ。

DBも、負荷分散ちゅー観点からちとズレるけど、
別々のDBのテーブルを、１つのJavaオブジェクトにラップできちゃう。
OracleとSybaseにDBが分散されてても、まとめて１つのオブジェクトにラップして、
アプは、そのオブジェクトとやりとりするだけ。
驚異。

119:名無しさん＠お腹いっぱい。
02/02/24 00:16 VTvdAz4Q
アプ鯖だけで動かしても1台で足りないってのは、
(1) それだけWOが重いってこと？
(2) WOはそれだけ負荷の高い処理を前提として設計されてるってこと？

大規模で本格的なシステムでは、いつ消えるかわからんものは、いくらモノがよく
ても怖くて使えない。小規模なシステムをパパっと作るような所で使いたいんだ
が、大規模なシステムをターゲットにしてるとしたらちょっとミスマッチかも

120:名無しさん＠お腹いっぱい
02/02/24 00:56
WOは、元々、NeXT時代からあるんです。
金融系で実績ありますよ。元々、大規模なシステム向けでした。まぁ大は小をかねてますね。
一昨年までは、同時アクセス数無制限のライセンスだと、開発版＋運用版で\700万Overでしたし。

とはいえ、別に俺は信者や回しモノでもなんでもないので、あれこれ言う必要もないでしょう。
WOも所詮は道具。目的に応じた道具を選択すればいいだけ。

121:名無しさん＠お腹いっぱい。
02/02/27 20:01 ZOHgWtn/
WebProg 板的には、HTML はデザインに入るって解釈でいいのかな。

122:名無しさん＠お腹いっぱい。
02/02/27 20:05
外に見える部分は全部デザインなんじゃないかな。

123:名無しさん＠お腹いっぱい
02/02/27 21:05
HTMLにロジックやらSQLが埋まってる場合はどうよ？

124:名無しさん＠お腹いっぱい。
02/02/27 22:41 4wH+W7s0
>>123
埋め込まないですむツールを探すのがこのスレの趣旨だろ。
WOやWalrusではそういうことができる。

125:名無しさん＠お腹いっぱい
02/02/28 00:25
Walrusは、実務レベルじゃ使えないな。

126:名無しさん＠お腹いっぱい
02/02/28 00:26
っつーことは、
Perl, PHP, ASP, JSP, ColdFusion等々もダメってことか。

127:名無しさん＠お腹いっぱい。
02/02/28 05:28
>>119
WOはスケーラビリティも売りだったりする。
ノートパソコン1台で何から何までやる最小構成から始まって、
(これでパパっとデモとかやるとけっこう食い付きがいい)
最後はhttpd複数、app鯖複数、DB複数みたいな重厚長大構成まで持っていける。
今だとApacheとCocoon組み合わせた感じとちょっと似てるな。ってもちろんWOの方が古いが。

WO出たての頃はCで書いたcgiとかと比べられて、app鯖重い、とかいぢめられたが、
最近はServletだのなんだので他も重くなってるのであんまり言われなくなった(w

128:名無しさん＠お腹いっぱい。
02/02/28 05:44
Walrusって見てみたけど、ふつうのタグのid属性使ってるのキビシイな。
までもeRubyとかcgi-libよりもイイのは認める。

>>125
そもそもRubyを実務レベルで使わせてもらうのもまだ抵抗アリ。

129:名無しさん＠お腹いっぱい。
02/02/28 07:15 deZVjrVj
Walrus使ってみたけどdreamweaverでテンプレート編集できて、
それがそのまま動的なページになる。
便利な気はするけど、俺もRubyを実務で使うのは怖い。

130:名無しさん＠お腹いっぱい。
02/02/28 07:45 EVItbpbr
>>126
>>1 でその結論はでてるような。

embed 系は注意しないとだめでしょう。
繰り返しと分岐をどうするかだよね。
Walrus の繰り返しは上手くやってるなと思う。

無理に分離しないってのも選択肢だとは思うけど。

>>128
普通の id 属性使ってるとこがよさげじゃない？
独自な要素使ったりするのはエディタと馴染まないだろうし、
別ネームスペースの要素や属性を扱える HTML エディタってしらないし。
って DW すら使ったことないからわからんけど。

131:名無しさん＠お腹いっぱい。
02/02/28 09:45
>>130
> 普通の id 属性使ってるとこがよさげじゃない？

あんまり詳しく見てないんだけど、今までHTMLの編集過程で
id属性を使ってた人はそれをあきらめなきゃいけないのと、
タグで囲まない部品は定義出来なさそうってのが
ちょっとツライ。
あと、コピペしたときにすぐ名前空間衝突起こしそうだよね。

なんか興味出てきたんでMLにでも覇逝ってみるか。

132:仮
02/02/28 20:46 noWCUt+8
>>131
warlus 使って、掲示板作ってます。
URLﾘﾝｸ(210.155.146.159)

idは、<div> や <span> にも付けられるので、タグで囲まない部品
の問題は、ほとんど起きませんよ。

>あと、コピペしたときにすぐ名前空間衝突起こしそうだよね。

これは、私も問題だと思います。NAME属性とも衝突起こしますし。

133:nobodyさん
02/03/03 02:06 Z7la6eJB
こんなの

HTML::DWT - DreamWeaver HTML Template Module
URLﾘﾝｸ(search.cpan.org)

みつけたんだけど、DreamWeaver のテンプレートって
どんなかんじ？　使ったことない...(恥)

134:nobodyさん
02/03/03 06:02
JSP のカスタムタグ作ればきれいに分離ができるじゃん。

135:nobodyさん
02/03/03 14:40 nKi/6AzP
>>134
カスタムタグを扱えるHTMLエディタって何がある？
そのエディタを扱えるデザイナってどれくらいいる？

136:nobodyさん
02/03/03 21:25
>>134
あそ、ここはオーサリングソフト使わなきゃ HTML 組めない人達の
板だったわけね。横槍大変失礼いたしました。

137:nobodyさん
02/03/03 22:36
>>135
何か JSP に恨みでも?
っていうか PHP や ASP 用の HTML エディタってあるの?
デザイナってみんなそれ使ってるの?

138:nobodyさん
02/03/03 22:38
>>136
じゃなくてさ、
オーサリングソフトを使わなきゃHTMLを書けない奴と
一緒に仕事をしなきゃいけない人もいるじゃん。
このスレってそういう人が多いと勝手におもってるけど。

139:nobodyさん
02/03/03 23:00
>>138
じゃこのスレはオーサリングソフトのサポートがない物は論外というわけかね。
いや別に良いんだよ、1のタイトルが目に付いただけのUnix板からの流れ者だから。
話の流れを読んでなかった俺が悪かったということでよろしいな。

140:138
02/03/04 00:06
>>139
や、論外ってわけじゃないけどさ。ひとつの方法には違いないし。
ただJSPのカスタムタグで解決だぁ～ってほど、明るくはなれないのよってだけ。

141:nobodyさん
02/03/04 00:09 cezFKT1+
>>139
デザイナを含む開発でメンテナンスまで含めた*工程*を提示してもらえば、
オーサリングソフトにこだわるつもりはないよ。

デザイナが雛形作成したものに、
プログラマが<%.. >や<? ...>やカスタムタグを追加してページを作ると新規の時はいいが、
デザインの見直しがあった時に、誰が何をいじればいいのかわからない。
XMLやカスタムタグを自由に使える技術力のあるデザイナがいればいいが、
そんな都合のいいやつはいそうにない。
結局、標準HTMLで動的なページを作成できるアプサバ使うしかないと思うが
他にいい手があるだろうか？
喧嘩を売ってるわけじゃなくて、
「流れ者」だから見える所があるかもしれないと思って聞いている。

142:nobodyさん
02/03/04 08:47
とりあえず、場違いなレス付けてすまんかった。
>>136 は半分煽りで入れたんだが、オーサリングソフトでデザインと
コンテンツを分ける方法を本気で話すのが趣旨なら大変悪かった
(おとといから咳が止まらなくてイラついてたな)。

流れの話だが、専門でやってるのは銀行や保険なんかの金融系 Web
サイト。一回の開発で画面数にしておよそ 100～150 くらい (フ
レーム分割された一つ一つの合計) な上、かなりの処理が入るので、
最後までオーサリングソフトでやろうというのは度台無理な話。
まぁ売り物はコンテンツであってデザインではないと言い切れる
世界なので、デザイナが絡むとしても最初のデモ画面作成くらい
かな。どのみち開発者が手書きで HTML を書き直すことになる
(おかげでページデザインのできるシステム屋は付加価値が付く;
専門の人にはかなわんが)。だから HTML が書けないデザイナ
なんてハナから頭になかったし (そもそもそれじゃブラウザ間の
互換を保ったデザインなんてできないと思う)、>>1 を見て普通に
Model-View-Controller の話かと思ったわけ。

まぁ HTML が書けることが大前提だったから、JSP+拡張タグでデザ
インを分離できてこれ以上何が必要? って話だったわけ。

それから XSL はサーバ側にかなりの負荷をかけるので、大き目の
サイトではあまりお奨め出来ない (特に Java で組んである奴)。
ちょっとリクエスト数が上がるとすぐ監視端末が真っ赤になる。

143:nobodyさん
02/03/04 13:40 oVEZs8i8
>>142　貴重な意見thanks
そういうシステムやってる人にこそ聞きたいだけど、
大規模なWEBアプリの開発では、どういう分業が理想的だと思う？
たぶんその規模の開発なら、
役にたってるかどうか別としてコード書かないプロジェクト管理屋がいたり、
DB屋も論理的なモデリングやる奴とパフォーマンス考える奴に分かれてたりするだろ。
WEB回りもこれから専門分野ごとに分化していくべきだと思うのだが、
（部品としてタグライブラリ作る奴とそれを美しく配置するデザイナーとか）
どこでどういう風に分離すべきか、もしアイディアがあったら聞かせてほしい。

144:nobodyさん
02/03/04 19:33
>>143 # インフルエンザ発覚、乱文失礼
ロジックを組む人とデザイナの作業を明確に分けたいならタグライブラリが
最適だろうな (Java 限定の話ですまんけど、俺、他は C++ で CGI くらい
しかやったことないし)。まだオーサリングソフトだけでちょっと込み入った
繰り返しや条件分岐作れるほど技術が枯れていないと感じている (普段テキ
ストエディタしか使わないんで実際のところはよくしらんが)。

プロの Web デザイナがプロジェクトに参加するとしたら、やっぱり
HTML くらいかけなきゃ意味ないとおもう。そうじゃなきゃ「ただの
デザイナ」だよ。互換性や挙動の違いを良く知っている人がいい。
カスタムタグの一覧と使い方を渡して、後のデザインはデザイナに
任せるみたいな (本当は事前にお客さんが決めてんだけど)。そう
じゃないと、結局プログラマがデザイナの作ったページと同じ体裁に
なる HTML を１から組まなきゃいけなくなる。

機能的なタグライブラリがそろうと「横展開」というかなりおいしい
おまけがついてくる。中のロジックはまったく同じでデザインをガラリ
と買えればまるっきり新規開発したように見えるから。中小企業相手の
管理ソフトとかこっそりやってるところあるとおもうよ。

っていうか今日はもうだめっす。

145:nobodyさん
02/03/05 01:14
前に、本当のデザイナ、HTMLもちょっとわかるデザイナ、
HTMLバリバリ書くしcgiもやるがデザインセンスなし男、
ただのJavaプログラマ、って構成でデザイナが紙で持ってくる(良くて
Photoshopファイルとか)デザイン案を、必死にオーサリングツールに
乗せて、それをタグの整合性失われてないかチェックする、という
かなり力技やってた。
思うに、中間に何も入らないってのはおそらく無理だ。
ツールにしろ人にしろ、なにかそこに挟まる。

146:nobodyさん
02/03/05 09:42 YJM7TYzZ
>>145
たぶん新規開発だからまだ力技が通じたんだと思うよ。
（それでも相当苦労しただろうけど）
メンテナンスフェーズに入ってから、
馬鹿なデザイナーと一緒に仕事すること考えると鬱
でもそういう奴のデザインセンスは凄い。
色の使い方ひとつとっても全然違う。
ちょっと絵心のあるプログラマなんかじゃ、とてもたちうちできない。
馬鹿さかげんもたちうちできないけどな。

147:nobodyさん
02/03/05 13:16 2x2AJfUn
うーむ。理想的な方法はまだ無いってことで、
現状では、デザイナーは最低限 HTML の構造ぐらい理解しとけ、
でよろしいかな？

ところで、HTML 読めない Web デザイナーってどれぐらいいるんだろ？
都市伝説だと思いたい。

Strict な HTML じゃない!とかそういうのはまあ置いといて。

148:nobodyさん
02/03/05 13:22
HTMLを書かないやつはいても
読めないやつはいないでしょ。

149:スズキ
02/03/08 11:44 +mT8zTLZ
はじめまして。スズキです。
コンテンツとデザインの分離をコンセプトにBBSのCGIを作ってます。
よかったら見てください。m(_ _)m
URLﾘﾝｸ(www.bluepage.org)

150:nobodyさん
02/03/08 13:17
ほんとに「コンテンツとデザインの分離」がコンセプトならWeb製作板じゃないかなぁ？
ここはどっちかっていうとデザインとロジックの分離のような。

151:nobodyさん
02/03/08 15:48
>>150
禿同。
MVCの三権分立。

152:スズキ
02/03/08 16:02 CkkEnjQA
>>150
たしかに！そのとおりだよね。

「HTMLはHTML、プログラムはプログラムと完全に分離する方法はないものか。」
という部分を読んで、
てっきり、プログラム中にHTMLを書かないCGIに関して話すのかと
誤解してました。

153:nobodyさん
02/03/08 16:16
>>151
Webページはもともと静的なものでは？
[M] → XML
[V] → XSLT＋XSLTFo
[C] → ？？　スクリプト？UA？

154:三級者
02/03/10 22:07
>>144
> 結局プログラマがデザイナの作ったページと同じ体裁に
> なる HTML を１から組まなきゃいけなくなる。

禿。PerlでもHTML::Templateなんてモジュールあるけど
デザイナがカスタムタグ理解してくれないと労力効率は何も変わらん。

155:nobodyさん
02/03/10 23:06 sQ4r0PjT
結局、EnhdraやWalrusのように特殊なタグなしのテンプレートが正解ってことか。
Zopeも最新バージョンでは似たような方向に行くようだし。

156:nobodyさん
02/03/11 22:29
[M] = Database
[V] = HTML ( + JavaScript)
[C] = Server Side Application

157:nobodyさん
02/03/12 00:07
MVCとひとことで言っても、ControllerがViewのすみずみまで
知りつくしてるやつと、Viewがプラガブルなやつを較べると
相当に趣が違う。
C = App Server だけだとその違いを反映していない。
いかにApp鯖にhtmlの面倒を見させないか、というのを
話しているところにMVCの話を持ってきてもピントずれてる
というか、それだけでは意味ないって。

158:1
02/03/12 11:45 kdCuXako
まだ残ってたのですね…

なんか混乱気味なので、スレを立てた者としてどういう意図で立てたスレなのかを
説明しておきます。(激しく今更ですが)

まず、何度か指摘があるようにロジックとHTMLの分離が正しいです。
とりあえず、コンテンツ = プログラムで吐き出す可変部という意味で取って下さい。

MVC云々、アプリケーションサーバとは云々というほど規模の大きい話のつもりは
ありませんでした。そこまで話を広げるなら、プログラム板か情報システム板の方が
適切ですね。

せいぜい
「テンプレートっていうかそんな感じの仕組みでなんかイイのない?」
レベルの話です。

デザイナが書いたHTMLをプログラマレベルでがんがん弄っちゃうような環境と規模
(もしくはデザイナ=プログラマ)で、できればオーサリングソフトと相性がいい仕組み
だと便利だよねえ。程度の話のつもりでした。

以上参考までに。

あ、私はSmartyに落ち着きました。Enhydraと格闘してたのは遠い昔…なんであんな苦労を…

しつこいですが、PHP使ってる人「Smarty」イイですよ。相変わらず日本語の情報は
皆無ですが、テンプレートとしての使いやすさはバツグンです。
URLﾘﾝｸ(www.phpinsider.com)

次ページ