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も随分参考にさせてもらったし、感謝してる。
だけど素人ばっかり使ってると教えるのにへこむんだよ。まぁ俺とは相性が
イマイチだったってことなのかもな。俺は頭悪いから単純な奴の方が
やりやすい。
ま、そんことより、残業が減った分プロジェクト予算に余裕が出来たから
結構後輩と飲み会できるって方が、俺には嬉しいよ（藁）
325:narucy56
02/05/28 03:35 R/0H6IB3
WALRUS
URLﾘﾝｸ(walrus-ruby.hoops.ne.jp)
フツーの HTML 文章からリストを展開するというアプローチ。
326:nobodyさん
02/05/28 04:37
> 結構ソース綺麗だしな。
Apacheの連中のプロダクツって、なんか姑息なワザが多いような気がするのは
漏れだけだろうか。ま、そうしないとたちまち遅くなってしまうというのはあるが。
327:nobodyさん
02/05/28 05:33
（´-`）.。oO（でも、mod_autoindexは簡単に全体のデザインを変更できるようにしてくれた方がありがたい……)
328:nobodyさん
02/05/28 11:23 TpvqXC+o
>>246
先生! Smartyの日本語マニュアルはどうなってしまったのでしょうか?
329:318
02/05/28 16:35
>>324
> 作業分担は、結局アプリの機能単位になってしまってたな。最初はWOF隊と
> EOF隊とかって感じで分けようとしたりしたんだが、なかなかしっくりこなくてなー。
> WO半年くらいなので試行錯誤だったから、俺がヘタレなんだと思うけど
> 「分離」は上手く出来ても「分業」という風にはし辛かった。
> 何というか便利なんだけど、周囲と分かち合い辛かったな。WOのせいと
> いうより俺の力不足だけど。
> ・・・あと、Cocoon2の最大のメリットは、ローテクだってこと。要素のそれぞれ
> （XML,XSLT,SQL,Javaなどなど）について、入門書とか多いじゃん。それを
> 読んで割とそのまま実践しやすいんだよ。
すごく参考になった。ありがとう。
漏れも半素人との分業が多いんで、そのうちCocoon2も調べてみるよ。
WOを使うとしても、よくよく分担の仕組を考えないとまずそうだね。
330:316
02/05/29 01:43
>>326
そういうのまで含めて、漏れには参考になってる（ｗ
>>329
Cocoon2の問題は、このスレでも出てたがXSLTの記述を簡単にできる
GUIのツールがないことだな。GoLiveやDreamweaver単独ではムリなので
自前でスクリプト作るとかTidy駆使するとか工夫は必要だ。どれも
ローテクだけどな。でも調べる価値は充分あると断言するよ。
まぁひまなときにでも触ってみてくれ。XMLPRESSのVOL.6に記事が載ってたよ。
331:nobodyさん
02/05/29 02:59 fN9RbxN4
cocoon１.xは昔使ったが、レスポンスがなんか一呼吸ある感じで、
アクセスの多いサイトとかだとどうかなーっと思った。
332:316
02/05/29 03:40
>>331
1.x1はDOMベースなので遅かった。2.0からはSAXで書き換えられたので
随分と改善されたよ。
333:nobodyさん
02/05/29 20:14 fktfuQY8
299だけど
プロジェクトを構成する人間がどれだけ
ロジックとコンテンツを分離することが重要か理解できていないと（考えてないと）
どんな言語 ツールを使っても意味ないと思うよ
けいけんだんから
334:316
02/05/30 00:17
>>333
禿同。
335:nobodyさん
02/05/30 01:33
豚に真珠、猫に小判とは、そゆことを言うんだな。
336:nobodyさん
02/05/30 03:02 eC70WsjL
Cocoonって実務で使えるレベルなのか・・・（？
337:nobodyさん
02/05/30 04:24 eC70WsjL
亀レスなんすけど、デザイナが書くべきtemplate(html)ファイルの中に
条件式書けたらmvcじゃないっすよね。←理想論かなぁ
なんか利便さを求めると本末転倒のような。
それだったら別にphpの内部に処理書けばいいわけだし。
（←別ファイルとしてincludeするとか
ブラウザでテンプレートhtmlファイルを閲覧できた方がいいですよね。
>187
のような場合は.phpのスクリプト側でヘッダーファイルを読み込んで
テンプレートエンジンに渡した方がいいのかな、と思うのですが。原始的だけど。
smartyの場合、テンプレートがphpファイルとして解釈される(>38)らしいので
また違うのかもしれませんが。
仕様としては面白いけど、そもそもな、、、気も。
includeをテンプレートでする(control)とか。
全くプログラマよりの仕様であることは確かだと思います。
将来的にはXHTMLで独自タグ(コントロールとして規定するなり）
を使うってのがいいような気がします。
phpにはもうちょっとdom関数成熟して欲しいですが(4.2.xでまた結構変わった
まぁ、ぶり返すようで、当たり前でアレですが。
338:318
02/05/30 07:24
>>333
「プロジェクトを構成する人間」が複数の技術者を指してるなら同意。
デザイナを含んでるなら、違うと思う。
339:316
02/05/30 09:17
>>336
実務で使ってるよ。実務にもピンからキリまであるから案件に
合うものを選んで使えばいいと思う。
俺はLinux上のBlackdown製JDK1.1でJservってころからでかい案件
やってきたので、そのときの不安からするとCocoon2はすごく安心感ある。
Cocoon2は確かHPのAP鯖にも組み込まれてるしな。
340:nobodyさん
02/05/30 14:38
>>339
>>336じゃないけど、サンクスコ。かなり興味が湧いたよ。
Jservより安定してるならいいかな。
（じつはまだJservの動いている鯖管理もしてたりする）
教えて君で申し訳ないけど、これからCocoonを導入しようって時に役立つ本とか
資料ってある？
341:316
02/05/30 18:47
XMLPRESSのVOL.6がまずは参考になる。
本文の最後に参考文献が載っているので、これも網羅すると良い。
あと翔泳社の「Javaプログラミング集中講座サーバ編」っていう
ムックがあってその中に記事があるのでこれも参考になる。
それくらいしか日本語の書籍ベースでの情報はないかな。
あとは下のところにも行くと良い。
Cocoon Information
URLﾘﾝｸ(www.emergence.jp)
cocooncenter Home
URLﾘﾝｸ(www.cocooncenter.de)
ドキュメントは当然英語だが頑張って読破すべし。
あと意外なところで、ソースの中のコメントにサンプルがあったりするので
積極的にソースコードは見たほうがいい。2.0.1では動いていたサンプルが
仕様変更で2.0.2で動かなくなってたりするのだが、コメントを見るとしっかり
修正版の記述方法が書いてあったりする。
ってなところだ。
342:316
02/05/30 19:14
>>340
補足しておくと、Cocoon2自体はAvalonベースのフレームワークだが
実行にはServletコンテナが必要になる。実際にはcocoon.warで配布されている。
だもんで、安定性という点で言うとコンテナに左右される点があることは
予め承知しておいて欲しい。俺はTomcatを使ってるが、Tomcatを信頼できると
言えるかどうかは案件次第だしな。他のAP鯖でも使えるはずだし、その辺は
自分の都合に合わせてくれ。
343:nobodyさん
02/05/31 00:37
php屋とjava屋とWOマンセーなマカーとRuby好き、cocoonの虜が入り乱れてるな、
ここは（ｗ
344:316
02/05/31 00:51
>>343
そうだな（ｗ だが俺はCocoon2よりも可愛い新人の虜だ（藁）
345:316
02/06/02 03:03
>>330
自己レスだが、XSLTをGUIで作成できる便利なツールがあった。
商用なのだがXMLSpyというのがある。これのSuiteの中に含まれている
XSLT Designerというのがいけている。早速購入申請をしようと思ってる。
お試し版をDLしてチュートリアルをやっただけだが、エディタでガシガシ
からはおさらばできそうだ。日本語版もあるらしい。
346:nobodyさん
02/06/13 15:18 yNmFMLOL
age
347:nobodyさん
02/06/13 19:24 ayuV0hwK
316は、マジで羨ましいYO!
ｾｸｰｽできたら写真ｳﾌﾟしてくれYO!
348:316
02/06/18 00:22
>>347
ｾｸｰｽは難しいと思われ。ﾏﾀｰﾘ逝くよ（ｗ
さて、新人娘担当分のXSLT全部終わっちゃったよ。テンプレートの
使い方をマスターしたら、何気に工夫し始めた。偉いな、うんうん。
おじさん嬉しいよ。
なので検索処理の手間のかかる部分以外は、一通り動いちまった。
予定では何だかんだであと1ヶ月くらいかかるかと思ってたので
すごく気楽になった。久々にのどかな感じだ。
349:nobodyさん
02/06/18 10:16
Webアプリで、テンプレがXML+XSLTで作られてる時って、
テンプレ部分のデバッグってどうやんの？
350:316
02/06/18 15:26
>>349
テンプレートがXML+XSLTってのが今ひとつ判らないので外したらスマソ。
ページのヘッダとかフッタをXML+XSLTで作成している場合、ということかな？
だとしたら個別に作成しておいて、includeやcall-templateなどを
駆使するという感じで対応できる。
で、デバッグというのが良くわからんな～。どういう状況？
ちなみに、XSLTUnitというのが（俺は使ってないが）バージョン0.0.1なんて
レベルだがあることはある。これもテンプレートを活用したものだ。
351:nobodyさん
02/06/23 03:18
このスレは、やっぱりプロの人のスレなのかね。
あの、そろそろテンプレートエンジン用のスレ作りませんか？
あと、smartyの和訳はいずこへ…
352:nobodyさん
02/06/23 13:31 AV3cblpq
>>351
>そろそろテンプレートエンジン用のスレ作りませんか？
いらないよ。そんなもん。
テンプレートなんて、HTML 吐き出す関数を書けばいいだけやん。単純極まりない。
単純なら単純なまま、そう作ればいいと思う。
353:nobodyさん
02/06/28 20:41 lD5j6FWe
>>351
立てて立てて。
この世界、大は小を兼ねないからね。
延々とAPサーバ系の話されてても参考にすらならない。
>>351
単純な物ほど奥が深いと思いねえ。
354:nobodyさん
02/06/28 22:29
>>350
スレたて賛成
私はHP制作のプロじゃなくて、個人HP作ってるだけなので、APサーバの話しはよくわからなかったです。
なので、別スレがあった方がありがたいっす。
>>351
smartyとか、かなり複雑になってきてると思いますけど。
355:nobodyさん
02/06/29 12:40 QOFblC9h
>>354
複雑なものは使う価値なし。というか元々PHPなんて使う価値なし。
356:nobodyさん
02/07/01 20:10 vc/YDHho
Smartyをsafe mode onで使っている人いますか？
SmartySingleDir.class.php 以外に方法ってないんでしょうか？
357:nobodyさん
02/07/10 01:26 Bf103iyC
これよさげ
URLﾘﾝｸ(www.fk.urban.ne.jp)
PHP4カスタムタグ
358:nobodyさん
02/07/14 20:17
>>357
PHP本体にその機能が組み込まれてくれたらいいのにね
359:nobodyさん
02/07/23 13:08 o6Uqr4Ab
Ruby用のテンプレートライブラリ
URLﾘﾝｸ(kari.to)
URLﾘﾝｸ(kari.to)
誰かPHPで同じことやってくれんか？
360:nobodyさん
02/07/29 14:53 ZmYJlXK3
いつのまにかSmarty2.2.0出てるage
URLﾘﾝｸ(smarty.php.net)
361:nobodyさん
02/08/04 20:32
ageeee
362:nobodyさん
02/08/11 12:51 R3Ij6n7j
いつのまにかSmarty2.3.0出てるage
URLﾘﾝｸ(smarty.php.net)
363:nobodyさん
02/08/11 18:13 Ms7aTxrB
つきあってられん。
364:nobodyさん
02/08/14 11:15 bYkAqAae
Servlet,JSPで携帯サイト作るとき、ロジックとデザインの分離って
できますか？
コントローラのServlet用意して、データのBeanをセッションに放り込んで、
JSP側で拾うってことができないから、やぱJSP側でロジックのクラスを
呼び出して、ページリンクは、JSPに書くというモデルにならざるを
得ないんでしょうか？（URLのセッション変数は使わない仕様）
※何気のこのスレ良スレ。
365:nobodyさん
02/08/28 13:35 pGZkk2O6
＞＞３６４
＞やぱJSP側でロジックのクラスを
＞呼び出して、ページリンクは、JSPに書くというモデルにならざるを
＞得ないんでしょうか？
RequestDispatcher::forward とか
366:nobodyさん
02/09/06 01:37 pfquKKHb
Perlでテンプレートモジュール作りました。
CPANに登録するつもりはないのですが。
ここで公開してもいいですか？
367:nobodyさん
02/09/06 03:25
>>366
罵倒されるか、厳しいつっこみが入るか、まったく無視されるか、称賛されるかは
わかりませんが、問題はないでしょう。
368:nobodyさん
02/09/06 05:25 SwN4wAbM
perlerじゃないが期待あげ
369:366
02/09/07 06:48 UExbT08M
まだドキュメントを作ってないので簡単に作ってから
公開しようかなと思います。
370:X ◆japan/wc
02/09/07 16:46
>>364
HTMLテンプレ読みこんで置換して吐けばいいだけなら何ででもできるだろ。
371:nobodyさん
02/09/07 19:28
>>366
HTML::Template との違いを述べよ。
372:nobodyさん
02/09/07 20:57
>>371 禿同
<TMPL_LOOP>
<TMPL_INCLUDE>
<TMPL_IF>
さらにステキ機能を持ってるなら期待
373:366
02/09/08 20:33 CI7/kLe9
今回作ったテンプレートモジュールを簡単に説明します。
名前は、Tmpl.pmです。
基本的には テンプレート側に%hoge%のような変数を埋め込み
それをプログラム側で置換します。
あと、
<!--#cut name="hoge" -->
<!--#cutend -->
というタグに挟まれた部分を切り取り部品として使います。
ループや分岐処理させる為のタグです。
374:366
02/09/08 20:34 CI7/kLe9
HTML::Embperl派の人達を取り込むための「媚び」として
テンプレートにPerlの変数を埋め込めたり、
<!--#perl -->
<!--#perlend -->
というタグの中に直接Perlのコードを記述できたりします。
375:366
02/09/08 20:38 CI7/kLe9
おまけ機能としては、
テンプレートで外部ファイルや画像ファイルを読み込んでいる場合、
それらのファイルとテンプレートとCGIファイルが同じフォルダに
ある場合は問題ないのですが、別のフォルダにある場合、
CGIで出力する際にそれらのファイルへのパスが変わってしまいます。
そのためにパスの置換処理もできるようにしておきました。
376:nobodyさん
02/09/09 00:13
>366
php版がほすぃyo!
377:nobodyさん
02/09/09 00:16
コードをアップしてから説明すれ
絵に描いた餅ｳｻﾞｲ
378:nobodyさん
02/09/09 01:16
<BASE HREF=''>でもよさそうだが375の機能はいいかも
374はデザインとコード分離したい手前嫌だな
cutしてテンプレートをブロックに区切って扱うちゅうのはわかるけど
HTML::Template使ったことある？
379:nobodyさん
02/09/09 23:32 IgslT6n4
phpの話だけど、php-mlでテンプレートの有用性の話題が出てるね。
380:366
02/09/10 23:45
今日まで仕事が忙しくてまだドキュメント作成できてません。
モジュールだけアップして「解析すれ」というのも
無責任なんでちゃんとやってからアップします。
しかも明日から海外旅行に行くので１７日までは
手をつけられません。ごめんなさい。
381:ネラ
02/09/11 12:02 ucHxsRkV
>>372
その３つともあるよ。「4D」というWebアプリケーションサーバだけど。
www.4d.com
382:nobodyさん
02/09/11 22:58
ドキュメントいらんよ。コードだけ見せれ。
383:nobodyさん
02/09/13 14:20 iLAw4QWK
URLﾘﾝｸ(www.pm9.com)
384:hoge
02/09/13 15:13 QIoL0ggW
>>382
例１）ループ
<!--#4DLOOP arrProduct-->
<tr>
<td>hoge</td>
</tr>
<!--#4DENDLOOP-->
例２）SSI
<!--#4DINCLUDE MyHeader.html-->
例３）条件分岐
<!--#4DIF $Var='hoge'-->
<H1>逝ってよし</H1>
<!--#4DELSE-->
<H1>イイ！</H1>
<!--#4DENDIF-->
385:nobodyさん
02/09/14 06:48 TjmGHZ9+
やっぱ amrita が一番使いやすいなぁ。
386:nobodyさん
02/09/14 11:13 R4eRML0P
>>385
実際に使ってるの？
レポートきぼん(特に性能)
387:nobodyさん
02/09/14 19:12 TjmGHZ9+
速いかどうかはベンチ取ってやってみては。
（データをどっかから取ってきて html に変換して、public_html へ放り込む
バッチを作った程度。そういう処理を定期的にやる）
書きやすさでは一番だし（デザイン担当の人にとっても楽）、
ruby で書いていけるのはいい。
想像では、CGI で使うのはちょっとメモリがもったいないかなという気がする。
メモリ上に構築したハッシュをドンと渡してやるだけだから。
web サーバとの関係も考えつつ、amrita 使わず、eruby を使って、
イテレータで少しづつ渡していくように作ったほうがいいと思う。
388:nobodyさん
02/09/14 19:39 TjmGHZ9+
>想像では、CGI で使うのはちょっとメモリがもったいないかなという気がする。
と、思ったが、すぐ開放してくれるもんだし、気にしなくてもよいかな。
389:nobodyさん
02/09/14 22:16 jEvDqaSB
>>387
Enumerableなオブジェクトをモデルにしてコンパイラを使うと
メモリは1行分だけしか使わないよ
require 'amrita/template'
t = Amrita::TemplateText.new '<ul><li id=list></ul>'
t.use_compiler = true
t.expand(STDOUT, {:list=>STDIN})
これを実行すると、端末から1行入れるとすぐにその行を<li>つきで出力する
だから、必ずしも全部メモリに展開するわけじゃないと思う
390:nobodyさん
02/09/15 06:40
>>384
だれも4Dのことは聞いてないよ。
なおかつ、 HTML::Template でそれは出来るんだから、それ以上の何かが
ないと使えないよ、って話なんだが・・・
391:nobodyさん
02/09/15 21:49 bpMuztdb
>>389
マジですか。たいしたもんだ。
392:nobodyさん
02/09/15 21:53 9W83Zx8U
良かったらうんこ板に遊びに来てくださいです。。
URLﾘﾝｸ(jbbs.shitaraba.com)
393:りお ◆/OjWxByc
02/09/15 22:09 tnovrUBN
漏れはWebObjectsマンセーなんだが、WebObjectsもイイところばっかしだけど、
悪いところもいくつかある。
EOFはSQLをほとんど意識しなくても良い便利極まりないフレームワークだけど
ちょっと凝ったレコードセット（EOっていうんだけど）の操作が必要になると
SQL書いた方がはやかったりもする。メンテ性を全然考えなくても良いような
システムでも同じでしゅ。あと、DBに強く依存するような機能を利用したい
場合も、ちょっとしたバグのおかげで使えなかったりするから、、とこれは
将来のバージョンアップで期待か。
他のアプリケーションサーバーではセッションフェイルオーバーが
標準で実現できているけど、WebObjectsは実現されていない。もっとも
プログラミング次第で実現できるのだけど、ちょっと面倒。EJBや
JSPなどとの連携もとれるようになったのも、EOFやWOFというテクノロジーが
あるのに何で連携しようとするん？と少しクビをかしげるときも（でも
冷静に考えると、あー、なるほどねと政治的背景をも少し感じるときもある）
WebObjectsは重いというイメージがあるけれど、決してそんなことはない。
PentiumIII-800Mhzで512MRam の赤帽Linuxで色々とアプリを動かしているが
スカスカうごく。レスポンスが重いと嘆いているのは、そりゃ作ったプログラマの
ウデが未熟だってぇことだ（←偉そうに(;´Д`)
なんか、微妙にすれ違いでスンマソン。ウチの会社ではデザイナには
WebObjectsで使うタグは<WEBOBJECT> </WEBOBJECT>だけだから、そこらへん
を少しだけ意識してください、と連携とってます。CVS使ってますけど。
WebデザイナはWebObjectsとプログラムがどいうカンジで動くのかを少しだけ
勉強してるだけです。
394:nobodyさん
02/09/16 05:58
おお、りおｻｿ降臨してるしｗ
395:nobodyさん
02/09/17 21:33 Zw7x1lTe
<age>
396:あぼーん
あぼーん
あぼーん
397:nobodyさん
02/09/21 02:17 fER+Pudx
ロジックとデザインの分離を語るとき、デザインには
ロジックはかかないが、代わりにロジックにデザインが入り
こんでいたりする。
デザイン主体で見るなら、少々ロジックが入り込んでも、
デザインは一つのファイルで完結したいなと思う。
どうせDreamWeaverとか使えば、コードを省略してくれたり
するわけだし。
なんもないデザインで、<TD>データ</TD><TD>データ２</TD>
ぐらいなら、ロジック側に入り込んでも影響ないけど。
398:nobodyさん
02/09/21 04:09
＞ロジックとデザインの分離を語るとき、デザインには
＞ロジックはかかないが、代わりにロジックにデザインが入り
＞こんでいたりする。
ｱﾌｫですか？
多いケースは、デザインにロジックが混入するｹｰｽだろ。
cgiしかやったことねーのか。
399:nobodyさん
02/09/21 18:14 bCEdfPyU
>>398
デザインにロジックを混入させたくないから分離するんだろボーケー
400:りお ◆/OjWxByc
02/09/21 19:38 n+jiSbS4
>>398
397はたう゛ん、JSPまわりのことを言っているのかもしれない。
HTMLタグとﾌﾟﾛｸﾞﾗﾑとSQLが混在するファイルを見ると少し混乱するのは確かすよね。
401:nobodyさん
02/09/21 20:06
>>400
WebObjectではページ内のループの概念とかってどうなってるの？
402:401
02/09/21 20:21
補足
例えばDBから複数のエントリを取り出してきてそれを表にするような場合、
WebObjectではどんなふうにやるのか知りたいage
403:りお ◆/OjWxByc
02/09/21 20:39 n+jiSbS4
>>401-402
まとめるから、ちょっとまっててクレ。
404:りお ◆/OjWxByc
02/09/21 20:49 n+jiSbS4
>>401-402
とりあえず、
ｽﾚﾘﾝｸ(php板:835-836番)
におれっち的なへんじをかいておきました。
わかりにくいかもしれまへんけど、ワカランことがあったら
何でも書いてﾁｮﾝﾏｹﾞ.
405:nobodyさん
02/09/22 12:12 bpmTH82o
>400
そうそう、Servletからforwardしたり、ASP.NETのコードビハインドが
ある前提で、メインロジックは後ろに追い出せた場合の話でした。
例えば、JSPだと単一の処理に頑張ってタグライブラリを書いてまでは、
分離する必要はないかなという感じぐらいのノリ。
りおさんのレス見させてもらいましたが、ASP.NETは、
WebObjectsに強く影響を受けてるなとつくづく。
ところで、WebObjectsは、MVCモデルのコントローラみたいに、
ロジックに応じて、Ｖをがらっと変えてしまう（Servletなら表示する
JSPページのファイルをサーバーサイドで動的に変える）ことって
簡単にできるんですか？
406:nobodyさん
02/09/23 15:16
MVCのCみたいに、の下りが漏れには理解不能なんだけど、
同じモデルの見せ方を動的に変えるなんてのは当たり前に出来ます。
てゆーかそれが出来ないアプ鯖なんか使い物にならなくない?
407:nobodyさん
02/09/30 21:50 l9Fp6ZzH
>>406
GUI アプリケーションじゃ「C」を分けとくと楽なんだな。これが。
ウィンドウをマウス or キーボード or リモート操作 で動かる構造にしとくとイイでしょ？
408:nobodyさん
02/10/12 20:07
＞＞405
できます。
ただし、それをやろうとしたら、周りがついて来れなかった。
ルーキー同士で組ませるなよぉ
409:nobodyさん
02/10/12 20:39
漏れも、Tomcat(藁)、WebLogic、ColdFusion、WebSphereとやったことあるけど、
WebObjectsは、独自技術かつ、それらの先を行き過ぎて、平均的スキルの開発者だと
手に負えないんだよな。。。。
いくらWebObjectsが凄いものでも、まともに扱える開発者を揃えられないと、
業務で導入できないんだよ。。。鬱
とはいえ、一人でも結構な規模に対応できるからいいんだけど。
410:409
02/10/12 20:49
とりあえず、View部分は、ロジックとまったく関係なく、デザイナ任せにできるから、楽で良いね。
「<WEBOBJECTS>タグの範囲だけは、削除せんといて～」と指示しておけば、
こっちは暫定Viewで作業できるし。
JSPみたいにViewにロジックが入るような事は一切無いのが素晴らしい。
しかし、そんなものは、はっきり言ってどーでもいいね。
Enterprise Object Frameworkを知ってしまったら、EJBとか使ってたのが
禿しくバカバカしくなった。。。
411:408
02/10/12 21:38
会社入ってから、
一画面丸ごと全部 コンディショナル（if節みたいなもの）で、
切り替えているコードを見たとき、
正 直 感 動 し ま し た 。
やるなよ… そんなダメダメなやり方、 この会社入るまで想像すら、しなかったよ。
学生だって、もっとましなコード書くよ。
412:408
02/10/12 21:46
コウじゃないぞ！！
<html>
***** ←条件により一部の表示を変える。
</html>
コウやってるんです。
<html>****</html> ← 条件により丸ごと置き換え
<html>****</html> ← しかもたくさん。
<html>****</html> ← 中身にも条件による表示切替ありのおまけつき。
413:nobodyさん
02/10/12 21:49
ここですか？
WebObjectsﾏﾝｾｰのスレは？
414:nobodyさん
02/10/12 22:11
>>413
どこがﾏﾝｾｰですか？
WOにも、欠点はいっぱいありますよ？
415:nobodyさん
02/10/12 22:15
>>413
ちがうぞ。>>412は、マンセーではなくてだな、逆なんだよ。
インターフェイスとポリモーフィズムで同じことが、
簡単かつ、わかりやすくできるのに。
416:nobodyさん
02/10/12 22:24
WebObjectsって2chではよく聞く名前だが、それ以外では聞いたこと無いな。
2chにエヴァンゲリストが入り込んでいるのか？
.NET死滅スレのMS厨みたいだ・・・
417:nobodyさん
02/10/13 00:35
WebObjectsは、日本では超マイナー製品だからな。
ｱｯﾌﾟﾙｼﾞｬﾊﾟｿも積極的に売ってないし、サポートもろくすっぽ無いし。海外ではかなり有名なんだが。
でも、ググってみると、いっぱい情報あるよ。
でも、電話系システムのバックエンドとか、航空管制システムとかで使ってるぞ。
金融会社では、昔ながらのNextStepやらOpenStepなんつー酔狂な環境で、
未だに古いバージョンが動いてるし（藁
"ObjectWeb"なんつー、ｵｰﾌﾟｿﾝｰｽのJ2EE対応のｱﾌﾟ鯖もあったな（藁
とはいえ、マイナー無名製品。
OOPをきちんと学んだ開発者でないと、さっぱり理解できない複雑性をモツ。
つまり、間口が狭く、学習曲線が緩い。
こんな製品が、今の市場にウケるわけがない。
418:nobodyさん
02/10/13 07:31
>417
どこの電話会社や航空管制施設なの？
金融系ってまさか銀行？
恐ろしい企業もあったもんだ。
その例はWOの信頼性を保証するもんじゃなくって、逆にそれをそこまで採用しちゃってる企業の危険度の尺度じゃない？
419:417じゃないっす
02/10/13 09:20
WOFは外部に公開しない部分で使われることが多いみたい。
信頼性はあんまりないよ、正直。
バグがぼろぼろ見つかるの。
420:nobodyさん
02/10/13 10:58
>>418
でも、WebSphereとかWebLogic、.NETなんかを使うよりは遙かにマシだろ。
証券会社なんかで、.NETに移行始めてるとこあるけど、
あぁいうのはどうなんだろうな？怖すぎて契約できないよ（ｗ
WOの信頼性は、どうなんだろう？
マカじゃないからよくしらなんだが、アップルストアって落ちたりしてんのかな？
(URLﾘﾝｸ(store.apple.com))
全世界の注文を、アメリカのアップル本社にある５台くらいのマク＋WO+オラ（Sun）
でさばいてるって言ってたよ。
421:nobodyさん
02/10/13 11:37
.NETを使うより遙かにまし？
ＭＳはうまいよ、プラットフォームを作るのが。
ある程度の信頼性を確保できたうえで、最近はそれなりの規模のウェアハウスの運用にまで耐えられる環境が実現できている。
TomcatだJSPだPHPだなんて騒ぐよりも遙かにましな選択だと思うぞ。
Site ServerとかCommerce Serverなんていう中途半端なβ製品を買わせてきてしゃあしゃあとしているのは相変わらずだけど、見誤らなければ良い選択肢がある。
企業としてAppleなんてのはカスで、そこがリリースしているだけで信頼性はゼロと見ていいよ。
信頼性なんてものは、将来性と双子の兄弟みたいなもので、将来性のない製品に信頼性なんて育つはずがないの。
そんなものを採用すると、１００％将来はこける。
ただでさえ存続するアーキテクチャなりプラットフォームの選択って微妙な問題なのに、わざわざ確率の低い方に賭ける意味は限りなくゼロに近い。
今までAppleが提唱してきてサードパーティーを乗りに乗せた風呂敷って全部びりびりに破けてるって事実を、もっと真剣に受け止めた方がいいぞ？
かってはApple UNIX構想が死に、DALは捨てられ、またゼロからの再構築を目論んだという経緯を持つ企業を、俺は絶対に信用しない。
WOなんて早晩くたばるよ。
OOP命ってことでそれがウリのコーダー様なら、さっさと.NETに来るべし。
ただし、しっかりと個々のアーキテクチャの勉強をする気のない似非OOPクンたちは挫折しないようにね。
最低限必要だよ、SQLを書けたりDBアーキテクチャの構造を理解し、そのクラスを効率よく扱えるテクなんて。
WO使いがあまりに生意気だから一言書かせてもらったさ。
ついでに一言、WOに対する比較なら素のASP（.NETじゃない）でもまだ上を行ってる・・・ってかまとも。
422:nobodyさん
02/10/13 11:46
>OOP命ってことでそれがウリのコーダー様なら、さっさと.NETに来るべし。
自分で言ってることが、よくわかってないようです。(ﾌﾟ
「ウリの思想は、マンセーニダ！」って感じですか。北ﾁｮｿみたいですね。
.NET厨があまりに生意気なので、一言書かせてもらいました。
ついでに一言、WOと素のASPを比較している段階で、WOをほとんど知らないってことがﾊﾞﾚﾊﾞﾚですね。
さらに付け加えると、長文の最後に「一言書かせてもらった」なんて、日本語もよく理解できないようですね。
そういう俺は、WOに憧れるWebLogic厨です。
423:nobodyさん
02/10/13 11:59
.NET? アフォですか？ .NET Framework? EJBの真似？ .NET Server? まだ製品も無いのに？
CLR? JavaVMの猿真似かい。 J#やらC#やら、節操がないよ。どうせJ++の二の舞。
もっとも、MSがCrossPlatformをまともに考えたら、C#はもしかしたら数年後に化ける可能性もあるが。
鳴り物入りでJ++を登場させ、WFCを推進し、そこに上った開発者のハシゴを、政治的な理由から
思いっきり蹴り外した経緯を持つ企業を、俺は絶対に信用しないね。
もちろん、穴は多いが、クライアント環境としてのWinは使いやすいし、Win用デスクトップアプリは
良くできてるものが多い。ゲーム環境としても、Winは最高だと思う。
しかし、サーバサイドアプリを運用する環境としては、最低最悪だな。
「開発」という側面だけに着目するから、多機能なIDEの評判などに、うまく誤魔化されてしまう。
ただし、運用開始後の多種コストを一切無視して、MS製品のみで固めるんだったら、
.NETという選択肢も有りだろうな。
424:nobodyさん
02/10/13 12:03
アフォはお前だよ。
C#とJ++ってのはそもそも比較の対象として違う。
J++ってのは単なる環境で、C#ってのは言語。
それにJ++が鳴り物入りだって解釈した開発者の気がしれんよ。
俺はまったく信用しなかった。
あんなもの過渡期の環境だって見りゃわかりそうなもんだ。
ってか、Javaって時点でＭＳがどこまで真剣にやるか考えてみた？
そんな梯子にうかうかのぼって行く方が間違ってんだよ。
425:nobodyさん
02/10/13 12:06
>>422
うん、いかにもWOにあこがれるWebLogic厨房だわな。
それからお前みたいなアフォは開発言語だけいじれ。
「一言書かせてもらった」は正しい日本語なんだよ。
日本語喋れんようなお前ごときにいちいち訂正されたかないわい。
クライアントの前できっちり案件に関して商談できるくらいになってから日本語については語れや。
426:nobodyさん
02/10/13 12:09
誤：J++ってのは単なる環境で、C#ってのは言語。
正：VisualJ++ & WFCってのは単なる環境で、J++とC#ってのが言語。
427:nobodyさん
02/10/13 12:12
WO厨房、MS厨房ともに必死すぎ（ｗ
スレの趣旨に戻れや。
そもそも、.NETやWOで、どこまでコンテンツとデザインを分離できるんだ？
具体例出せるのか？
話しはそれからだ。
くだらんフレーミングはやめろ。両方とも、目くそ鼻くそを笑う、でしかないな。
428:nobodyさん
02/10/13 12:29
>>427
それ、俺も興味あるな。
Webｱﾌﾟﾘで、ﾃﾞｰﾀﾍﾞｰｽから取得したﾃﾞｰﾀを、Web側に出力してやる部分を、
.NETやWOや他のﾂｰﾙで具体的に比較してみたい。
PHPやJSPとか今までのASPだと、テンプレート内にロジックを書けるタグがあって、
そこにSQL含めたコード書くのが普通だよね。
429:428
02/10/13 12:40
追加。
条件分岐が絡むHTML生成とか、繰り返し処理（HTMLテーブル作成等）を
Webｱﾌﾟﾘでやるにあたって、MVCをきっちり分けるってできんの？
430:408
02/10/13 16:41
なんか、妙な議論が… 私が発端かな？ ごめん。
WOF は、DB のテーブル、ビューを Java のクラスにすることができる。
ロジック（メソッド）をそのクラス内に追加することもできる。
インスタンス生成時に条件をつけて、持っているデータを変化させられる。（検索とかで使う）
Java クラスではなく、HashMap 系のインスタンスにすることも可能。
表示するページは、PHP や JSP のカスタムタグを使った時と似たような形式のHTMLと、
それに対応する Java クラスで構成される。
表示用の Java クラスにメソッドを追加すると、HTML の方でそれを呼び出すことが可能になる。
Java クラスなので、似たようなページの場合、同じクラスを使えば、手間を省ける。（もしくは継承）
ページ固有の処理はこちらに加えてる。
HTML の方は、JSP と似たようなものかな。
対応するクラスのメソッド、フィールドを呼び出せる。
リフレクションで、型に応じた処理を勝手におこなってくれる。
繰り返し処理部分は、か な り独特のロジックあり。
List List ←こういうListが、
├ HashMap ├List たくさん現れるのに最初戸惑った。
└ HashMap └List
.NETの方は、良く知りません。勉強不足です。
431:nobodyさん
02/10/14 01:13
>>418
金融系とは、ドイツ銀行と、昔派遣でいっていたかいしゃが契約していた
大手都市銀行と、、、いくつかです。信頼性云々よりかは、かいはつこうりつが高かったんで、
客先評判はすこぶるよかったですよ(pure.
432:nobodyさん
02/10/14 09:42
>>418, >>431
日本だとM菱銀行とかが使ってたよ。
といってもNeXT時代なのでWOじゃなくて、その前身のPDOとかだけど。
今のWOの売り方だと基幹系に採用されてるとか言っても信じられないのは
無理はない。もうそんなに先進的でもなくなっちゃったし。
433:nobodyさん
02/10/14 10:13
そろそろWOF以外の話きぼんぬ。
434:nobodyさん
02/10/14 10:24 ++3XMo/L
>>432
確かに先進的でもなくなってしまったけど、WOF特有のKeyValueCodingやEOFの
一貫性つうか、エレガントさはヨソのAP鯖で似たようなのが出てこないというか
むしろ不便を強いられているというのがちょぃと納得いかないんですが。。。
435:nobodyさん
02/10/14 12:54
漏れは、やはりWOのﾏｲﾅｰさから、早く他のｱﾌﾟ鯖に乗り換えたいんだけど、
WO並か、それ以上の製品が無いんだよなー。
お値段がやはり。。。
DB扱うWebｱﾌﾟﾘを、客のために作るんだったら、今のところWOしかねぇなぁ。。。
んで、.NETでのMVC分離の具体例が知りたいのだけれど、
暴れてたMS厨は、そういう例を出せるほどのｽｷﾙは無かったって事？
>>430も、具体例出してきたのは非常に好感持てるが、いまいち判りづらい。
436:nobodyさん
02/10/14 15:04
>>433
スマヌ、もう少し続ける。
>>434
KVCやEOFを他社が真似しないのは、ひとつにはこのへんの技術が
特許でガチガチに守られてるから、ってのがある。
しかもこの特許を持っているやつらはNeXT時代に次々と別の会社に
出て行っちゃって既にAppleにはいないので、WOがライセンスで潤うという
可能性もなくなってしまっている。もったいない話なんだよなあ。
437:nobodyさん
02/10/15 09:39
WOスレで聞いたほうがいいのかもしれないけど、、
>>436
その特許ってのは具体的にはどれのこと？
URLﾘﾝｸ(www.uspto.gov)
438:nobodyさん
02/10/15 20:29
WOネタはもうやめてくれ！
WOに触れる人が今後増える可能性があるのならともかく、
ここを見に来る大部分の人間にとって、WOの話はコンテンツとデザインの分離の話と
何の関係もない。
439:nobodyさん
02/10/15 22:31
>>438
何の関係も無いってのは、言い過ぎだと思われ。
WOに特化したコアな話題だったら当然、WOスレでやって欲しいところだけど、
WOでは、コンテンツとデザイン（というよりは、Model/Controlerと、View）が
完璧に分離できるっていうじゃん？
そこには興味あるから、今後の選択肢の一つとして、その点は知りたい。
マカ専用でもなさそうだし。Linuxでも動くんでしょ？FreeBSDではどうなの？
今、JSP+Servlet+JDBCなんだけど、なんとかしたいんだよな。
TagLibも、メンテナンスも考えたMVC分離って点では、今ひとつだし。。。
440:nobodyさん
02/10/15 23:11
>>439
とはいっても、400あたりからずっとWO続きなのは正直ウザイ。
MVCとかCodeBehindとかTemplateとかカスタムタグみたいな製品や技術に
比較的非依存な話題ならいいんだけど、（他の技術にも流用できそうだから）
WOの話ははっきりいって、いくらされても他の製品や技術に流用できるようには見えん。
> WOに特化したコアな話題だったら当然、WOスレでやって欲しいところだけど、
もはやWOに特化したコアな話題だと思われるが。
441:nobodyさん
02/10/15 23:23
ちょっと最近のスレを読んでみたけど、WebObjects語ってる香具師らは
何というか、「選民思想」みたいなのがあるな。
「先進的」とか「独特」とかいう単語を並べて自分に酔っている。
>>409なんてほぼ自己陶酔に近い。
で、マニアックなのを逆に誇っているような・・・。
とりあえず、J2EEサーバや.NET、ASPといった競合技術を子馬鹿にしたような
発言は余計だったかな？
cocoonとかの話をもっと聞きたかったな。
442:nobodyさん
02/10/15 23:35
はいはい、ここで暴れてるWO厨ども、まったく意味無いから、本スレに帰ってくるように。
WOは、ｱｯﾌﾟﾙ(J)社内でも認知されない妾の子扱いだから、あまりよそ様の目に触れてはいかん。
選民意識は持ってていいが、外には出すな（ｗ
つーわけで、迷惑掛けてｽﾏｿ＞このｽﾚ住民殿
興味あるなら、WOｽﾚにｳｪﾙｺﾒ。
443:nobodyさん
02/10/15 23:40
>>441
自己陶酔ってのは、端から見て確かにｷﾓｲが、毎日使う道具だったら、惚れて使う方がよくねぇ？
包丁だって、ﾅﾏｸﾗに文句言いながらよりは、私見でも「よくｷﾚるｼﾞｬﾈｰｶ」って思いこんだほうがいいと思うが。
J2EE/.NET/ASP共に然り。どの分野にも、極めた人間ってのはいるからな。
Perl使ってEJBも真っ青はﾛｼﾞｯｸ組む香具師もいるし。
駄文ｽﾏｿ。んじゃ。
444:age
02/10/15 23:48 pfYG+Byr
ビジネスロジックとデザインの分離とはちょっと話がずれるが、
ロジックのコンポーネント化というのはどうなのかな？
俺はPHPの中に普通にロジックをガリガリ書いてしまうほうなんだけど、（あとはincludeとか）
やっぱバイナリのコンポーネントにくるんでおいたほうがメリットはあるの？
ASP→COM/COM+
J2EE→JavaBeans/EJB
.NET→.NET Assembly
PHP→ねぇよ
って考えると、コンポーネント仕様を持たないPHPが中途半端に見えるんだけど。
ビジネスロジックのコンポーネント化についてばっさり意見を言える神の説明ｷﾎﾞﾝﾇ。
445:nobodyさん
02/10/15 23:51
自分が不案内な技術がやたらと目に付くようになったときに、それをウザイと思うか
そんなにいうなら調べてみようじゃねーかと思うかでは、その技術や
背景になっている枠組への理解度が違ってくると思うのだが。
結局このスレがWO厨だらけになって他の話題が出てこないってことは、この
「コンテンツとデザインの分離」っていうトピックに興味を持つ人間の割合が
WO厨は他と比べて多いってことなんだろう。
どうせなら、なんで他の環境のやつらが熱く語ってくれないのか、ってあたりを
問題にしたいところだが。
446:nobodyさん
02/10/15 23:57
> 自分が不案内な技術がやたらと目に付くようになったときに、それをウザイと思うか
> そんなにいうなら調べてみようじゃねーかと思うかでは、その技術や
> 背景になっている枠組への理解度が違ってくると思うのだが。
ここらへんは同意できるのだが
> 結局このスレがWO厨だらけになって他の話題が出てこないってことは、この
> 「コンテンツとデザインの分離」っていうトピックに興味を持つ人間の割合が
> WO厨は他と比べて多いってことなんだろう。
ただ単に他の奴等が逃げ出したのでは？
ただでさえ過疎化著しいWebProg板で、他のネタが書けないような雰囲気になってしまえば
ＷＯ以外の書き込みがなくなるのも無理はない。
ちなみに「コンテンツとデザインの分離」というトピック名称には普通興味は持たないわな。
「ロジックとデザインの分離」には興味を持つ人間も多いだろうが。
447:nobodyさん
02/10/15 23:59
>>444
もちろん出来たらメリットはあると思う。てゆーかそれがやりたいと
みんな思ってるけどなかなかキレイにくるめないんだと。
問題意識とズレるかも知れないけど、Zope/CMFでやってる、
ワークフローのオブジェクト化なんてのはロジックのコンポーネントと
言ってもいいんじゃないかな。EJBでああいうことをやるのは不可能に
近いとは思うけど。
448:勝手ﾆ仕切ｯﾃｽﾏｿﾝ
02/10/16 00:29 wAz0M52D
まぁなんだかんだいって450近くまでスレが伸びるというのも、それだけ多くのWebプログラマが興味を持っている分野だということだね。
これはCGI屋、PHPﾏﾝｾｰ派、J2EEﾜｼｮｰｲ人間、MS工房とかいった人種の壁を越える共通問題だと思うYO。
で、結局ロジックとデザインの分離方法は技術によってけっこう主流が違うんだなぁということが分かったんだけど、
だいたい以下の4パターンくらいに分類できるということなのかな？
Template型
=>Perl-CGIのHTML::Template、PHPのSmarty等
MVCデザインパターン型
=>ASP(中途半端)、J2EE(Servlet+Bean/EJB+JSP)等
カスタムタグ型
=>J2EEのJSP、ColdFusion等
Codebehind型
=>ASP.NET
XML+XSLT型
=>CocoonのXSP
(WOは知らん。特殊らしいからこの中には分類できん。)
ちょっとここらへんたたき台にしてスレの方向転換＆中間まとめしてみない？
（あまり宗教対立や部落紛争を起こさぬように･･･）
449:nobodyさん
02/10/16 00:30
>>444
そのためのルールベースエンジンじゃねえのか？（ｗ
450:nobodyさん
02/10/16 01:02
厨な質問かもしれないけど、１点確認したい。
WOの話題がNGってことは、商用製品におけるロジックとデザインの分離方法を
このスレで語るのはダメってことかい？
基本的にフリーで利用できる製品のみが対象？
WO厨ってなじられることを覚悟でﾊﾟﾋﾟｺすると、
なぜWOの話題は嫌われるの？ﾏｲﾅｰすぎるから？
選民意識が強いっていうのは、NGにする理由にならないと思うんだけど。
451:450
02/10/16 01:04
んーと、このスレは、
コンテンツ（というよりロジック）とデザインの分離に関する技術的話題を扱うスレだよね？
452:nobodyさん
02/10/16 01:08 AoJOl8Ws
>444
どっかで、Win-PHPはCOMが使えるって言ってたよ。
でも、ASPでもCOMは避けたいねぇ。管理ウザイから。
開発環境で、似たようなアプリが増えてくると、
かなーりブルーだよ。目の前のが動いてるつもりで、
違うフォルダの古い奴が動いてたり(^^;
PHPは、やはり元々、Perl+αかつ ASPの対抗製品だから、
そんなもんじゃないすか？ネームスペースの切り方からして、
お手軽さの方が重視されてると思うし。次は、ColdFusionみたいに
Java化するんでしょ？そうなれば、Servletをアシに使えるのでは?!
453:nobodyさん
02/10/16 01:17 AoJOl8Ws
>448
漏れの印象としてはWOは、ASP.NETのサーバーサイドコントロールと
同じに見える。（Codebehind?)
454:nobodyさん
02/10/16 01:46
WOスレはかなり宣伝入ってると思われ。
現実では、WO使ってると言う話はほとんど聞きません。
455:nobodyさん
02/10/16 02:01
だから、WO厨は、本スレに戻ってこいって。
WOユーザーでさえWOをまともに理解できてないﾔﾂ多いんだから、
一般的開発者に語ったところで、「宣伝」「自己陶酔」「選民意識」って言われるのがオチ。
世間の見方なんて、WOユーザーとマカは同レベルでしかないんだよ。
どうせお前ら、WOF+EOFを語りたいんだろ？本スレで思う存分やろうぜ。
はい、撤収～撤収～
456:nobodyさん
02/10/16 02:27
>>448
その分類あんまりフラットじゃないと思う。
MVC型ってたぶんStrutsかなんかをイメージしてるんだと思うけど、
それを実現するためにはテンプレートやカスタムタグの存在が基礎に
なってるわけで、並列するようなもんじゃないでそ。
J2EEとだけ言ったんでは分離もくそもあったもんじゃない。
が、しかし、なんか中間結果をまとめたいというのは禿しく賛成。
457:nobodyさん
02/10/16 19:51
>>454
それって、あなたの周りだけのハナシでは。
部分をもって全体を語るな。
458:nobodyさん
02/10/16 21:16 wAz0M52D
Template型にはJavaのVelocityもあるな
459:nobodyさん
02/10/16 21:19 wAz0M52D
＞WOの話題がNGってことは、商用製品におけるロジックとデザインの分離方法を
＞このスレで語るのはダメってことかい？
商用製品そのものの独自思想はちょっと控えたほうがいいとは思うが、
例えばJ2EEみたいに規格があって、それに対してTomcat、JBossからWebSphere、WebLocigまで
様々な製品実装があるようなものは問題ないと思う。
ケースバイケースだな。
あまり書き込みルールみたいなのを設けると過疎化が進む。
460:nobodyさん
02/10/17 00:13
つーか、WOの話題はWOスレでやれ！
特定の製品は歓迎されないよ。
で、wo使って作られてるサイトってどんなん？(jpドメイン
461:nobodyさん
02/10/17 00:15
>>460
URLﾘﾝｸ(www.apple.co.jp)
462:nobodyさん
02/10/17 09:01
>>461
本当に航空関連（えあどぅ）でWOが使われているとはしらなんだ...
463:nobodyさん
02/10/17 12:09
エアドゥとかで使われてるのは、Webアプリだよね。
C/Sタイプのアプリも開発できて、それはSybaseと一緒にNTTの基幹システムで動いてる。
ただしそれは、NTTが事例としての引用を認めてない。
NHKも社内で使ってるが、こちらも同様。
WOスレ行くと、WOが持ってる技術特許へのリンクも見られるぞ。
464:nobodyさん
02/10/17 18:08
ウチがlinux/phpでリプレイスやってるサイトある(ﾟдﾟ)！
紹介されてるサイト結構、既にcgi/aspなんかになってるやん。
URLﾘﾝｸ(www.ablic.net)の求人探索1/3ぐらいの確立でパラメータが
エラーとかでるよ(;´Д`)
465:nobodyさん
02/10/17 22:34
>>WOスレ行くと、WOが持ってる技術特許へのリンクも見られるぞ。
みたYO. 糞ﾏｶｰ共がﾏﾝｾｰﾏﾝｾｰする理由がよくわかったYO(W
466:nobodyさん
02/10/20 08:58
WO厨の気がすんだら書き込みなくなるわけね。
467:nobodyさん
02/10/20 13:47
>466
WO使っている連中なんてそんなもんだよ。
一昔前のMac馬鹿と同じ（藁
468:nobodyさん
02/10/20 14:32 9WgqBhUQ
>>467
そういうならWO以外のネタを出してくれ。
469:nobodyさん
02/10/20 17:15 qpipozpW
Cocoonって何がすごいのかよくわからないんだけど、
WO厨なみに製品ﾏﾝｾ-して説明（洗脳？）してくれる人ｷﾎﾞﾝﾇ
470:nobodyさん
02/10/20 22:00 bYFhkOye
>468
ネタっていうか、そもそもビジネスロジック自体がページという概念から切り離せないWebアプリケーションの世界で、どうやってロジックとデザインを分離するってことを考えるのかわからん。
どのようなWebアプリケーションの環境においても、所詮クライアント環境に吐き出すものは毎回サーバが提供しなけりゃならない。
こんなモデルってのはいままであり得なかったわけでしょ？
UIが素っ気ないものでいい（究極はVT100アクセスで利用したようなキャラクタベースのコマンド）ならまだしも、高価な実装が期待されるんだから無理もはなはだしいんだよ。
どうあがいてもステートレスのサービスっていうとんでもない前提の制約がある上に、その上塗りがあるんだからどうしようもない。
そもそも分離したらWebアプリケーションとしての体をなさない世界で分離を考えること自体がナンセンス。
一番の早道は、デザイナーがコーディングに近づくのでなく、デザイナーがパーツ化したデザインと組みあがったUI部分の実体を提供して、それをコーディングする側が適切に配置できるように訓練することだよ。
デザインも断片化したコードの一部としてプログラマーが取り扱う以外ないだろうと考える。
その結果はある程度のprint構文（あるいはヒア構文）の混在は避けられないし、合理的だ。
471:nobodyさん
02/10/20 22:10
>>470
激しく同意。2行目からは読んでないけど。
で、どこを縦に読めば良いの？
472:太郎
02/10/20 22:22 CP0XcMB5
無料サイト総合案内室わつくりますた。
情報量は知り合いの友達よりも結構多いです。
あと無料ソフト集もあるのでねダウソしてみては 。
あと、このサイトの正式タイトルを考案中ですので応募してみては。
あとアンケートにも答えてみては。
URLﾘﾝｸ(www31.tok2.com)
473:nobodyさん
02/10/20 22:54
>ネタっていうか、そもそもビジネスロジック自体がページという概念から切り離せないWebアプリケーションの世界で、
>どうやってロジックとデザインを分離するってことを考えるのかわからん。
>どのようなWebアプリケーションの環境においても、所詮クライアント環境に吐き出すものは毎回サーバが提供しなけりゃならない。
ネタですね？（ｗ
ネタにマジレスしてよかですか？
例えば、PHPとかJSPで、デザインにSQLとか条件分岐によるHTML出力処理とかが、
バリバリに入っているという、よくあるタイプのWebアプリがあるとする。
当然、実装的には問題無いわけで（ほんとか？）、完動すると。
しかし、運用開始後に仕様変更や拡張があった場合はどう？
デザイナにHTMLテンプレート部分を担当させてたとして、
デザイナの仕事が終わらないと、コード部分も修正できないってことは無い？
同じ動作をする、暫定テンプレートを別途作るという無駄な作業する？
他にも、いろいろメリットあると思うけど。
だからこそ、JSPのTaglibとか、いろいろ出てきてるんだと思うんだが。
間違ってる？
474:nobodyさん
02/10/21 04:33
HTMLにロジックが入ってるだけやん。←tagライブラリ
それと、ロジックにHTMLが入った(php/asp)のも大差ないような気も。
ロジックの再利用ができるって意味でのタグライブリ、
デザインの再利用を(主に)するのがテンプレート技術？
475:nobodyさん
02/10/21 04:34
どっちも再利用しなきゃ意味がないと・・・OOと一緒か。
476:nobodyさん
02/10/21 06:40
>471
だからさ、WO厨はあっちイケよ。
いらない。
>473
> だからこそ、JSPのTaglibとか、いろいろ出てきてるんだと思うんだが。
> 間違ってる？
だからさ、それが根本的解決策にはなり得ないってことは、UI＆フロントエンド、ビジネスロジック、バックエンドまで一貫してごりごり設計＆コーディングまでやってればわかるってことだよ。
完全に分離なんて無理だって（笑）
オープンソースが世界を変える、携帯電話で空を飛ぶってのと同レベル。
それからきみが書いていることは「そうなればいいな」ってことや「それって問題じゃん？」って提起なだけ。
指摘していることが問題じゃないなんて誰も言っておらん。
問題ではあるけれど本来解決し得ない問題もある。
だから無駄な抵抗を止めて本質を見レと言ってるのね。
>474
まさにそういうことだね。
HTMLにロジックが混在しているか、ロジックにHTMLが混在しているかってところがせいぜいなんだよ。
それ以上にも以下にもならん。
>475
再利用するっていうのは必須の発想だよね。
不可能な分離を考えるのでなく、いかに現実的な解決メソッドを編み出すかにつきると思うんだ。
477:nobodyさん
02/10/21 08:20
ネタなのかなぁ？
>>476
>HTMLにロジックが混在しているか、ロジックにHTMLが混在しているかってところがせいぜいなんだよ。
>それ以上にも以下にもならん。
ここで言っているロジックって、UIのビヘイビアに関するロジック(表示ロジックと呼びますか)だよね？
で、>>470で話している、
>ネタっていうか、そもそもビジネスロジック自体がページという概念から切り離せないWebアプリケーションの世界で、どうやってロジックとデザインを分離するってことを考えるのかわからん。
この文の最初に出てくる（ビジネス）ロジックと、後の文のロジック、476の文章の結論が結びつかないんですけど？
476はビジネスロジックと表示ロジックがちゃんぽんになってませんか？
休暇申請するシステムを作るとして、
「有給休暇残日数ー有給休暇申請日が０以下の場合は、申請拒否」というルールを
プログラムにしたのがビジネスロジック。
「上のビジネスロジックの結果、拒否された場合、赤表示。認可された場合は黒表示。」
という入出力仕様をプログラムにしたのが表示ロジック。
この前提だと、ビジネスロジックはWebページと完全に切り離されて考えられるのでは？
476が言いたいのは表示ロジックのことだとすると、表示ロジックとデザインは切り離せるものじゃない、という意見には賛成。(デザインに依存してコーディングせざるを得ないだろうから）
478:316
02/10/21 09:22
>>469
よし語ってやろう。何が聞きたい？
取り敢えず、新人の女の子と楽しく仕事できるというのがCocoon2の最大の売りだ（ｗ
479:nobodyさん
02/10/21 22:31
>>316
316じゃないが、その売りだけで完璧だよう
480:469
02/10/22 00:10 3vYtKYtk
質問その１
どういうWebサイトを作る時にCocoonはメリットがあるの？
質問その２
Cocoonではどうやってロジックとデザインの分離を実現するの？（一応スレの内容に合った質問として）
質問その３
うちの職場は男しかいないんだけど、Cocoonを使って開発したらカワイイ新人の女の子が入ってくる？
481:nobodyさん
02/10/22 00:39
Cocoonをある程度の規模の開発案件に適用したとして、
サポートしてくれる企業ってある？
いざって時にサポートしてくれるものでないと、ビジネス用途だとむずい。
お前らの仕事だと、そこまで厳密さは要求されないのですか？
482:469
02/10/22 01:01
>>481
それって、Cocoonに限らずオープンソースのソフトウエア全てにいえることでは？
PostgresSQL、MySQL、そしてApacheを導入してシステムを構築している企業なんて今時金融機関を含め山ほどあるでしょ？
Cocoonと同じApache XMLプロジェクトの配下にはXercesやXalanなんて大物もいるしね。
まぁでも不安になる気持ちは確かに分からなくもない。
俺も、Apache Web ServerよりもIBM HTTP Server powered by Apacheのほうが安心する。
483:nobodyさん
02/10/22 01:08
＞俺も、Apache Web ServerよりもIBM HTTP Server powered by Apacheのほうが安心する。
結局、これなんだよな。。。
モノは同じでも。
484:nobodyさん
02/10/22 03:04
>>481
リスクのないところにリターンはありません。
大事なのはリスクをいたずらに避けずにしっかりと計量することです。
それができない事業主体はSIerにぼったくられても仕方ありません。
485:316
02/10/22 13:25
>>480
＞質問その１
＞どういうWebサイトを作る時にCocoonはメリットがあるの？
一言で言うと、力技でたくさんコンテンツを作る必要があるサイトだな。
Cocoon2自体は、ローテク同士の接着剤の役目を果たす。Webアプリケーションを
ごりごり作るというよりも、大量のコンテンツが並ぶサイトを構築するための
ものだ。
もちろん、ありがちなショッピングカートみたいなものを作るのも結構
簡単なんだが、それは他のソリューションでも同じように出来る。
Cocoon2が便利なのは、元ネタは殆ど同じなんだが、見せ方やら使い方が
色々で、しかもそれがべらぼうに多くて、という場合に、どんどん楽になる。
XSLTに対してすんなり入れるなら全然OKだろう。XMLのありがたみを最大限に
活かしてくれる枠組みという感じだ。
486:316
02/10/22 13:30
＞質問その２
＞Cocoonではどうやってロジックとデザインの分離を実現するの？（一応スレの内容に合った質問として）
まず、Cocoon2の肝はサイトマップという仕組みにある。
サイトマップの中でコンテンツごとにパイプラインというのを定義していく。
サイトマップ自体はXMLファイルだが、これを読み込んで動的に
Servletに変換してくれるというのが秀逸だ。
さて、サイトマップに書くパイプラインの簡単な例は、こんな感じになる。
<map:pipeline>
<map:match pattern="hello">
<map:generate src="hello.xml"/>
<map:transform src="hello.xsl"/>
<map:serialize type="html"/>
</map:match>
</map:pipeline>
これはブラウザからURLに、URLﾘﾝｸ(localhost)～～～/helloと指定すると、
まず、hello.xmlというファイルを読み込んで、そこにhello.xslというXSLTを
適用し、最後にHTML形式に変換して返信するという定義だ。
487:316
02/10/22 13:33
ここで面白いのは、URLは何でもOKだということだ。
実体のファイルとは関係ない。
さて、元ネタが同じで、見た目だけ変更するにはどうするか。
この場合は、もうひとつパイプラインを追加して、適用するXSLTを別個用意すればOKだ。
<map:pipeline>
<map:match pattern="hello2">
<map:generate src="hello.xml"/>
<map:transform src="hello2.xsl"/>
<map:serialize type="html"/>
</map:match>
</map:pipeline>
これはサイトマップファイルに追記するだけで、on the flyでServletに
なる。どうだ、便利だと思わないか（藁
488:316
02/10/22 13:37
しかし、これでは質問への答えになっていない。ロジックはどうするのか、という
問いだ。ここで考えてみて欲しい。コンテンツを生成するときのロジックとは
元ネタのXMLを動的に生成することだということだ。そこで、Cocoon2では
XSPというものを使う。
<map:pipeline>
<map:match pattern="hellodb">
<map:generate src="hello.xsp" type="serverpages"/>
<map:transform src="hello.xsl"/>
<map:serialize type="html"/>
</map:match>
</map:pipeline>
こういう記述をすれば、XSPを実行できる。実行した結果、XMLがメモリ上に
生成されて、こいつにXSLTが適用されるという按配だ。
489:316
02/10/22 13:40
勘のいい香具師なら気付いたことだろう。
そう、これは分業が可能だということだ。
ダミーのXMLを用意しておいて、XSLTの作成をする奴と、
そのダミーのXMLどおりのものを生成するXSPを書く奴とで別個に
作業できる。
最後に、サイトマップで合体すればOKという風になる。
しかも、それぞれは普通のエディタだけで作業可能だ。もちろん
XMLエディタや、DreamWeaverのようにXHTMLを書けるツールを使うことで
生産性をUPできる。
490:316
02/10/22 13:42
XSPのポイントは、決して見た目の中にロジックを埋め込んでいるわけでは
ないということだ。あくまでも、元ネタとなるデータの生成にロジックを
使うわけだ。
それに独自タグは一切不要だ。何故なら、単純なXMLとXSLTをくっつけているだけだからだ。
昼飯を食うので、続きは後ほど書く。
491:316
02/10/22 13:53
さて、分業という点で言うと、
XSPプログラマ(M)
XHTMLデザイナー(V)
XSLTプログラマ(C)
という分担が可能になる。XSLTはちょうどSQLプログラミングと同じような
感じだから、手続き型言語におけるプログラミングとは、また風情が違う。
XSPのロジックは、Javaで記述する。Servletになるのだから当然だな。
だからJavaで出来ることは何でもOKだ。
492:316
02/10/22 13:56
同じURLで、複数のUser-Agentごとに見た目を変更するのも簡単だ。
<map:pipeline>
<map:match pattern="hello">
<map:generate src="hello.xml"/>
<map:select type="browser">
<map:when test="imode">
<map:transform src="hello_imode.xsl"/>
</map:when>
<map:otherwise>
<map:transform src="hello.xsl"/>
</map:otherwise>
</map:select>
<map:serialize type="html"/>
</map:match>
</map:pipeline>
このように、ブラウザセレクタを使って、適用するXSLTを変更することが出来る。
だからもう、URLﾘﾝｸ(i.)～～やら、http://～～/iなどとして、分離する必要はない。