[seasar-dev:507] Re: [S2JFace] DTDの変更について

KOMORI Yusuke y-komori ＠ nifty.ne.jp
2006年 8月 31日 (木) 22:07:54 JST 

　小森です。

　bskuronekoさん、DTDの検討、本当にありがとうございます！

> 1. プロパティは属性よりも要素の方がいいのではないか
> 今は各コントロールが持っているプロパティを
> 属性に記述するようにしていますが、
> これを要素にした方がよい気がしています。
> 
> 理由：
> 　・Font、Layout、TableItemのような複雑な型を書きやすい
> 　・テンプレートXMLが編集しやすくなる
> 　・直接書く場合と別の場所の定義を参照する場合の
> 　　両方を同じ場所で書ける
> 　　（Font要素をtemplate直下に記述してそれを参照するといった
> 　　ことが簡単にできるようになる）

　いろいろ考えてみましたが、基本的には今のまま属性に記述するほうがいいと
思います。


■ 0.1版 と 0.2 版の比較

    　試しに、現在サンプルとして付属している「DIでジャンケン」の画面定義
    XMLを bskuroneko さんが作ってくださった 0.2 版のDTDで書き換えてみま
    した。

    　0.1版のDTDでは 63行 あったのが 0.2 版では 36 行と大幅に減っていま
    す。（添付ファイルを比較してみてください）
    　全体としてもこちらのほうがスッキリして読みやすいと思います。
    　なので、基本方針としては今のままでよいと思うのです。(実際に自分で
    書いてみたところ、補完がきくのはかなり気持ちイイですね)


■ フォントやレイアウト定義の再利用について

    　つぎの問題としてフォント属性やレイアウト(特にレイアウトデータなど)、
    同じものを複数箇所に記述する場合どうするか、です。

    　これには、２つのアプローチがあると思います。

        １．１カ所で定義しておいて、参照する方法
                (bskuronekoさんが書いてくださった考え方)
        ２．親の属性を自動で引き継ぐ方法

    　現在の S2JFace は、２のアプローチを取っています。
    　添付の DIdeJanken2.xml でも、

<shell id="janken" text="DIでジャンケン" images="container.gif" background="white"
    foreground="black" fontHeight="50">
    
    　となっていますが、background、foreground、fontHeight の各属性は、
    レンダリングの段階で shell 要素の子である 各 label や button 要素に
    自動的に引き継ぎます。(実は、このへんの引き継ぎをどうするかという情
    報を持っているのが、現在の org.seasar.jface.renderer.info 配下のクラ
    ス群です)

    　こうすることで、 各 label 要素に同じ属性を毎回書かなくて良いように
    しているのです。

    　仮に、１のアプローチを取ったとすると・・・

