作者: 閑舎
日時: 2006/7/06(12:06)
うぇいくさん、こんにちは。

うぇいく <weyk@...> さん wrote.

> 　１番、おや？　と思うところは、各タグ(PやBODY)に関する処理の
> 実装がBlockに含まれている点です。以降、サポートするタグを増やす
> ごとにBlockが肥大していくことになり、メンテも大変です。
> 　各subClassが、自分で取り込める部分のみとりだすparseをサポートし、
> それを元に戻す(?)部分のみのtoTextを提供してつくりになるのでは
> ないかとおもうのですが・・・（自分のことは自分が知っている）

最初に思いつくのは、確かにおっしゃるような構造で、

  Body, P

のそれぞれが parse, toText という関数をもつ、単純なものだと思います。が、
もう少しやってみると、様子が変わってきます。

HTML のタグには、非常に似た振舞いをするものが多く見られます。Body, P, Li 
などは、広い範囲で次のタグを探します。これに対し、B, I などといったタグ
の守備範囲は狭いものです。Pre などは内部の toText が通常とは違うことにな
るでしょうが、他の圧倒的に多くのタグの toText は共通です。

で、Body や P の parse, toText はそっくりなわけで、それなら共通するもの
はその特徴から Block, Inline といった基底クラスを作り、その継承でいくほ
うがいいのでは、となったわけです。

parse がやることは 2 つあって、

-次のタグの開始位置をみつけ、現タグの終了ポイントを明確にし、変換すべき
 テキストの長さを決定する。

-次のタグの種類を見極め、そのタグの構造体を作り、そこへのポインタ next
 を決定する。合わせて、現タグが終了なのか、次のタグの親となるのか、といっ
 た関係を決定する(サンプルにはそこまでの処理は入れてません)。

Block の parse は示した例では原始的ですので、もう少し詳しく処理する必要
があります。

--
本田博通（閑舎）
テキストとスクリプトの http://www.rakunet.org/TSNET/