[seasar-dev:500] Re: [S2JFace] DTDの変更について
bskuroneko
bskuroneko @ gmail.com
2006年 8月 27日 (日) 00:47:43 JST
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ですから(w
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
> > > をコピー&ペーストする必要はなくなります。(w
> >
> > _______________________________________________
> > 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 メーリングリストの案内