<template>
  <font name="default" background="white" foreground="black"
  fontHeight="50 />
    ・・・・
  
  <label font="default" ・・・>
    または
  <label ・・・>
    <font ref="default" />
  </label>

    と、結局記述量が増えてしまう気がするのです。

    　もちろん、最終的には１のようにフォントやレイアウトスタイルを別定義
    する方法も必要と思うのですが、そのためだけのために他のすべてのものを
    属性から要素へ変更する必要はないと思います。
    (パーサが大変・・・という本音もほんの少しだけあります(^^;)
    
    　あと、TableItem や TreeItem まわりについては、いまのところあまり真
    面目にSWTを反映しなくていいと思います。
    
    　というのは、現実論としてアプリケーションを作る場合、内容が固定して
    いるテーブルやツリーはあり得ないので、JFace の TableViewer や 
    TreeViewer を使うことになるからです。
    
> 2. スキーマをXMLSchemaにしたい
> 現在はDTDでスキーマを定義していますが、
> これをXMLSchemaにしたいと思っています。

    　すみません、こちらは私も不勉強なので、なんともいえません。
    　数年前に Relaxer を勉強したことがあったのですが、型定義等がしっかりで
    きるのは安心感がありますよね。
    　その方が スキーマ定義しやすいのであれば、一考の価値ありと思います。
    
    　気になるのはバリデーションです。現在使用しているSAXパーサではDTDに
    よるバリデーションを行ってくれますが、XMLSchemaの場合ってどうなるの
    かご存じでしょうか？（逆にJAXBを利用しなければならなくなる？？）
    
    　私の勉強不足かもしれませんが、JAXBだとDomしか扱えず、結局Domから
    S2JFaceのコンポーネントモデルへの変換が必要になって重くなるのではな
    いかと心配しています。(あと、やっぱりスキーマコンパイルが必要なのも
    ちょっと重いなぁ・・・と。すみません、勝手ばかり言って(^^;)


On Wed, 30 Aug 2006 22:09:10 +0900, bskuroneko <bskuroneko ＠ gmail.com>
wrote:

> bskuronekoです。
> 
> DTDにコントロールを追加したり、
> クラス名やフィールド名に名前をあわせたりしています。
> 
> そこで気になった点が２つありますので、
> 意見を聞かせてください。
> 
> 1. プロパティは属性よりも要素の方がいいのではないか
> 今は各コントロールが持っているプロパティを
> 属性に記述するようにしていますが、
> これを要素にした方がよい気がしています。
> 
> 理由：
> 　・Font、Layout、TableItemのような複雑な型を書きやすい
> 　・テンプレートXMLが編集しやすくなる
> 　・直接書く場合と別の場所の定義を参照する場合の
> 　　両方を同じ場所で書ける
> 　　（Font要素をtemplate直下に記述してそれを参照するといった
> 　　ことが簡単にできるようになる）
> 
> 
> 2. スキーマをXMLSchemaにしたい
> 現在はDTDでスキーマを定義していますが、
> これをXMLSchemaにしたいと思っています。
> 
> 理由：
> 　・メンテナンスがしやすい
> 　　DTDだと共通化はすべてEntityという文字参照で行うので、
> 　　どこが何を定義しているのか後で見た時にわかりにくいが、
> 　　XMLSchemaでは型定義、属性グループなど、
> 　　それぞれがXMLの要素なのでわかりやすい。
> 　・記述を間違えにくい
> 　　DTDではEntityが文字列でしかないので、
> 　　間違った記述を簡単に書けてしまう。
> 　　XMLSchemaでは定義がそれぞれ明確なので
> 　　間違えにくく、必要な項目の補完もできる
> 　・型定義を継承したりできるので、
> 　　クラス階層に合わせて記述すればわかりやすくなる
> 　・型の定義を細かく書ける
> 
> 1番は小森さんがせっかく書いてくれたパーサーを
> また書き直さなくてはいけないのが申し訳ない所です。
> 
> 2番はまだまだ勉強中ですが、
> 細かく型を指定できることよりも、メンテナンス性の向上が
> 一番のメリットだと思っています。
> DTDより項目が多いので覚えるのは大変かもしれませんが、
> 書いている時の安心感がだいぶ違います。
> 
> その他ではJAXB2.0なんかを使うと楽できるかなぁ
> などと空想しているところです。
> # コード自動生成系ですけどね。。。
> 
> 以上、ご意見お待ちしております。m(_ _)m
> 
> 
> 06/08/27 に bskuroneko<bskuroneko ＠ gmail.com> さんは書きました:
> > bskuronekoです。
> >
> > DTDをコミットしました。
> >
> > 私もDTDをちゃんと書いたのは初めてです。（＾＾；
> > HTMLのDTDを参考にしながらみようみまねで書いてみました。
> > なので、もしかしたらもっといい定義方法があるかもです。
> >
> > > > > 1. クラス名やフィールド名と定義名を一致させるか
> > > > >  SWTを知っている人への混乱が少なくなり、
> > > > >  実装もリフレクションで解決しやすくなるので、
> > > > >  名前を一致させた方がいいと個人的には考えています。
> > >
> > > わたしもできるかぎり一致させるべきと思います。
> >
> > それなら要素や属性の名前をなるべく一致させる方向で
> > 修正していきましょう。
> > ちょっとレンダラーにも修正が入ることになりますが、
> > それほど大きな修正ではないでしょうし。
> >
> > > ただ、悩むのは SWTコンスタントによるスタイル指定です。
> > > コントロールによって指定できるものが違うので、属性に変換すべき
> > > と考えていました・・・
> > > (SWT.HORIZONTAL -> align="horizontal" とか)
> >
> > なるほど〜。
> > 補完するならその方法しかないかもしれません。
> > style属性の方がSWTに詳しい人はわかりやすいんですが、
> > 補完できる方がうれしいかもですね。
> > FontやLocationの指定なども無理やり複数属性にしてますし、
> > ありかもしれません。
> > とりあえずはstyle属性で動くようにしてみて、
> > その後に検討するのがよさそうですね。
> >
> > > > > 2. tabListをもう少し簡略化できないか
> > > えっと、これは TabFolder に対応するものでしょうか？
> >
> > すみません。説明が足りませんでした。
> > CompositeクラスのsetTabListに対応するものです。
> > Tabキーによる移動順を指定するものだと思うのですが、
> > タブ順を決めるだけにしては要素数が多くなってしまったので、
> > IDをカンマ区切り文字列で属性指定するだけでもいいかな〜
> > という検討項目です。
> >
> > > > > 3. IDREF型はやめたほうがよいか
> > > これはいまの段階では判断つきにくいですが、いまのところはやめておいて、
> > > 全体が固まってきたら必要な部分に導入した方が、考えやすいでしょうか。
> >
> > そうですね。
> > これはDTDを修正しておきます。
> >
> > > > > 4. 名前がいまいち？
> > > すみません、わたしもネーミングセンスにはまったく自信無しです。(--;
> >
> > mayaaやS2JSFなどの似たような機能を参考にするとか？
> > まあ名前ぐらいならサンプルを組んでみて
> > 違和感があってからでも変えられますしね。
> >
> > 私も手を動かして考える方なので、
> > どんどん動くように作ってしまいましょう。
> > まだまだSandboxですから（ｗ
> >
> >
> > 06/08/26 に KOMORI Yusuke<y-komori ＠ nifty.ne.jp> さんは書きました:
> > > 小森です。
> > >
> > > bskuronekoさん、ありがとうございます！
> > >
> > > 私も実はDTD弱者(現在のDTDもベースは亀谷さんに作ってもらった・・・)なの
> > > で、「こんなことができるか・・・」と感心しながら読ませていただいてます。
> > >
> > > 私はどちらかというと、実際に手を動かさないと考えられない人間なので、ダ
> > > メ元で現行のS2JFaceに組み込んでみましたが、やはりそのままではバリデーショ
> > > ン通らないですね。
> > >
> > > できれば、現在の 0.1 の上位互換に・・・と思いましたが、混乱しそうなの
> > > でやめましょう。(^^;
> > >
> > > > > 1. クラス名やフィールド名と定義名を一致させるか
> > > > >  SWTを知っている人への混乱が少なくなり、
> > > > >  実装もリフレクションで解決しやすくなるので、
> > > > >  名前を一致させた方がいいと個人的には考えています。
> > >
> > > わたしもできるかぎり一致させるべきと思います。
> > > ただ、悩むのは SWTコンスタントによるスタイル指定です。
> > > コントロールによって指定できるものが違うので、属性に変換すべき
> > > と考えていました・・・
> > > (SWT.HORIZONTAL -> align="horizontal" とか)
> > >
> > > でも、今回作っていただいたDTDを見ていると、工夫次第で(かなり大変そうで
> > > すが)なんとかなりそうですね。
> > > 下手に小細工するよりも、できるかぎり一致させる仕様のほうがポリシーがはっ
> > > きりすると思いました。
> > >
> > > 将来的にはSWTがわからない方にも使ってもらえるようにしたいのですが、ま
> > > ずはSWTを隠蔽せず、効率的に画面がつくれるようにすることを最優先すべきと
> > > 思います。
> > >
> > > > > 2. tabListをもう少し簡略化できないか
> > > えっと、これは TabFolder に対応するものでしょうか？
> > > だとしたら、単純に
> > >    <!ELEMENT tabList %compositeElems;>
> > > ではダメでしょうか。
> > >
> > > > > 3. IDREF型はやめたほうがよいか
> > > これはいまの段階では判断つきにくいですが、いまのところはやめておいて、
> > > 全体が固まってきたら必要な部分に導入した方が、考えやすいでしょうか。
> > >
> > > > > 4. 名前がいまいち？
> > > すみません、わたしもネーミングセンスにはまったく自信無しです。(--;
> > > Seasarプロダクトは、とりあえず頭に「S2」を付ければよいのでプロダクト名
> > > を考えるときだけは悩まなかったのですが・・・
> > >
> > > 亀谷さんのいうとおり、いったんコミットしていただけませんか？
> > > 私の方でも、対応パーサを書きながら考えてみたいと思います。
> > >
> > >
> > > On Sat, 26 Aug 2006 17:36:53 +0900, daiki kameya <paint_the_town_red ＠ parkcity.ne.jp> wrote:
> > >
> > > > 亀谷です。
> > > >
> > > > TO)bskuronekoさん
> > > > ありがとうございます。
> > > >
> > > > SVNにもコミットしちゃってください。そのほうが何かと便利かもなので。
> > > >
> > > > まだ、詳しくは見てませんが、ENTITYって今まで使ったことなかったのでちょっ
> > > > と読むのに苦戦しそうです。（いい勉強になると思ってがんばります。）
> > > >
> > > > TO)bskuronekoさん、小森さん
> > > > とりあえず、この形で使っていきつつ何かあればまた議論→変更みたいな感じで
> > > > いいのではないでしょうか？
> > > >
> > > > bskuroneko wrote:
> > > > > bskuronekoです。
> > > > >
> > > > > DTDたたき台バージョンを添付します。
> > > > > お待たせしました。
> > > > >
> > > > > まだコントロールの定義などが足りていないのですが、
> > > > > 議論の足場にはなると思います。
> > > > > コントロールの定義は今後追加しておきます。
> > > > >
> > > > > 簡単に要点をまとめます。
> > > > > ・DTDのバージョンはとりあえず0.2とした
> > > > > ・各コンポーネントごとに要素を定義した
> > > > > ・親クラスのプロパティなどは共通の属性としてエンティティにした
> > > > > ・型もエンティティで分類しておいた
> > > > > ・layout、layoutDataは要素にして補完できるようにした
> > > > > ・id, style, replaceはウィジット共通の属性とした
> > > > > ・idはID型とし、XML内で一意になるようにした
> > > > > ・コントロールを参照する属性はIDREF型とした
> > > > > ・componentDef要素で部品を定義できるようにした
> > > > > ・include要素で部品を取り込めるようにした
> > > > > ・menuとmenuMangerの記述方法をクラスの関係に従うようにした
> > > > >
> > > > >
> > > > > TODOコメントにも書いていたりしますが、
> > > > > 個人的に気になっている点は以下です。
> > > > >
> > > > > 1. クラス名やフィールド名と定義名を一致させるか
> > > > >  SWTを知っている人への混乱が少なくなり、
> > > > >  実装もリフレクションで解決しやすくなるので、
> > > > >  名前を一致させた方がいいと個人的には考えています。
> > > > >
> > > > >  現在のDTDはレンダラーで使用している名前と
> > > > >  クラス名、フィールド名などが混在してます。m(_ _)m
> > > > >
> > > > >  現在のtextAreaのように独自で簡略化したものなどを
> > > > >  追加定義するのはよいと思います。
> > > > >
> > > > >  SWTのクラス体系に強く依存することになってしまいますが、
> > > > >  Swing対応などが必要になったら、
> > > > >  jButtonなどの要素を追加すればよいでしょう。
> > > > >  SWTとSwingが中でぐちゃぐちゃに混在するようなGUIも
> > > > >  書けるようになるかもしれませんね。
> > > > >
> > > > > 2. tabListをもう少し簡略化できないか
> > > > >  componentRefという要素を列挙してIDREFで参照していますが、
> > > > >  少し書くのが面倒くさい気もしています。
> > > > >  この程度ならidのカンマ区切りでもいいかもしれません。
> > > > >  各コントロールにtabIndex属性を追加することも考えたのですが、
> > > > >  それだと順番を入れ替えたりコントロールを追加するときの
> > > > >  対応が煩雑になりそうなのでやめました。
> > > > >
> > > > > 3. IDREF型はやめたほうがよいか
> > > > >  extendsやincludeを多用すると 、
> > > > >  IDREFでIDが見つからずにエラーになってしまいそうです。
> > > > >  今IDREFで定義している部分は%String;に変えてしまった方が
> > > > >  いいような気がしてきました。
> > > > >
> > > > > 4. 名前がいまいち？
> > > > >  componentDef、includeなど、
> > > > >  名前をもう少し練った方がよさそう。
> > > > >
> > > > >
> > > > > 属性の記述方法や要素の構成方法など、
> > > > > いろいろな部分で気になる点が出てくると思います。
> > > > > どんどんたたいてやってください。
> > > > >
> > > > > 少なくともこのDTDで
> > > > > grabExcessHorizontalSpace
> > > > > をコピー＆ペーストする必要はなくなります。（ｗ
> > > >
> > > > _______________________________________________
> > > > Seasar-dev mailing list
> > > > Seasar-dev ＠ ml.seasar.org
> > > > https://www.seasar.org/mailman/listinfo/seasar-dev
> > >
> > > ----------------------------------------------
> > >  小森 裕介 / Yusuke Komori
> > >
> > >  E-Mail:y-komori ＠ nifty.ne.jp
> > >    Blog:http://d.hatena.ne.jp/y-komori/
> > >     URL:http://www.littleforest.jp/
> > >
> > >
> > > _______________________________________________
> > > Seasar-dev mailing list
> > > Seasar-dev ＠ ml.seasar.org
> > > https://www.seasar.org/mailman/listinfo/seasar-dev
> > >
> >
> _______________________________________________
> Seasar-dev mailing list
> Seasar-dev ＠ ml.seasar.org
> https://www.seasar.org/mailman/listinfo/seasar-dev

----------------------------------------------
 小森 裕介 / Yusuke Komori

  E-Mail:y-komori ＠ nifty.ne.jp
    Blog:http://d.hatena.ne.jp/y-komori/
     URL:http://www.littleforest.jp/
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: DIdeJanken.xml
型:         application/octet-stream
サイズ:     2368 バイト
説明:       無し
URL:        http://ml.seasar.org/archives/seasar-dev/attachments/20060831/43497f64/attachment-0002.obj 
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: DIdeJanken2.xml
型:         application/octet-stream
サイズ:     1190 バイト
説明:       無し
URL:        http://ml.seasar.org/archives/seasar-dev/attachments/20060831/43497f64/attachment-0003.obj

Seasar-dev メーリングリストの案内