At 11:24 PM 5/31/00 -0500, sam th wrote:
>Well, I had never planned to implement HTML, as opposed to XHTML. I have
>no desire to write that parser (and it would belong in the importer).
Wise move. ;-)
>But
>the problem is that with your first example, the importer has to keep
>track of the state of the formatting at any given point, which is
>information that is avalible in the PT.
Oh. I didn't realize you were trying to avoid keeping track of the current
state. That's easy to do, especially for a cleanly-nested format. Just
push and pop a stack based on the nesting depth -- all the information you
need can be read off by just walking the stack. Caches don't get much
simpler than that.
>This is why I think that a
>controller class, as suggested by Jeff among others, is the best way to
>handle this.
I suspect the controller class (to get access to the IP, right?) is a red
herring. See below.
>Now, if I had an insertion point while I was doing the importing, the PT
>would be much easier to use (I could just use the sort of code FV_View
>uses). I could then make changes to formatting, instead of just appending
>further formatting. But the view maintains its own insertion point, not
>the PT.
Now I get it. Even if you really don't want to keep track of the current
format state yourself, you still don't need an insertion point. Importers,
by definition, are always appending to the end of the document. All you
need is the format at the end of the document.
Sounds like at most one API change, if that.
>And lest you think that this is unique to XHTML, you should look at a
>KWord document sometime. Importing that would take yet more heavy lifting
>(which would be easier with a controller).
Huh? That can't be right. Is KWord's format really harder to import than
Word's? Ick.
Paul
