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

List:       koffice-devel
Subject:    Re: [RFC] filter redesign
From:       Eva Brucherseifer <eva () kde ! org>
Date:       2001-09-10 20:42:05
[Download RAW message or body]

Hi Frank,

On Montag, 10. September 2001 16:14, Frank Dekervel wrote:
> Op maandag 10 september 2001 14:16, schreef Eva Brucherseifer:
> > director:
> > The director parses the input and extracts the tasks to do in order to
> > build a document in another format. It doesn't have any knowledge about
> > how to perform the tasks.
> >
> > builder:
> > The builder puts the output format together. It has an interface that
> > provides methods for sub-tasks. These are called by the director. It
> > doesn't have any knowledge about the input format.
>
> thats more or less the design i use for a new (not yet committed) html
> input filter. (its not that well separated). 

Yes, your design is pretty similar :-) So far I only thought about the export 
problem, which is easier, because you map a complex structure to an easy one. 
I realized that for an import it's more difficult. Still I think, the pattern 
can be used as well. At least for the easy import formats.

I would map it like this:
 KHTMLReader == director & parser
 KWDWriter == builder

The complete structure would look like this: 

import --> director  --> builder --> koDocument
                html              kword        == kword html import filter
                html              kspread     == kspread html import filter
                ascii              kword        == kword ascii import 
                latex              kword
                 ....              

export <-- builder <-- director <-- koDocument
                html           kword           == kword html export
                html            kspread       == kspread html export
                ascii             kword 
                ...

> I was planning to make the
> 'builder' as filter independent as possible too, but i think it will be
> pretty difficult to separate everything out (you need at least a vague
> kword 'knowledge' to create a kword doc)

I don't understand completly. Where do you need the knowledge, in KHTMLReader 
or in KWDWriter? The KWDWriter must be totally specific for kword, but 
you can have a second builder for kspread and maybe reuse the html reader.

When looking at the kword import problem I also thought about a possible html 
import filter for kspread, I got the following idea: 
A table in the html structure, you read in KTHMLReader, can either be 
converted into a KWord table or a KSpread table. Maybe it's then better, to 
use a set of builders for a kword import? E.g. a KTextBuilder and a 
KTableBuilder.
A KTableBuilder can then be subclassed to KWordTableBuilder or 
KSpreadTableBuilder - depending on the choice of the user.

>
> > So how does this look like for the html export filter? You have the
> > builder that can set together a html page. Here is a rough sketch of a
> > html builder class:
> >
> > class KHTMLBuilder      : public KOfficeBuilder
> > {
> > public: 
> >         virtual void buildDocument(...);  // initialization
> >         virtual void buildHeader(...);
> >         virtual buildFooter(...);
> >         virtual buildParagraph(...);
> >         virtual buildTable(...);
> >         virtual buildTableRow(...);
> >
> >         virtual HTMLDocument* getHTML();
> > }
>
> Maybe you could have a look at KHTML's DOM::Document. You can build the
> document with the DOM, and it should export correct html. Offcourse
> QDomDocument can do that too, but maybe khtml has some extra nice html
> specific features you can use (i'm not sure tough)

Is KHTML is not made for output, is it? I'll check this. 

>
> > After dividing the import/export classes this way, you should be able to
> > share functionality. E.g. the kword html export and the kspread html
> > export can share the htmlbuilder class.
>
> That would be cool, but i think it will be difficult to make the separation
> that clean you could plug the director made for foo->kspread together with
> a kword builder. You'll always need a bit of conceptual knowledge i fear
> (only the fact kword is a wordprocessor, and kspread is a spreadsheet ex.)
> But i might be wrong ..

See above, what I was intending. Maybe my first explanation wasn't that good 
:-(

For the kspread html filter I'd like to use the following:
- KHTMLBuilder - a class that puts together html elements
- KSpreadDirector - the "manager" of the output, that understands the kspread 
structure

I would like to extend this setup then to have a latex export by making a 
class KLatexBuilder.

In order to not duplicate work, I would like to share the KHTMLBuilder and 
KLatexBuilder classes with the kword html and latex filters. Still I have no 
idea, how these classes can be made available in libraries - don't know 
anything about the libloader stuff :-(

Puh, that is a long mail - I hope it's not too chaotic ;-)

Greetings,
eva
_______________________________________________
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]