[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [RFC] filter redesign
From:       Thomas Zander <zander () planescape ! com>
Date:       2001-09-14 17:49:36
[Download RAW message or body]

On Fri, Sep 14, 2001 at 12:35:38AM +0200, Nicolas Goutte wrote:
> On Thursday, 13. September 2001 16:59, Eva Brucherseifer wrote:
> > Hi Nicolas,
...
> > So far your filter seems to head towards a kword filter only. That is why I
> > started to think about how to share work. And the result is the design,
> > that I proposed, and that Zander was able to explain much better than me
> > (Thank you for helping ;-). I didn't want to overrun you, that is why I
> > proposed the whole thing here first.

:-)

> It is not your idea in general that made me felt "overran", it is the fact 
> that I have started to write the library for KWord export filter two weeks 
> ago, with no much comment but an interested welcome from David Faure.

I feel a bit guilty in this, I know Eva is quite buzy, so I was quite excited
to see her put some time into this, sorry I forgot about you here....  I honestly
do appriciate both your work!! :)

> The library was meant by me mainly to encapsulate problematic code in the 
> ASCII-like export filters (of KWord.) This part of code is known to be 
> problematic everytime that the file format of KWord is changed, in particular 
> when it is simplified. So I had wanted to separate it, so that modifications 
> in the KWord file format could be changed at only one point for most of the 
> filters and not in each (KWord) export filters like now.

This is also the controller, builder background idea. It even can be extended
to have different directors talk to different builders, so you can just paste
together 2 classes to create a filter. However powerful this concept may be, the
limit lies on the specification of the Interface (API) between the builder and
the controller. So this will probably be good for every ascii like format, but not
much more.

> I thought that I could make it evolve a little and have classes with method 
> like StartElementP, charactersElementP, EndElementP, as they exists in 
> KWord's AbiWord import the functions. They would have told that a paragrapgh 
> was started, that we had some characters for that paragraph and that the 
> paragraph was closed. The class that need to implement this methods are not 
> the builders, as you have defined them. In the meantime, I think that it is 
> not that problematic, as something I call "glue" can be made between the 
> parser-like idea I had and builders in the sence of your definition.

Maybe you can just avaid the problem by adding code to the builder that always
creates a correct structure. So calling addTableRow would add a paragraph, and 
a table if they did not exist before.

Then the parser can be simplified and the builder knows more about the document
structure it implements. For example the paragraph and table structures do not
have to be added in case of a plain ascii text. So that builder does not implement
it.

> > Your is not so different from what I was proposing. You already have a
> > hierarchy which very much is the builder side. All the "getXXX" functions
> > are functions that are part of a builder.
> > What Mr. Gamma called the director in his book, is in your function
> > ClassExportFilterBase::filter(...) and all the "ProcessXXX" functions that
> > are not part of any class.
> 
> The problem is that exactly those Process* function is part of the problem in 
> the ASCII-like filters! :-(
> 
> So for me, your proposal was going back to the start somehow!
hmm, Eva's proposal puts the changing file format proplem in the director. I would
imagine a piece of code like;
director::doParag(QDomElement &parag) {
    // interpret xml tree here, and then;
  QString text= getAttribute( parag, "text", "");
  //etc..
  builder.addParagText(paragNum, text);
  builder.setBold(paragNum, bolding);
}

etc. (ok, this won't work, but you get the idea)
Which means that the code which parses the DOM tree interprets it, and the builders
implementation is irrelevant in this case.

> > That was another long mail, although I should type... typist's neuritis :-(

oops.. :(

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

[Attachment #3 (application/pgp-signature)]
_______________________________________________
Koffice-devel mailing list
Koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]