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)
159:三級者
02/03/13 09:01
154でわかるように、うちはHTML::Template使ってます。
あ、デザイナが理解できないちゅーよりオレの説明が下手なのか。
関係ないがデザイナ連中からColdFusion導入しろ、
とうるさくてかなわん。
160:nobodyさん
02/03/13 19:34
ColdFusionしばらく使ってた。
簡単にサイト作るには、CFMLは確かに便利。
しか～し。
きちんと拡張性も考慮して設計したにも関わらず、後の仕様変更と拡張時に、
デザイナ連中とのコラボレートで地獄を見たよ。
CFに限らず、JSPやASP、PHPなんかでも同じだと思うんだけどね。
デザイナが絡まず、サイトの大幅な仕様変更もなきゃ、いいツールだ。
161:nobodyさん
02/03/13 23:23 LkTLC//k
HTML::Templateおもしろいね。
でも、標準的にどこでも手に入る環境じゃないのが辛いなぁ。
162:nobodyさん
02/03/14 00:11
HTML::Template はプログラマにとっては便利だけど、
デザイナは読みたくもないだろうと思うよ。
163:nobodyさん
02/03/14 01:23 Jx+3VC0E
HTML::Templateは、たしかにどこでもインストールされてい
るわけではないけど、展開して置いておけば（つまり make とか
しなくても使えるよ。）
最近のヤツはいろいろ他のモジュールを必要とするので、1.8とか
をいれるとよいでしょう。
基本的なことは、1.8でもできるし。
164:nobodyさん
02/03/14 07:46 nAmAc5Wh
コールドフュージョンはデザイナがコーディングするためのものです・・・。
165:nobodyさん
02/03/14 15:11
>>164
どこの会社？社名出してよ。
もし契約してるとこなら、打ち切らなきゃ。
デザイナにコーディングさせたオナニーシステムなんて、使い物にならん。
166:nobodyさん
02/03/14 15:46 xs367yVo
>>163
1.8ってまだ公開されているの？
167:nobodyさん
02/03/14 23:19 6NMo0mqW
>>166
公開されているよ
URLﾘﾝｸ(www.cpan.org)
ちなみに、最新は2.5です。Perl5.6必須だけど。
URLﾘﾝｸ(www.cpan.org)
168:nobodyさん
02/03/14 23:33 83vwJ138
>>167
Thx!早速落としたよ。
169:nobodyさん
02/03/15 01:50 sSRdthig
レンタル・サーバだから、そういうの使えない…
Smarty も HTML::templateもよさそうだけど。
何か言い方法ありますかね？
170:nobodyさん
02/03/15 02:04
ホームにインストールしる
171:nobodyさん
02/03/15 02:20 sSRdthig
>>170
あ、それでできるんですか？
Smartyも？
172:nobodyさん
02/03/19 22:42 BqZatu5x
テンプレートエンジン用のデザインのテンプレートがいっぱいあるのってあります?
これみたいにテーマがあって変えられるやつ。
URLﾘﾝｸ(curtisonline.net)
PHP-nukeも使いようによっては、いじれそうだけど。
173:nobodyさん
02/03/25 20:03
>>158
PHPのsafe modeを有効にしながらSmarty使う方法はありませんか？
Smartyはtemplates_c/以下にコンパイル後のファイルを置く訳ですけど、
この際に作られるディレクトリが複数階層にわたるみたいで、
これらがsafe modeの制限に引っかかってしまいます。
174:1
02/03/26 11:05 mzbnXmq6
>>173
URLﾘﾝｸ(marc.theaimsgroup.com)
ここで safe mode で検索かけてみて下さい。
おそらく解決方法があるかと思います。
175:173
02/03/26 16:39
>>174
情報thanx
やはり、解決策としては、
1.Smartyを利用するスクリプトの所有者をhttpdプロセスのUIDに合わせる
2.Smartyを利用するスクリプトがある領域だけsafe modeをOffにする。
3.CGIとして利用して、Apacheのsuexecを利用する。
しか無いみたいですね。
で、不特定多数の利用者が自由にSmartyを利用できるようにするためには、
CGIとしてPHPを動かすしか無い、と。
176:nobodyさん
02/03/26 22:34 0DHHOlhe
PHP SiteManagerってどうよ？
URLﾘﾝｸ(www.roadsend.com)
177:nobodyさん
02/03/27 13:10 xBtxtmDD
>>176
見てみたけど、多言語対応してるみたいだし、テンプレート・エンジンもあるね。
なかなかよさげだけど、誰か使ってないの？
178:nobodyさん
02/03/30 22:47
>> 149
興味があり見に行きましたが、まさか Java script が必須とは (汗
いえ、只の愚痴です。すいません。
179:nobodyさん
02/03/31 06:52
Smartyの英語マニュアル全部読んだのですが、
既存のHTMLファイルを取り込む方法がいまいちわからないです。
180:nobodyさん
02/04/01 04:24 Hzf2fsPp
HTML::Templateってデザインとロジックの分離ができてないよね。
ループとか分岐の指定をする専用タグがある時点でアウトでしょ。
181:nobodyさん
02/04/01 04:31
それにしてもHTML::Templateはかなり使えると思う
182:Dream ★
02/04/01 06:40
>>181
うん、いい感じですね。
コンテンツ大きいとオーバーヘッドがきつそうだけど、アクセスがそんなに
負荷になっていないサーバだと、大丈夫なのかな？
とにかく、面白そうなものを教えて下さって、ありがとう＞All
183:nobodyさん
02/04/01 09:29
HTML::Templateってcgiでしょ？
うちは、/cgi-bin/以下に置かなきゃいけないから、いやん。
184: ◆AngelBlk
02/04/01 11:00
Smartyだけど、青マンモス本にリファレンス載ってるみたい。
誰か買った人います？
どんな感じか教えてほしいのだけど。
会社の帰りにでも、探してみるかなぁ・・・。
185:1
02/04/01 14:08 ALawDKoI
>>179
取り込むというと…?
{include file='includefile'}
みたいなことは出来ますけど、たぶん違いますよね。
>>184
マンモス本ってなんですか?? オライリー?
186:nobodyさん
02/04/01 16:33 SClNMZpg
>>185
お返事ありがとうございます。
ただ、現在のページをheder,left,bottomに分けて、そこをテンプレートにして管理したいだけなんですけど
Smartyだとやり方がよくわからなくて…。
187:1
02/04/01 17:11 ALawDKoI
>>186
別のファイルが差し込めればいいんですよね。
---- header.html ----
<h1>へっだー</h1>
---------------------
というヘッダー部があるとして、本文のテンプレート(例えばbody.html)に
---- body.html ----
<html>
～ 省略 ～
<body>
{include file='header.html'}
～ 本文 ～
</body>
</html>
-------------------
とすることで、body.htmlにheader.htmlが差し込まれた形で処理されます。
188:nobodyさん
02/04/01 18:34 eCkZiEpB
青マンモス本でSmartyがどんなふうに取り上げられてるの？（近くで売ってないので）
Smartyのマニュアル和訳とかしてwebにあげようと思ってたんだけどなー(´д｀；)7割はｵﾜｯﾀ
189:nobodyさん
02/04/01 18:55
>>188
おーすげえ。まんせー。
190:nobodyさん
02/04/01 19:41 jOov+muS
>>187
お返事ありがとうございます。
index.tplにheader.html等組み込むのはいいのですが、コンテンツを
各webページごとに入れ込む場合、テンプレートの方でなく、index.phpなどの方に入れ込むと思うのですが、その入れ込み方がマニュアルを見ても乗ってないというか、わからないというか...
例えば、index.phpのコンテンツ部分をindex.txtから取り込むには、ファイルを読んで、それを$contentsに入れ込んで、$smartyに渡すということをすればいいのでしょうか?...自分でもよくわからないです...
>>188
すごいですね。upしたら教えて下さい。
というか、途中でも、upすれば、リバイズとか助けられると思いますよ。
191: ◆AngelBlk
02/04/01 23:16
>185
オライリーではなく。
PHP徹底攻略：実戦編のこと。
URLﾘﾝｸ(books.softbank.co.jp)
これ。
昼休みに買いに行ったら、店が休みだった・・・（涙
>188
目次みたら、リファレンスのところにSmartyって書いてあったよ。
でも、使い方和訳したならきぼーん。
192: ◆AngelBlk
02/04/01 23:27
書き忘れ。
PHPusersMLより青マンモス本の目次。
URLﾘﾝｸ(www.geocities.jp)
多分、明日買ってきます。
193:nobodyさん
02/04/02 06:01
>>190
話はずれるけど、DBからデータを取ってくるのとCVSなtextファイルからデータ取ってくるのどっちの
方が早いのかね？
194:1
02/04/02 09:55 IYI5YDp3
>>190
うーん、それはSmartyというよりPHPでゴリゴリ書くしかないですね。
---- main.html ----
<html>
<body>
{$contents}
</body>
</html>
-------------------
というテンプレートに
---- index.php ----
require("Smarty.class.php");
$smarty = new Smarty;
$fp = fopen("index.txt","r");
$smarty->assign("contents", fread($fp, filesize("index.txt"));
fclose ($fp);
$smarty->display("main.html");
-------------------
こんなかんじなのかな?
すいません、>>190さんの言いたいことがよくわかってないかもです。
>>188
ぜひUPして下さい。日本語のSmartyサイトが1件も検索に引っ掛かってこない現状
は寂しいです。
195:__
02/04/02 10:01 hdBuJcW1
.NETつかえば？
196:nobodyさん
02/04/02 10:11 6uavVYCo
>>194
わざわざコードまでありがとうございます。
これを参考に自分で書いてみます。
Smartyは、もうちょっとwebサイトに色々情報が欲しいなぁ～と思いました。
MLの過去ログを見ても、やっぱりサンプルが足りないと言う人や、Smartyを使っているサイトを
教えてという人や、themeを作ろうなんて人もいました。
色々プラグインなんかもシェアできたら、便利そうですよね？
現在新しいサイトをオープンしているようですね。
URLﾘﾝｸ(smarty.php.net)
日本のサイトを作ったらまずいのかな？
197: ◆AngelBlk
02/04/02 11:34
>196
別にまずいってことは無いのでは？
個人のそう言う動きを制約するものは無いはず。
198: ◆AngelBlk
02/04/02 12:55 QT5eEfAO
昼休みに青マンモス買ってきました。
Smartyは完全にリファレンスだけ（公開メソッドとか関数の一覧）
なんで、>188さんがマニュアル作ってくれたなら是非ともアップしてほしい。
199: ◆AngelBlk
02/04/02 17:35
って連続かきこスマソ。
青マンモス本ですが
Part-1 Chapter-5 Templates
ってのがSmartyの事でした。
でも、本を買えない人もいるし
やっぱ>188さんには公開してほしいですね。
200:nobodyさん
02/04/02 22:29
私も青マンモス本買って来ました。
マニュアルには書いていないことが書いてありわかりやすくて良さそうです。
＃まだちゃんと読んでいない。
が、マニュアルのように詳しくないので、どちらも必要と思われます。
>>188さん、私もきぼーんです。
201:188
02/04/02 23:11 R/mGCLUs
>>190
こういう感じの事かなぁ、と憶測で。
例えば、左側にメニューがあって右側その内容が表示されるサイトの場合ですが、
まず全体のテンプレートを用意しておいて、
<!--body.tpl-->
{include file="header.tpl"}
<table>
<tr><td>
{include file="$left"}
</td><td>
{include file="$right"}
</td></tr>
</table>
{include file="footer.tpl"}
202:188
02/04/02 23:12 R/mGCLUs
続き。
PHPスクリプトからは、
// index.php
$smarty->assign("left","menu.tpl");
$smarty->assign("right","welcome.tpl");
$smarty->display("body.tpl","welcome");
として最初のwelcomeページを表示し、
次にメニューをクリック、そのリンク先がnews.phpだった場合
// news.php
$smarty->assign("left","menu.tpl");
$smarty->assign("right","news.tpl");
$smarty->display("body.tpl","news");
というような事が出来ます。
Smartyのキャッシュを有効にしてると、同じテンプレート(body.tpl)からは
キャッシュファイルは1つしか生成されないので、news.phpに行っても
最初に表示されたwelcomeページがまた表示されてしまうんですが、
displayメソッドの第2引数に各ページでユニークなキャッシュIDを渡す事でそれを防げます。
えーと、マニュアルは、もともと公開する目的で作ってたんで。
もうちょっとしたら公開できると思います。
203:nobodyさん
02/04/02 23:22 6uavVYCo
>>201
>>202
すごい！こんなことができるんですね。ありがとうございます。
この方法だと、ファイルオープンの処理をしなくてもOKですねぇ。
ちょっと、コーディングして試してみます！
マニュアル公開、嬉しいです。
#ちなみに、翻訳ソフトに通してから、修正ですか？一つ一つ翻訳ですか？
204:nobodyさん
02/04/03 03:36 w0fKgoFn
>>202さんの通りにやったらできましたー。感謝、感謝。
すごいなsmartyって。
205:1
02/04/03 08:25 n4eJMQ5/
>>201 = 188
うは、そんな使い方出来るんですね!
と思ってよくマニュアル見たらしっかり書いてありましたね。
>>196さんゴメソ。
そろそろスレ違いな感もなきにしもあらずなのでSmartyでスレッド立てようと
思いますがいかがでしょう?
206:nobodyさん
02/04/03 09:52
>>205
べつにいいんじゃない？ネタ引っ張っていけるんだったら立てても。
207:nobodyさん
02/04/03 14:54
>>205 AAの準備は万端です
208:nobodyさん
02/04/03 15:50 w0fKgoFn
>>205
こういう使い方マニュアルに書いてありました？
4回位読んだのになぁ。でも、1さんいろいろありがとう。
CSVなテキストからデータを読むには
>>194なやり方が必要と思われるので。
スレ立て賛成です。
Smarty使いが増えるかも。
Smarty使いって、スマーターって言うのかな？
あー、いやらしい。
209:nobody
02/04/04 15:43
Smartyの話題がでてるけど、、、
漏れも1年ちょい前から同じようなコンセプトで
PHP用のテンプレートクラスを作っています。
Smartyとの共通点は、いったんテンプレートファイルを
PHPスクリプトに変換することです。
Smartyとの違いはHTML側に書く特殊タグの種類を4種類に
限定することによって、デザイナーでもテンプレートを
書けるということです。
最近いろんなかたの助言によってとても安定＆高速になってきました。
URLﾘﾝｸ(hoover.ktplan.ne.jp)
210:nobodyさん
02/04/04 18:35
>>209
かなり良さそうです。特にドキュメントビルダーのあたり。
Smartyとのスピード比較きぼーん。
211:nobody
02/04/04 18:44
>>210
現在、ベンチマーク比較のページを執筆中ですが、
単純なHello world 程度の小規模のサンプルで実験した場合、
僕のほうがSmartyの約3倍速いです。
（機能は僕のクラスのほうがシンプルなのですが。）
また、かの有名なFast Templateよりも1.5倍ぐらい速いです。
ベンチマークのページを書き終えたら、また直リンします。
212:nobodyさん
02/04/04 23:43
>>211
返事はやいですね。ベンチすごいですね。大規模はどなんでしょ？
シンプルでとっつきやすいですし、なにより日本語なのがうれしいですね。
213:nobody
02/04/05 01:36
大規模なテストは、それぞれのテンプレートをバリバリ
使いこなしている人に最適化されたスクリプトを書いてもらわないと
テストの意味がないので、僕独りでは難しいです。
ただし、僕の作ったクラスにもSmartyのようにテンプレートを
パースした結果をファイルに保存して2回目以降はパースしないで
済むオプション機能を実装しています。
ので、その機能を使えば大きなテンプレートでも問題なく使える
とは思います。
214:nobodyさん
02/04/05 08:17
>>213
大規模の比較は、一人では難しいとのことですが、開発はどのように行っているのですか?
webページを見ましたが、開発への参加募集はしていますか？
独自MLもないように見えます。PHP-users-MLベースで開発しているのでしょうか？
215:nobody
02/04/07 21:56
コーディングは現在僕独り。その他、パッチを変えてくれる人もいますｌ
また、罫線案をメールや掲示板でいただきます。
みなさまの協力の上に原始的な手法でかいはつをすすめているところです。
216:nobodyさん
02/04/07 22:27 hI7aRZHK
デザインはFLASHで、テキストはアクションスクリプト、CGI、PHPでという分け方もありだと思いますが、どうでしょうか？
利用されている頻度は少ないですが。
217:nobodyさん
02/04/08 02:53 jy9kIRbx
新しいFlash、悪くないと思うが。
今度クライアントに提案するシステム（イントラだが）は、
インターフェイスを、全面的にFlashで行こうかと。
218:nobody
02/04/08 03:39
自作テンプレートクラス@PHP版のベンチマークテストを取ってみました。
Smarty,Fast Templateよりもはやいです。
URLﾘﾝｸ(hoover.ktplan.ne.jp)
219:nobodyさん
02/04/08 04:12
>>218
ベンチマーク・テストありがとうございます！
すごいですね、これ。僕もsmartyでサイト作っているところなんで、HTMLテンプレート版も
作ってベンチマークしてみよっかなぁ。
220:nobodyさん
02/04/08 04:42
>>218
typoが多いよ・・・
221:nobodyさん
02/04/08 04:50 a4RoISwK
PHPってHTMLに直接コードを書けるのが売りなのに（売りとは思わんが）、
わざわざ言語使用に反して分ける時点でもう破綻しちゃってるよＮＥ！
222:nobodyさん
02/04/08 05:47
PHPは手段であって目的ではないのだから別に破綻していることにはならんでしょう。
223:nobodyさん
02/04/08 06:58
言語仕様を使い切らないと無意味と考えるのは痛いな。
224: ◆AngelBlk
02/04/08 08:42
確かに、初期段階では221が言ってるように
HTMLにコードかけるってことが売りだったかもしれないけど
今となってはそれもどうでもいいような気が。
実際自分がコーディングしてて思うけど
やっぱりデザイン部分はわかれていたほうがやりやすいし。
まあ、適材適所。
当たり前のことだけど、使い分け出来ないやつは氏ってことで。
225:nobodyさん
02/04/08 13:27 +OQca7Zg
>>218
うーん、今のご時世で速さを売りしても余り意味がないような気が…
どのみち機能が増えてエンジン自体が肥大していけば重くなるのは避けられないから
開発途上の今の状態でどれだけ速くても「うん、まあ当然だよね」としか言えない。
そもそもサーバサイドの処理が重くて悩むのって、PHP使ってる向きには少ないと思う。
それよかコードの記述性と可読性が他のテンプレートエンジンと比べてどう優れてるのか
教えて欲しい。
サイトをざっと見た限りでは、Smartyのサブセットの域を出てないように思う。
226:nobody
02/04/09 01:53
>>220
ごめんなさい、いま直しました。
文法のほうについては責任をもてません。MS WORDで単語チェックした
だけです。
>>225
テンプレートの書きやすさが自分のものの特徴と思います。
プログラミングを知らないデザイナーにも5分程度で教える
ことができます。
227:nobodyさん
02/04/09 07:16 GMnXZpQb
age
228:nobody
02/04/09 10:26
さらにバージョンアップして高速になったYO!
URLﾘﾝｸ(hoover.ktplan.ne.jp)
229:nobodyさん
02/04/09 11:26
Smartyもそうなんだが、サンプルがないから、とっつきづらい。
実際の運用サイトの雛型とか、携帯での運用の場合のサンプルとかあると
とてもうれし。
230:nobody
02/04/09 12:09
228ですが、、、サンプルとしてどんなものが適当と思われますか？
例のための例をあげてもなかなかわかりにくいだろうし、
実際の現場で使われているものになると中規模すぎて説明が
大変になります。
悩ましいところです。
僕のサイトでのPEARを使ったリスト表示サンプルはどうですか？
URLﾘﾝｸ(hoover.ktplan.ne.jp)
231:188
02/04/09 12:51
>>229
少し前にSmarty-GENERALで、Smartyを使って制作したサイトの
ソースが公開されてました。もしかしたら参考になるかも。
URLﾘﾝｸ(marc.theaimsgroup.com)
232:nobodyさん
02/04/09 13:38
PHPばかりでつまらんのう、そろそろスレの本題に戻してﾎｽｨ
つか、>>228のあからさまな宣伝が鼻につく。宣伝したけりゃ自分でスレ立てれ。
233:188
02/04/09 13:57
>>232
そーいえばここ、PHPスレじゃなかったですね。
やはりそろそろ、「デザインとロジックの分離 with PHP」みたいな
別スレ作って移動しますか？
あ、テンプレートって文字を入れたほうがいいのかも。
どうしましょうか、新スレのタイトル案。
234:nobodyさん
02/04/10 01:30
>>233
テンプレートエンジン(PHP)とか？
話題自体smartyかHTMLテンプレートしかでないから、「smarty と HTMLテンプレート」とか。
デザインとロジックの分離自体あまりしてないような感じだし。
>>232
宣伝でもよいと思われ。それで稼ごうとかでなければ、むしろ歓迎。
235:nobodyさん
02/04/12 11:44
>>234
そろそろ、スレ立てませんか？
236:nobodyさん
02/04/12 12:01 wN+/eHS+
PHP以外で興味がある人が少ないってだけじゃないの？
文句しか言わないでネタ振りもしない>>232に萎え。
237:nobodyさん
02/04/12 12:06
細分化して単発スレばかりになるのもどうかと思うけどな
腐るほどPHP関連のスレあるわけだし
238:nobodyさん
02/04/12 12:56
>237
っていうか、この板相変わらず
人少なそうだしね・・・。
239:nobodyさん
02/04/12 23:35
じゃ、とりあえず、このスレで、テンプレート関係の話をしますか。
「コンテンツとデザインの分離」関係の話は出尽くした感があるし。
240:nobodyさん
02/04/14 21:28
>>231
thanx.
見てみました。さらっと見ましたが、色々なコードがありましたねぇ。
ちょっとどうなってるか、よくわからんので、じっくり見てみます。
241:nobodyさん
02/04/15 01:52
結局、PHPはちょっとしたことには便利なんだけどさ、大規模向きだとツライ。
Perlよりはマシにしろ、メンテしづらいし。
242:nobodyさん
02/04/15 06:31
>>241
そんな時のテンプレ・エンジンじゃないの？
243: ◆AngelBlk
02/04/15 09:59
>241
具体的にどのあたりが？
244:nobodyさん
02/04/24 07:52
>>243
HTMLにプログラム書くところ。
245:nobodyさん
02/05/03 02:55
smarty 2.1 age
246:nobodyさん
02/05/03 15:46
やっと{myfunc}...{/myfunc}みたいなカスタムタグが定義できるようになって
プラグインの幅が広がった感じ。
つーか、2.1.0に対応したほんにゃくマニュアル完成ヽ(´ー`)ﾉ
近日サイトage。(予定)
247:nobodyさん
02/05/04 00:15
>>246
おおー！期待大。ありがたや、ありがたや。
URLﾘﾝｸ(smarty.php.net) 完成しつつあるage.
248:narucy56 ◆wMOjCT4s
02/05/04 11:08 vTPrP0BI
WEBアプリケーションサーバとしてのWALRUS
URLﾘﾝｸ(www.brain-tokyo.jp)
これはよさげ！！
249:nobodyさん
02/05/04 15:27 d0uaPpR2
>>248
それだけ貼られてもよくわからん
どこがどういいのよ
250:nobodyさん
02/05/04 19:22
>>248
ロクにリファレンスも揃ってないのに『どう』いいんだ？
他スレでもあんたのカキコみるけど、名無しに戻ってほしいコテハンに+1
251:nobodyさん
02/05/04 21:29
>>248
Ruby使えるサーバってあんまりないと思うんだけど、どうなの？
252:nobodyさん
02/05/05 22:19 ITpza3EM
配列の展開だけじゃなく、
条件によってテンプレートの一部を表示したりしなかったりもできるみたいだ。
URLﾘﾝｸ(kari.to)
説明は不親切だが、このデモのソースをよく読んだらわかってきた。
このテンプレート展開のやり方はいいかもしれない。
253:nobodyさん
02/05/06 04:38 G0jBHwom
PHPに対するPHPテンプレートの優位性って何？
いくつか見てみたけど、 PHPだけでいいような気がしてならない
というより、PHPよりテンプレート用言語（笑）を覚える手間が
増えてるだけのような
254: ◆AngelBlk
02/05/06 18:00
>253
デザインの変更に対する対応が容易になる。
仕事で明日までにデザイン変えてとか言われると
普通にPHPコード埋め込んでやってると死ぬよ・・・。
255:nobodyさん
02/05/08 12:20
SmartyでPHP-nukeのthemesを使えねーかと思ったことあるんだけど、できるかな？
クリック一つでデザインを変られる…みたいな。
256:253
02/05/10 11:37 49KcfInZ
>>254
PHPでもあらかじめ注意して分けてれば、対応できるんじゃない？
functionとかincludeとかprependとか使えば。
強制的に分離させる（HTML中にはあまり難しいコードはかけない）ってところが
みそなのか？
PHPってもともとHTMLをちょっとだけ変える、とかに向いてるし
Smarty とかは[PHPもどき]にしか思えないんだけど
<?=$hoge ?> が {$hoge} になってるだけ、とおもえた。
HTMLタグの記号じゃないところがみそなのか？
結局 DreamWeaverとかで「プログラム素人にわかりやすく」編集できるようになってないと
分離してもあんまり意味ない気がする（というかプログラマの負担が大きすぎ）
257: ◆AngelBlk
02/05/10 14:19
>256
>結局 DreamWeaverとかで「プログラム素人にわかりやすく」編集できるようになってないと
>分離してもあんまり意味ない気がする（というかプログラマの負担が大きすぎ）
激しく同意。
確かに、Smartyは少し方向性が違うな、と思った。
（少なくとも自分が求めているものとは、かな）
自分一人で作るにしても、テンプレートの方には
出来るだけコードっぽいもの書きたくない・・・。
258:nobodyさん
02/05/10 16:10
Smartyのテンプレート言語って単純じゃないですか？
プラグインによって＋αの機能を多く実装してますが、
プログラム的なものは分岐式とループぐらいだと思います。
(これは他のテンプレートエンジンもそうですが)
ロジックが露出してしまいそうな部分は、カスタムタグを提供する事で
対処する事ができます。
＃テンプレートに渡された連想配列からツリー形式のメニューを
＃動的に生成しようとするとテンプレート側で分岐やループを駆使する事になるので、
＃これを何とかするタグが作れないか考案中。
259:nobodyさん
02/05/10 21:51 /cNgrcGu
>>253
PHPってもともとそういうものだからな。
260:nobodyさん
02/05/11 01:40
>>259
なのにそのPHPでテンプレートを開発している奴らの目標は何かと問いつめたい
ただ、{?php xxxx ?}みたいなタグじゃない形で PHP が実行できると
便利な場合もあるなと思った
261:nobodyさん
02/05/11 04:38
>>260
やっぱり、いかにプログラマとデザイナーの作業に分けるかでしょ。
じゃあ、PHPがHTML埋め込み型言語である理由って何？とか言われると
すごい小さいアプリなら、てっとり早くでっちあげるのには便利かなー、って
くらいしか思いつかない。
個人的には、PHPはHTML埋め込み"可能"言語であって、
スクリプト内にHTMLを埋め込もうと思えば、あくまでも"可能"であるって
ぐらいの認識かなぁ。
自分がずっとSmartyを推してる理由は、変数置換や繰り返し以外にも、
プラグイン追加による機能拡張や、テンプレートの出力を一部キャッシュして
パフォーマンスを上げたりする事が可能だから。
静的コンテンツを動的に生成したい時とか本当に便利。
262:nobodyさん
02/05/11 16:18
Ｓｍａｒｔｙとかの情報ってどこから仕入れてくるの？
みんな何でＳｍａｒｙの存在を知ることができたの？
どこかにテンプレートエンジンのリンク集があるのかな。
263: ◆AngelBlk
02/05/11 17:10
話がループ気味です。
>262
URLﾘﾝｸ(smarty.php.net)
とか。
あと、割と最近でた青マンモス本にもSmartyの記事あったよ。
264:narucy56 ◆wMOjCT4s
02/05/12 11:17 215DjCeq
ロジックとデザインの分離で、面白いアプローチとしては、
Walrus
URLﾘﾝｸ(210.155.146.159)
拡張タグも何も要らない、普通に書いたHTMLを （属性名 id を利用して）
ロジックから出力された文字列を展開して、表示してしまおうというアイデア。
利点としては、HTML に全くロジックが絡まないので、デザインしやすいという
ことだろうか。
とはいえ、デザイン中に書ける繰り返し要素は、一回だけ。
--
<ul>
<li id=list>さかな</li>
</ul>
def list
[ "たこ", "いか", "めんたいこ" ]
end
<ul>
<li>たこ
<li>いか
<li>めんたいこ
</ul>
---
<li>が一回しか書けないのは欠点だなと思った。
265:nobodyさん
02/05/13 04:02
>>261
PHPを使ったテンプレート
URLﾘﾝｸ(hoge.com)
とかの場合
test.phpの内容
<?
$title = "test";
include("template.php");
?>
template.php の内容
<HTML>
<HEAD><TITLE><?=$title ?></TITLE></HEAD>
<BODY><H1><?=$title ?></H1></BODY>
</HTML>
smarty とかよりこんなのじゃだめなの？
266:nobodyさん
02/05/13 12:31
>>265
条件分岐や繰り返しのある表現をしようと思うとムリがありますよね。
全てのテンプレートエンジンがそうなのかは分かりませんが、少なくとも
Smartyが提供するものは
"PHPスクリプト内にHTMLタグを書かなくて済むような仕組み"
なわけで、デザイナーとプログラマの作業分担云々へのメリットは副次的な
効果だと思う次第です。
PHPスクリプトの可読性を上げ、より保守しやすい環境を目指した仕組みな
わけで、誤解を恐れず言えば、プログラマーが楽をするためのフレームワーク
であると言っても過言ではないと思います。
267:nobodyさん
02/05/13 19:33
>>266
Smartyはデザイナとプログラマの分業を重要な目的の一つとして
制作されたので、副次的に生まれた効果ではないです。
あと、PHPスクリプトにHTMLが混入するテンプレートエンジンなんて
存在し得ないと思うんですが。揚げられたものは全て
テンプレートエンジンが最低限実装すべきもののような気がします。
268:nobodyさん
02/05/13 20:12
DB連携がスマートにできるやつがいいね。
商用だけど、WebObjectsのフレームワークは、目から鱗。
269:nobodyさん
02/05/13 20:12
>>266
>条件分岐や繰り返しのある表現をしようと思うとムリがありますよね。
いや、PHPそのままかけるんだから
for() でも while() でも書けばいいんでないの？
smarty タグとかでも同じ事をやる訳じゃないの？
template.php 内で include してもいいし、関数を呼んでもいい。
template.php 内には
<table>
<? foreach($osakana as $syurui=>$nedan ){ ?>
<tr><th><?=$syurui ?></th><td><?=$nedan ?></td></tr>
<? } ?>
</table>
みたいな感じだけで
smarty だって selectionタグってな foreach のまがい物みたいなの使うんでしょ？
270:nobodyさん
02/05/13 20:19
smarty のプラグインで何かおもしろい機能があるのか？
271:nobodyさん
02/05/13 20:58
>>266じゃないが、Smartyはかなりプログラマよりの仕様になっていることは確か
自分たちの必要に迫られて作った→いろいろ揉まれて良い物ができた→公開した
という流れらしいしね
>>267
PHPを対象としたものでなければ存在するんだな、これが
仮にPHPに対象を絞ったとしても、存在し得ないだのすべきものだの
断定的な事がよく言えたもんだ
>>268
裏でどんなSQL投げてるか想像すると吐き気がしないか?
>>269
そんな方法を採らなければいけないことが無理があるって事だと思うが…
いびつだと思わないか?もう一度>>1を読んでみろ
URLﾘﾝｸ(www.phpinsider.com)
とりあえずこの辺読んだ方が早い。
読んでも理解できなければテンプレートエンジンのことは忘れろ
お互いのためだ
だいたい200を超えたスレでいまさら
> いや、PHPそのままかけるんだから
こういうアホなことを言うな
272:nobodyさん
02/05/13 21:31
>>271
>裏でどんなSQL投げてるか想像すると吐き気がしないか?
全部モニタリングできるし、必要に応じてカスタマイズもできるよ。
１０年以上の実績あるから、信用できる。
そのへんのプログラマにSQL書かせるほうが遙かに吐き気がしないか？
273:nobodyさん
02/05/13 22:16
>>272
詳しくしらんが、NeXT時代から数えても10年以上はいいすぎだろ
吐き気を催すようなSQLしか書けないプログラマにサーバサイドアプリ
書かせるなんざ論外
274:nobodyさん
02/05/13 22:18
>>271
混入してしまった時点でその部分のコードは相手方の
手から離れてしまっているので分担とは言えないような。
Javaですか？そのエンジンが持つ、専用のスクリプトの事じゃないですよね。
そのテンプレートエンジンを教えていただけますか？
275:nobodyさん
02/05/13 22:49
>>274
わざわざ機能不足な物を知ってどうする?
なにかメリットあるのか?
最新Verでどうなってるかまで知らないし、そこまでわざわざ調べるつもりもない
興味本位なら自分で探せ
そもそも俺が言いたいのは、自分が見たことがない = 存在しない などという傲慢な
考え方はするなって事だ
276:nobodyさん
02/05/13 23:42
>>275
それは機能不足だと思うんですか？
明らかに分析が間違っているのに公開されてるような
イレギュラーなフレームワークを話題に持ち出すのは
どうなんでしょうね。
あと、最後のように間違って解釈される方がいないように
"し得ない"という表現を用いています。伝わらなかったようですが。
277:nobodyさん
02/05/13 23:58
＞吐き気を催すようなSQLしか書けないプログラマにサーバサイドアプリ
＞書かせるなんざ論外
いい開発者＋いいフレームワーク＝(ﾟдﾟ)ｳﾏｰ
278:nobodyさん
02/05/14 00:47
>>276
誰が話題に持ち出してるんだ?
分析云々偉そうなこと言いなさんな、初期のテンプレートエンジンなんざ
全部文字列置換に毛が生えた代物だらけだったからな
まあ、その程度でも十二分に便利な奴もいるし、現在メインで使ってる奴もいる
(間違いなくいる、しかもかなりな数で)所詮は適材適所ってこった
ともかく自分の常識から外れたら全てイレギュラーとは恐れ入った
何に対してもずいぶん自信がおありと見える
微妙にスレ違いだから、お前にはここまで
279:nobodyさん
02/05/14 02:01
>>278
ｵﾏｴﾓﾅｰ
280:nobodyさん
02/05/14 02:13
>>278
>PHPを対象としたものでなければ存在するんだな
あなたが、私がそんなものは存在しないと断定したと勘違いし
テンプレートエンジンの存在を持ち出してきていますね。
変数置換しか出来ない云々、そういう話でしたか？
スクリプト内にHTMLが混入するという話ですね。
それこそ、”誰が話題に持ち出してるんだ？”のような･･･。
＃文字列置換はテンプレートファイルに書かれたタグを
＃置換するもの。しっかり分担されてますね。
>ともかく自分の常識から外れたら全てイレギュラーとは恐れ入った
あなたが機能不足と判断したのであって、私の常識で言っているのではないですね。
その在り処を知らない、その実装理由も知らない、
ただそうなっていたのを見たことがある、だけでは何の力もありませんよ。
さらに私のイレギュラーの定義ですが、勝手に思い込みすぎですよ。
そんな事いってないですね。
＃私が知りたいのは機能よりも、何故そうしたかという理由です。
＃もし正当な理由なく、なんとなくそうなったのであれば
＃それは一般に公開されるようなフレームワークと呼ぶものではないですね。
281:nobodyさん
02/05/14 08:13
おーまーえーらーちょっと頭冷やしてこい。
で、冷静になってから書き込め。
ただでさえ人少ない板なのに、
これ以上人減らしてどうするよ・・・。
282:nobodyさん
02/05/14 08:53
>>280
( しまった、デムパだったか…
読心術でも使え、と言わんばかりの言葉の(頭もか)足りなさ
ま、何もかもが子供の口喧嘩レベルの後付けなんだろうけどさ
>私が知りたいのは機能よりも、何故そうしたかという理由です。
>>276から↑を推測できる人間がいるのか?
だいたい本当に知りたければ、もっと早い段階でこの言葉がでてくるはず
そもそも大元の「存在し得ない」と「存在しない」じゃ、前者の方が否定の
意味は強いし、より断定的。
>明らかに分析が間違っているのに公開されてるような
これもそう。こういう物の考え方が、根っから染みついてて自覚できない
レベルになってるんだな、きっと
相手が勘違いした。じゃなくて、相手に勘違いさせてしまった。もしくは
自分が間違っているのかもしれない。とは考えられないものかねえ
スレ違いスマソ、もうやめる
283:nobodyさん
02/05/14 12:03
>>271 うーん、smarty で >>269 みたいなの書く場合は
template.tpl 内には
<table>
<!-- {section name=value loop=$osakana } -->
<tr><th>{$namae[value] }</th><td>{$nedan[value] }</td></tr>
<!-- {/section} -->
</table>
こんなかんじじゃない。php直で書くのとあんまり変わらん気がするが。
テンプレートにループとか取り込んで細かく制御しようとすると、
phpプログラマ、HTMLデザイナの他にテンプレートプログラマが必要になるだけで
デザイン変更があった場合に動く人間の数は HTMLデザイナ+テンプレートプログラマで減ってないし
テンプレートプログラマとHTMLデザイナが兼任できれば「コンテンツ（を作る人）とデザイン（を作る人）の分離」
という目的は達成されてるんだが、こんな実装の仕方では、結局PHPプログラマがテンプレートプログラマを兼任するしかなく
そうなるとPHPプログラマの負担が増えている（テンプレート言語を覚えないといけない）だけで、
本末転倒の気がしたから、200超えてからこんな話をしてます
284:nobodyさん
02/05/14 14:05 SWWQgFa+
最初の画面はどう作ってもたいした違いはない。
問題は保守の時。
具体的に言うと
(1) デザイナーが画面イメージのHTMLを作成
(2) プログラマが(1)を表示するコードを書く
(3) クライアントに見せる、文句言う
(4) デザイナーが(1)を修正してプログラマに見せて、
この通りに直せｺﾞﾙｱ！
(5) プログラマはどうする？
これがこのスレのテーマだと思う
○ コンテンツとデザインの分離ができてない
つまり、perlのようにコードの中に(1)のHTMLが分解して埋め込んであるような状態だと、
(2)のコードを修正して(5)のコードにするのが大変
つまり(5)の作業に(2)と同じ工数がかかる
○ コンテンツとデザインの分離ができている
Smartyのようなツールを使うと、(1)の成果物（テンプレート)と
(2)の成果物（ロジックのみのプログラム）がソース単位で分解されている
(2)に手を加えることなく(1)と(4)を入れ替えるだけで作業完了（実質的には工数ゼロ）
「ロジックの修正がなくデザイン面の修正だけする場合にどれだけ楽できるか？」
という評価基準で各ツールのよしあしを評価していけばいいんじゃないの？
285:nobodyさん
02/05/14 17:03
>>282
推測できないだの、言葉が違うだのと言い出しましたか。
肝心なところは無視してるし、もう建設的な発言が出来ない方なのかな？
> >>276から↑を推測できる人間がいるのか?
> だいたい本当に知りたければ、もっと早い段階でこの言葉がでてくるはず
んじゃちょっと、あなたの登場シーンに戻ってみましょうか。
> PHPを対象としたものでなければ存在するんだな、これが
あなたは単にテンプレートエンジンの存在を示しただけですね。
私が実装理由を知りたいという事を早く明かさなかったから
じぶんは勘違いした、とでも言いたげなようですが･･･
もっと早く言ったとして、あなたのこの発言の何が変わったのかなぁ？
単に連続して煽りたかっただけでしょ。後はこのまま消えるなり、
ROMするなり、自由にしてくれてたら別にいいですよ:)
＃大人なら、”ここまで”とか、”もうやめる”とかいいながら
＃ずるずるレスするのはやめましょうねー。お互いにね;)
> そもそも大元の「存在し得ない」と「存在しない」じゃ、前者の方が否定の
> 意味は強いし、より断定的。
どこで、いつ日本語を覚えたのか知りませんが･･･。
勝手な解釈ですね。どちらがより･･･なんて比較する事自体が
無理って事は、普通、分かりますよね？
それとも、分からないの？
> 相手が勘違いした。じゃなくて、相手に勘違いさせてしまった。もしくは
> 自分が間違っているのかもしれない。とは考えられないものかねえ
>>279 ;)
あと、心配しなくても、このスレの端の人からしてみれば
お互いその”デムパ”というものに十分括られていると思いますよ;)
あー、あと、最後に些細なちゃちゃ入れ。
> 詳しくしらんが、NeXT時代から数えても10年以上はいいすぎだろ
詳しく知らないなら、間違った事をわざわざ言う必要ないですよ。
私もｦｶｰですが、EOFは10年以上の枯れた技術です。
286:nobodyさん
02/05/14 17:41
>>285
最後にレスした方の勝ち合戦ですか？
あなたの方がだんだん言うことが矛盾してきてますよ。
悪いけど出てって、そして2度と来ないで。
すごく邪魔。
287:nobodyさん
02/05/14 18:23
>>284
>これがこのスレのテーマだと思う
確かにその通りだと思うです。
(3)=>(4) のあと、 (5)の際にデザイナーが
(1)のHTMLを修正するか、(3)のphp/tpl を修正するか
デザイナが (5)時に プログラマが作った(3)のphp/tplを
問題なく修正できるようになってれば解決するわけで
で、じゃあ smarty は ”php 以上に”それができているか？
という視点で見ると、そうでもないように見えて仕方がない
ということを「phpでできるよ派」は言っている
288:nobodyさん
02/05/15 15:21 JcpmR/QY
>>284
そういう状況を考えるとWalrusのようにテンプレートがピュアHTMLで独自タグを
使ってないのが便利そうだな。
> (1) デザイナーが画面イメージのHTMLを作成
> (2) プログラマが(1)を表示するコードを書く
ここでは、(1)にid属性を加えればテンプレート完成
そして、そのテンプレートをデザイナーに渡しておけば
> (3) クライアントに見せる、文句言う
> (4) デザイナーが(1)を修正してプログラマに見せて、
> この通りに直せｺﾞﾙｱ！
基本的には、ここで修正した画面イメージはそのままテンプレートになってるはず
だから
> (5) プログラマはどうする？
何もしないで「もうできるぞｺﾞﾙｱ！」 ということになる‥はず‥だが‥ｿﾝﾅﾆｳﾏｸｲｸﾉｶﾈ?
289:nobodyさん
02/05/15 15:44
>>288
その分自由度が損なわれるだろうな おそらく
290:nobodyさん
02/05/15 15:59
micromedia の ULTRADEVELOPER 4 ってどうよ？
291:nobodyさん
02/05/15 16:10
>>288
最後の問題は DreamWeaver や GoLive などのデザイナの使うツールと
デザイナの意識だなあ
> (3) クライアントに見せる、文句言う
ここで「（プログラムが絡んでる）テーブルの色かえろや！」という文句が来た場合、
Walrusだとid （エデイタにはただの属性値にしか見えない）だけ残して色を変えてくれるか？ id がとれた、変わったときに警告してくれるか？
smartyとかphpだと、smatyタグやphp（エデイタからはコメントに見える）が、とれたとき、間違った位置に来たときに警告してくれるか？
デザイナが
編集→ローカルでぷれびゅ→ＯＫ
→でもプログラム部分が壊れてるかもしれないのでプログラマがチェック→結局プログラム組み込み部分組み直したりとか(；´д⊂）
という流れが
編集→デザイナがアプリケーションサーバを通してぷれびゅ
→誤作動発見
→何で壊れてるかわかるので自分で修正→プログラマは何もしない(ﾟдﾟ)ｳﾏｰ
→何で壊れてるのかわからないのでプログラマに(ﾟДﾟ)ｺﾞﾙｧ!!
→これくらい覚えろや(ﾟДﾟ)ｺﾞﾙｧ!!→デザイナが覚えて直す
→うまく動いた→プログラマは何もしない(ﾟдﾟ)ｳﾏｰ
となる機能と、デザイナにちょっとくらいは覚える気力が備わっていると、まだましかも
あと、テンプレートの編集が他のページにも影響する、と言うことを理解して
デザイナがデザインしてくれるか？ とか
DreamWeaver超デブならアプリケーションサーバでプレビュが簡単にできるのかな？
292:nobodyさん
02/05/15 16:46
>>291
> Walrusだとid （エデイタにはただの属性値にしか見えない）だけ残して色を変
> えてくれるか？ id がとれた、変わったときに警告してくれるか？
CSSでidを指定して特定のタグにstyleを指定することができるはず。
だから、エディタが勝手にidを変えたり取ったりしちゃいかんと思う。
> 編集→デザイナがアプリケーションサーバを通してぷれびゅ
> →うまく動いた→プログラマは何もしない(ﾟдﾟ)ｳﾏｰ
こうならなきゃエディタのバグと言っていいのでは？
293:nobodyさん
02/05/15 18:19
>>292
> > 編集→デザイナがアプリケーションサーバを通してぷれびゅ
> > →うまく動いた→プログラマは何もしない(ﾟдﾟ)ｳﾏｰ
> こうならなきゃエディタのバグと言っていいのでは？
なかなかねえ
たとえばデザイナーが修正個所まるっと消して、再作成しちゃったら…
…なんてこともあるから、ツールが全てを解決できるわけじゃないだろうし
そんなところまで面倒みるようなツールは逆に使いにくいでしょ
テンプレートを理解してくれるデザイナーと仕事をすればいいだけの事
テンプレート専用タグよりCSSのほうがずっと難解だもの、理解できないわけがない
294:nobodyさん
02/05/16 11:31
>>293
>たとえばデザイナーが修正個所まるっと消して、再作成しちゃったら…
テンプレートの編集不可部分かパラメータの定義部分に、
「そのページにはこの独自タグ・機能・パラメータが使われてるはず！」っていう設定ができて
実行時（ぷれびゅ時）にはずれているとエラーが出る機能があるとイイかも
>テンプレートを理解してくれるデザイナーと仕事をすればいいだけの事
それはそうだがなかなか...CSS とかも専用エディタとかあるからな...理解してるとは限らん
295:nobodyさん
02/05/16 14:59
>たとえばデザイナーが修正個所まるっと消して、再作成しちゃったら…
WOFだと、どこに何があったはずだからエラーってのが出るよ。
DB連携箇所とかもぬかりなく。
みんな、けっこう原始的な方法使ってるんだな・・・・
296:fbfhjq
02/05/17 13:20
夜逃げしたい？
金欠？
ブラック？
別れさせたい？／騙された？／不良債権・名義貸し？
トラブル各種は相談してくれ。
（有）エスアールエー／0120-0120-49
info@sra-japan.com
297:nobodyさん
02/05/22 20:49 7i+05eoy
スレとはあんまり関係ないかもしれんけど、ナビゲーションで
<A HREF="index.html">HOME</A>
<A HREF="menu1.html">MENU1</A>
<A HREF="menu2.html">MENU2</A>
みたいなのがある。で、DW のライブラリとか使ってコピペするわけだが、
「Homeのページ内ではHome部分、Menu1 に来たときは Menu1の部分の色変えてね」
とかいう要求が結構ある
すると、
<A HREF="index.html">HOME</A>
MENU1
<A HREF="menu2.html">MENU2</A>
とか
HOME
<A HREF="menu1.html">MENU1</A>
<A HREF="menu2.html">MENU2</A>
とかなって、パーツ化できない
テンプレートとかでこういうのをカンタンに解決してくれる方法はない？
298:nobodyさん
02/05/22 20:56
>>295
WOではどうやってHTMLとプログラムの統合するの？
299:nobodyさん
02/05/22 21:08 YVZelF47
>>298
そこがWOのいいところ
自分で調べて比較しないと分からないとおもうよ
ASPやってるから泣きそうです
WOをしったしってしまったばっかしにJ2EEやASPが面度さくさくかんじます
300:nobodyさん
02/05/22 22:25
>>297
Javascriptなら簡単とか言ってみる。
301:nobodyさん
02/05/23 02:32
>>300 どうすんの？
302:nobodyさん
02/05/23 04:19
>297
色を変えるだけなら
ｽﾚﾘﾝｸ(hp板:36-43番)
303:nobodyさん
02/05/23 11:51
>>302
ありがとー
CSS使うやつはページ数増えてくるとかなりつらいかな。
クライアントの処理的にどうだろ
perlスクリプト使えば！ って話が上がってるけど、具体的な内容を知りたい..
304:nobodyさん
02/05/23 15:20
>>301
DOM
305:nobodyさん
02/05/23 23:51
WOでの開発方法や技術資料は、ここみればおおよそ理解できる。
URLﾘﾝｸ(www.apple.co.jp)
んで、WOはMacでしか動かないｸｿｱﾌﾟﾘでなくて、
開発はMacとWinNT/2K/XPでできて、運用はWO-DeploymentとJava2VMがあればOK。
>>299
確かに、WOのWOFとEOFなんかを知ってしまうと、JSPとかPHPなんかでUI作って
SQLをｼｺｼｺ埋め込んでるのがﾊﾞｶらしくなるよな。
EJBなんか手間ばっかくって、開発者泣かせのｳﾝｺﾁﾝﾁﾝ。
Struts? ﾊｧ?ｺﾞｸﾛｰｻﾝって感じになる。
306:narucy56 ◆wMOjCT4s
02/05/24 07:16 DidxxJnT
>>306
確かにな。Web プログラミングなんて、そんなもんだ。
自動化できる部分は沢山ある。
Struts もなんだが、（Struts の設定関連ファイルの雛型作るツールがいくつかあって）
柔軟性を保ちつつも、開発の自動化も進んでくるんじゃないかと思う。
307:nobodyさん
02/05/24 08:47
>>285
> あー、あと、最後に些細なちゃちゃ入れ。
> > 詳しくしらんが、NeXT時代から数えても10年以上はいいすぎだろ
> 詳しく知らないなら、間違った事をわざわざ言う必要ないですよ。
> 私もｦｶｰですが、EOFは10年以上の枯れた技術です。
EOFはその前身のDBKitまで戻っても、発表は92年8月。
10年近いことは確かだが、以上ではない。
ちゃんと正しいデータを書かないと本当にデムパ扱いされちゃうぞ。
308:nobodyさん
02/05/24 10:02
>>305
WOFとかEOFってなんのことかまったくわからなかったけど、WebObjectsのことだったのね。
こんなツール存在すら知らなかった。サンクス。
結構よさげなんだけど、マシンパワーガシガシ食いそうでちょっとこわいかな。
TrialCDの配布が終了してたけど、また配布してくんないかな。
試してみて自分に合えばぜんぜん出せる金額なんだけど、いきなり買うにはちょっとたかいなぁ。
309:nobodyさん
02/05/24 11:23
>>308
ポケットマネーでなんとか個人でも買える金額だよね。
２年前くらいは、同じモノが￥７００万だったんだよ。
９９％ＯＦＦ・・・・・
310:nobodyさん
02/05/24 13:25
>>309
どうもいい加減なことを書くやつが多くてかなわんな。
700万だったのは無制限アクセスの運用ライセンスだけ。
開発ツールは20万くらいで買えた。それでも今の方が安いけど。
普通に稟議書書いてなんとか通せるくらいの金額だ。
311:nobodyさん
02/05/24 13:31
>>308
Mac版だったら、タダでTrial版がダウンロード出来る。
でもその文章の感じじゃ絶対マカーじゃなさそう..。
312:nobodyさん
02/05/24 13:56
>>310
あんたのほうがいい加減なこと書いてるよ。
「同じモノが」って言ってるわけで、今売ってるモノは無制限アクセスの運用ライセンス込み。
313:nobodyさん
02/05/24 16:59
>>311
> 試してみて自分に合えばぜんぜん出せる金額なんだけど、いきなり買うにはちょっとたかいなぁ。
というようなことを言う人が、無制限運用ライセンスを欲しがってると判断する方が変だ。
ちょっと試したいときの値段と、昔の700万を比べてもナンセンス。
314:nobodyさん
02/05/24 17:07
それから、WOでロジックとデザインの分離が完璧に出来る、という話は
良く聞くしここにも何人か書いてるひとがいるけど、実際にWOで開発
やってる連中のコードのぞくと、全然それを実践していないことが多い
ってのも一応指摘しておく。
他よりは数段マシなのかも知れないけど、ツールは万能ではない。
だから、WO使ってコードとデザインを分離してるとは言いながらも、
どうやって分離を実現しているのか? をちゃんと説明出来ないと
いまひとつ引きが弱い。
ケンカを売ってるわけではなくて、自分でもどうするがベストなのか
決められないから悩んでいるわけだが。
315:nobodyさん
02/05/24 18:49
目的と状況によりけりってとこなのかな。
WOも他のツールも、所詮は道具でしかないからな。
とはいえ、OOPをきとんと理解できてないとWOを生かせないし、
他のツールでやってた人間が初めてWO使うプロジェクトに投入されたら
それはそれで地獄だろうな。
316:nobodyさん
02/05/26 18:06
今Cocoon2を使って仕事している。マジでマンセーだ。WO一時期使ってたが
漏れは今やCocoon2にゾッコンだ。マジで分業が楽だ。新人のド素人使っても
生産性が上がった。漏れはXSP主体で担当しているが、新人にXSLTやらせて
進捗がガンガン上がってる。元々SQL書くのは慣れているので、この点でも
気が楽だな。癖は強いが取っ掛かりが意外なほど楽だったので素人向きかも。
XMLの利点なんてわからなかったが、取り敢えず納期に余裕で間に合いそうなので
Cocoon2最高！って言っておく（ｗ ま、大したアプリじゃないんだがな（藁
317:nobodyさん
02/05/27 00:06
Cocoon2のスレってある？
318:名無しさん＠Ｅｍａｃｓ
02/05/27 01:14
>>316
差し支えない範囲で教えて欲しいんだけど、どんなアプリ?
319:nobodyさん
02/05/27 01:18
XSLTL+XSP、便利だけど、メンテナンスが大変だよ。
担当者が変わったら、理解するのにけっこうコストかかる。
320:316
02/05/27 01:41
>>317
あったらいいな。あるのか？
>>318
ナレッジマネジメントという名の社内掲示板だ（ｗ ageとかつけてやろうか
とか思ったよ。ただ、結構検索機能が複雑なんでその辺がナレッジ～～っぽい
ということかな（藁）あと、携帯電話からも使えるようにとか、色々あるので
その辺XSLTを複数用意しておくだけで解決できているのは楽だ。
>>319
何でも一緒だと思ってるから平気。つかWOはJavaやSQLの素人には習得に時間が
かかるのが難点だった。素人ばかりアサインされる漏れの立場からすると、
結構いらいらしたんだよなー。何でわかんねえんだとか怒ったりして嫌われるんだよ。
その点Cocoon2だと「お前XSLTに専念しる！」って可愛いトウシロの新人ちゃん
（マジ、可愛いんだよ）にやらせても、ちゃんと戦力になるのが嬉しい。
そうすると誉めてやれるから良い先輩になれるんだよ。愛が芽生えて欲しいぞ（ｗ
だから今マジで仕事楽しいよ。女の子ってああいう見た目ちゃんと作るの好きジャン。
俺はそういうの苦手だからちょうどいいしな。その女の子同期の子に「仕事楽しい」とか
言うわけだよ。そりゃ楽しいだろう。GIFとか作ってりゃさ。そうすると他の苦しい
プロジェクトにアサインされた子なんかも「いいなー」って良い先輩状態さ（藁）
何がいいって、そういう状態がいいんだよ。技術的なことなんてどうでもいいさ。
あと、基本的にDBはストアド使い倒しているので、XSPの記述はすげぇ少ない。
複雑なロジックはServlet＋BeanにしてしまってGeneratorに割り当てたり
GeneratorやActionを自前で作成したりすれば解決だしな。そうすると
XSPに書くことなんてホントにぱっと見て判ることしかないって按配だ。
JUnit使ってちゃんとテストできるし。そもそも俺コード書くの嫌いだし。
ま、単純な掲示板だからな。そんなもんだ。
321:318
02/05/27 08:05
>>320
なるほど。「お前XSLTに専念しる！」ってのはいいかも。オブジェクト
指向の魂いらないし。
漏れ今WO勉強中で結構作業が楽になりそうだと感じてるんだけど、必要
な素養が多いから確かにゼロから学習する人にはキツいね。でも、どっ
かで責任範囲の線引きして素人に作業振れないかな。316はWO使ってる
時どんな作業分担してたの?
322:nobodyさん
02/05/27 09:11
たしかに、XSLTというコンセプトが発表されればだれでも考えるんじゃ、
ってくらい自然ななりゆきだし、理解しやすいのかもなー。
323:nobodyさん
02/05/27 10:54
お前XSLTに専念しる！」ってのは、いいかもな。プロジェクト運営には。
成果物って点では疑問だけど。
なぜなら、うちとこにXML+XSLTで組み上げたクソシステムが転がってて
だれも、メンテできないから(泣)
324:316
02/05/27 11:26
>>321
作業分担は、結局アプリの機能単位になってしまってたな。最初はWOF隊と
EOF隊とかって感じで分けようとしたりしたんだが、なかなかしっくりこなくてなー。
WO半年くらいなので試行錯誤だったから、俺がヘタレなんだと思うけど
「分離」は上手く出来ても「分業」という風にはし辛かった。
何というか便利なんだけど、周囲と分かち合い辛かったな。WOのせいと
いうより俺の力不足だけど。
>>323
XSLTそのものは確かに見通し悪いよな。でもそれは複雑なデザインのHTMLなら
どんな道具を使ってもぶつかる問題だから割り切ってる。
Cocoon2だと、ロジックはXSLTから完全に追い出せるから分業ができる。
それにGoLiveでXHTML作って、ちょちょって変更するだけなので作業させやすい。
入門書も多いし。
・・・あと、Cocoon2の最大のメリットは、ローテクだってこと。要素のそれぞれ
（XML,XSLT,SQL,Javaなどなど）について、入門書とか多いじゃん。それを
読んで割とそのまま実践しやすいんだよ。Cocoon2自体はノリ付けの役目が
殆どだから。WOはハイテクなんでな、パイロット育成に時間がかかるんだよ（ｗ
対してCocoon2独自の技ってのは意外と少ないし、必要ならオープンソースだから見れば判る。
結構ソース綺麗だしな。Cocoon2独自のスキルを改めて習得する必要が少ないってのが
ポイント高いところかな。実際3人組でやってるが俺以外は全然Cocoon2知らないし。
Cocoon2は、デザイン（XSLT）、コンテンツ（XML）、ロジック（XSP）に分離して、かつ
それをSitemapで組み合わせていくというのが秀逸。Sitemapがなかった1.xのころは
こんなの使えるか！って感じだった。Sitemapはホント素晴らしい。おかげでダミーの
XMLを作成しておいて、XSLTを先に作らせといて、あとからSitemapで切り替えるだけで
完了！ってのが便利だな。
ちなみに俺はWO好きだ。便利だと思う。特にEOFはマジで感動した。
俺はSQL10年以上やってるから書くのは苦にならないんだが、それでもEOFは
いいと思ったよ。2chも随分参考にさせてもらったし、感謝してる。
だけど素人ばっかり使ってると教えるのにへこむんだよ。まぁ俺とは相性が
イマイチだったってことなのかもな。俺は頭悪いから単純な奴の方が
やりやすい。
ま、そんことより、残業が減った分プロジェクト予算に余裕が出来たから
結構後輩と飲み会できるって方が、俺には嬉しいよ（藁）