[seasar-dev:527] Re: [S2JFace] DTDの変更について
bskuroneko
bskuroneko ＠ gmail.com
2006年 9月 14日 (木) 00:44:32 JST
bskuronekoです。
xsdを作成してコミットしました。
dtdでは足りていなかったコントロールなどもだいぶ追加しました。
TableItemなどもモックアップを作るうえでは必要な場合もあると思うので、
一応定義してあります。
DIdeJanken2.xmlにxsdを適用したものを添付しておきます。
DOCTYPE宣言をxmlns属性に変えただけですけど。
これでスキーマはとりあえずの完成ですかね。
後は必要に応じて修正すればいいと思ってます。
06/09/05 に KOMORI Yusuke<y-komori ＠ nifty.ne.jp> さんは書きました:
> こんばんは、小森です。
>
> > > > 1. プロパティは属性よりも要素の方がいいのではないか
> > > いろいろ考えてみましたが、基本的には今のまま属性に記述するほうがいいと
> > > 思います。
> >
> > わかりやすい説明をありがとうございます。
> > 小森さんの意見を聞いて、
> > 私も今のまま属性に記述でよいと思いました。
>
> 了解です。
> では、これについてはFIXということで。
> たしかに、私も実際にXML書いてみて、「これは絶対に属性の方が楽だ。。。」
> と思いました。(^^;
>
> > ふと思いついたのですが、１と２のハイブリッドにする方法として、
> > componentDefで使おうとしているparam定義を
> > template自体にも適用するのはどうでしょう？
> >
> > 例）
> > <template name="hoge">
> > <param name="background">white</param>
> > <shell id="hoge" background="#{background}">
> > ...
>
> これ、良さそうですね。
> ComponentDef のところをあまりよく見てなかったので(すみません・・・)
> 見てみたいと思います。
> 実装上、問題なければ採用したいですね。
>
> > SAXパーサでもXMLSchemaのバリデーションは可能です。
> > JDK5からはSAXParserFactoryのsetSchemaメソッドを
> > 使用して検証を行うことができるようです。
>
> なるほど。
>
> > DTDかXMLSchemaかという問題とJAXBとは
> > あまり関係がありません。
> > 誤解を生むような書き方をして申し訳ないです。
>
> いえいえ、単なるわたしの勉強不足です。すみません。
> パーサ側に問題がないのならば、XMLSchema にしてくださって問題ないと思い
> ます。こちらも、とりあえずやってみて、良さそうな方法をとれば良いでしょう
> か。
>
>
> あと、パーサ、コンポーネント、レンダラ周りは、私も今色々悩んでしまって
> います。
> どこかが楽になるようにしようとすると、そのしわ寄せが他のところに来てし
> まう・・・と、当たり前の話なのですが、どこかで割り切らなきゃいけないです。
>
> 当初、パーサーの修正だけですませようという話を書いていましたが、それだ
> とＦＷ全体として見たとき、どうも継ぎ接ぎ感が否めない・・・
> 今のうちならまだ、コンポーネントやレンダラまで含めてアーキテクチャを刷
> 新しても良いとは思うのですが・・・
>
> 自分でも考えがまとまっていないので、まとまり次第またＭＬへ投げたいと思
> います。
>
> On Mon, 4 Sep 2006 00:24:45 +0900, bskuroneko <bskuroneko ＠ gmail.com> wrote:
>
> > bskuronekoです。
> > 返事が遅くなってすみません。
> >
> > > bskuronekoさん、DTDの検討、本当にありがとうございます！
> >
> > いえいえ、こちらこそ検討に付き合っていただけてありがたいです。
> > すごく勉強になります。
> >
> > > > 1. プロパティは属性よりも要素の方がいいのではないか
> > > いろいろ考えてみましたが、基本的には今のまま属性に記述するほうがいいと
> > > 思います。
> >
> > わかりやすい説明をありがとうございます。
> > 小森さんの意見を聞いて、
> > 私も今のまま属性に記述でよいと思いました。
> >
> > > ■ 0.1版 と 0.2 版の比較
> > >
> > > 0.1版のDTDでは 63行 あったのが 0.2 版では 36 行と大幅に減っていま
> > > す。（添付ファイルを比較してみてください）
> >
> > 本当ですね。
> > こんなに圧縮効果があるとは思っていませんでした。
> > やっぱりユーザーとして書いてみるのが一番わかりやすいですね。
> >
> > > ■ フォントやレイアウト定義の再利用について
> > >
> > > １．１カ所で定義しておいて、参照する方法
> > > (bskuronekoさんが書いてくださった考え方)
> > > ２．親の属性を自動で引き継ぐ方法
> > >
> > > 現在の S2JFace は、２のアプローチを取っています。
> >
> > 引継ぎの詳しい説明ありがとうございます。
> > なるほど納得しました。
> >
> > ふと思いついたのですが、１と２のハイブリッドにする方法として、
> > componentDefで使おうとしているparam定義を
> > template自体にも適用するのはどうでしょう？
> >
> > 例）
> > <template name="hoge">
> > <param name="background">white</param>
> > <shell id="hoge" background="#{background}">
> > ...
> >
> > これでテンプレートの上部で一括して指定したい項目があれば
> > 指定することができます。
> > さらに、ウィンドウの位置とサイズの保存や、
> > ウィンドウを少しずつずらして表示していくプログラムなど、
> > プログラム側からパラメータとして指定することで
> > GUIをレンダリング前に変えられる利点が生まれそうです。
> >
> >
> > > > 2. スキーマをXMLSchemaにしたい
> > > 気になるのはバリデーションです。現在使用しているSAXパーサではDTDに
> > > よるバリデーションを行ってくれますが、XMLSchemaの場合ってどうなるの
> > > かご存じでしょうか？（逆にJAXBを利用しなければならなくなる？？）
> >
> > SAXパーサでもXMLSchemaのバリデーションは可能です。
> > JDK5からはSAXParserFactoryのsetSchemaメソッドを
> > 使用して検証を行うことができるようです。
> >
> > DTDかXMLSchemaかという問題とJAXBとは
> > あまり関係がありません。
> > 誤解を生むような書き方をして申し訳ないです。
> >
> > JAXBはスキーマ（DTD or XMLSchema）を読み込んで
> > スキーマ定義に対応したJavaクラスと、そのマッピングソースを
> > 自動生成するツール（Relaxerと同じ用途？）だと思います。
> > 素直にXMLをJavaクラスにマッピングできそうなので、
> > そこからレンダラーなどを書くのは楽かなぁと思ったのですが、
> > スキーマから自動生成してジェネレーションギャップパターンで…
> > というのが面倒なのも事実ですね。
> > JAXB2.0になってだいぶ使いやすくなったみたいなので、
> > 柔軟にマッピングが定義できると便利そうなんですが、
> > 調べきれてません。
> > パーサーを自力で書くより楽ができるならいいなあ
> > という程度の気持ちでした。
> >
> > スキーマをメンテナンスするのがXMLSchemaの方が楽なので、
> > XMLSchemaでも書いてみて比較したいと思います。
> > 検証指定部分以外はコードへの影響はないでしょうし。
> > せいぜいDTDでの記述ミスが見つかるくらいでしょう。(^^;
> >
> >
> > 06/08/31 に KOMORI Yusuke<y-komori ＠ nifty.ne.jp> さんは書きました:
> > > 小森です。
> > >
> > > 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/
> > >
> > >
> > > _______________________________________________
> > > 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/
>
>
> _______________________________________________
> Seasar-dev mailing list
> Seasar-dev ＠ ml.seasar.org
> https://www.seasar.org/mailman/listinfo/seasar-dev
>
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: DIdeJanken3.zip
型: application/zip
サイズ: 790 バイト
説明: 無し
URL: http://ml.seasar.org/archives/seasar-dev/attachments/20060914/b9e1d1f4/attachment-0001.zip
Seasar-dev メーリングリストの案内