[Seasar-user:13715] Re: [Teeda] DynamicPropertyのid

[Masao NADAI]

> > > <span id="xxx" class="T_omittag" />
> (略)
> > <span id="xxx" class="foo T_omitid" />
(略)
> > こちらも、実装していただけないでしょうか。
>
> たぶんしません．
> 理由は
>
> > > が，class 属性を活用するのは評判がよくなくて
>
> です．

了解です。

> > > > ただ、"this"は、入れて欲しいです。
> > >
> > > これは無しということで．
> > > xxxMessage や xxxLabel 等の接尾辞の意味を
> > > 打ち消すには不自然なキーワード＆用法なのと，
> >
> > 接尾辞の意味を打ち消すキーワードではなく、
> > 明示的にPageクラスのプロパティを参照するキーワードです。
>
> つまり，このキーワードには
>
> ・Page クラスの
> ・プロパティを
>
> という二つの意味が込められているわけですよね．
> そして現状必要なのは，xxxMessage という
> プロパティを表示したい場合など，
>
> ・プロパティを
>
> の方ですよね？
> これを言い換えると，
>
> ・(メッセージでもラベルでもなく) プロパティを
>
> です．
> それに対して this というキーワードは
> 不適切で応用が利かないということです．

thisに2つの意味が含まれていることが問題なのですね。

> つまり，
>
> ・プロパティを
> ・メッセージを
> ・ラベルを
> ・～を．．．
>
> というように展開できないのです．

<span id="dept.name">部門名</span>
も
・deptオブジェクトの
・プロパティを
という二つの意味が込められているんじゃないですか？

> > > id 値を使うのであれば，
> > >
> > > <span id="property:xxxMessage" />
> > >
> > > のような形の方が直感的だし，
> >
> > propertyというプロパティ名が使えなくなり（互換性を
> > 損ね）ませんか？
>
> property: はその右がプロパティであることを示す意味で
> 書いたもので，これ自体はプロパティ名ではありません．
> よって，Java のキーワードと重なっても問題は微塵も
> ありません．
> # とはいってもこの案もたぶん採用しませんが．

XML的にダメだからですか？

<span id="property--xxxMessage" />
<span id="property..xxxMessage" />
とかはどうでしょうか？
自分で言ってて、イケてないなぁと思っていますが。

> > > <span id="message:xxx" />
> > > <span id="label:xxx" />
> > >
> > > のように応用も利きます．
> >
> > <span id="message.xxx" />
> > <span id="label.xxx" />
> >
> > で、よいのでは？
>
> property: と同様に，message: はその右の
> プロパティに対するエラーメッセージの表示，
> label: はその右をキーとするラベルを表示
> するという意味で書いたのですが，おそらく
> 誤解しておられますよね？

誤解してました。
単に
> <span id="message:xxx" />         <!-- xxx に対するメッセージ -->
を表したいのかと思ってました。

>  public MessageDto message;
こういう使い方を想定していませんでした。すいません。

> > > これも個人的な考えですが，テンプレートの妥当性に
> > > ついては，XHTML 名前空間の要素・属性だけ取り出して
> > > valid であれば，まずは十分ではないかと考えています．
> >
> > そうですか。
> > 私は、モックもプロジェクトの成果物なので、
> > これも validであるにこしたことはないと思います。
>
> その成果物は Teeda で処理するテンプレートであって，
> 公開される XHTML そのものではない，ということです．
>
> モックとして「も」ブラウザで確認できるように配慮は
> しますし，それが Teeda Extension の売りの一つですが，
> それが無条件で valid であるべきとまでは考えていません．
> XHTML ボキャブラリに関して valid に記述できれば，
> モックとしての役割は完全に果たせると考えています．

私も、それが無条件で valid であるべきとまでは考えていません。
validであるにこしたことはないと思ったまでです。

> > > 最近の Teeda は condition や foreach を使える要素が
> > > 増えたので随分と改善できたと思いますが，それでも
> > > まだまだ表現力不足なので，そっちを何とかしたいなと．
> >
> > 業務系システムでは、十分な表現力です。
> > どのようなことをお考えなのでしょうか。興味津々。
>
> できる・できないという意味では十分な表現力を
> 持ってるかと思いますが，例えば条件によって
> 動的な内容を持つ <script> を出力するという場合，
>
> <div id="isXxx">
>  <script type="text/javascript">
>    <span id="script" te:omittag="true"></span>
>  </script>
> </div>
>
> のようになってしまいます．
> これは冗長だし直感的でもありません．
> これを
>
> <script type="text/javascript" te:if="xxx" te.out="script">
> </script>
>
> のように書けるようにしたいと考えています．

もはや、デザイナーの理解できる範疇を超えているような。

<script id="isXxx" type="text/javascript">
  script
</script>
では、ダメですか？

> > > テンプレートが valid であることにこだわるなら，
> > >
> > > http://www.w3.org/TR/MathML2/appendixa.html#parsing.module
> > >
> > > みたいに，XHTML1.1 のモジュールに Teeda 独自の
> > > 要素・属性を加えた DTD を用意すればいいだけじゃ
> > > ないかと言ってみるテスト．
> (略)
> > 詳しく知らないのですが、理にかなっているような。
>
> そう思うのはどうかと．(^^;
> オレオレ DTD で valid であることに何の意味が
> あるのでしょうか？

オレオレDTOとは、思っていません。
立派にTeedaが提供しているDTDです。
プロジェクトの方針として、Teedaを採用したならば、
そのTeedaが提供するDTDに意味はあります。
成果物の品質はTeedaに保証されているのです。
/*
例えが適切かどうかわかりませんが、例えば、
Java 1.4で書いたソースコードを1.5でコンパイルすると
警告が出ます（genericsのあたりとか）。
でも、プロジェクトの方針として、1.4のコンパイラを
使用すると決めていれば、1.4コンパイラに一定の品質が
保証されているのです。本質的な品質は変わらないのに。
*/
すいません、何を言いたいのかわからなくなってきたので
コメントアウトしました。

> valid であることが目的化しちゃってるんじゃ
> ないでしょうか？

確かに、valid であることが目的化しちゃってるフシは
あります。
その理由は、以下に少しふれます。

> 何のために valid を目指すのか考え直した方が
> いいのでは？

何のために？と言われれば、成果物の品質を一定基準に保つ
ためと答えます。
ただし、必ずしも valid = 品質が良いとは思っていません。
でも、validでない = 品質が悪いと無条件で判断する
オヤっさんもいるのです。それは誤解なのですが、できるだけ
、そのような誤解を未然に防ぐ努力をしなければならないSIer
の立場もご理解いただければ幸いです。
警告だらけのソースコードでもちゃんと動作しますが、
やっぱり納品物はキレイにしたいと思うのがサガです。

ちょっとグチっぽくなりましたが、ご検討ください。