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

List:       koffice-devel
Subject:    Re: [RFC] filter redesign
From:       Frank Dekervel <Frank.dekervel () student ! kuleuven ! ac ! Be>
Date:       2001-09-10 14:14:51
[Download RAW message or body]

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). 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)

>
> 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)

> 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 ..

> Maybe you also can share directors, if the interface can be made general
> enough. Then you can have an abstract class KOfficeBuilder with empty (not
> pure virtual!) implementations. So, if a builder doesn't have an element,
> nothing happens. But would imply, that there is some kind of "general
> document structure", that is implemented in the builder interface - don't
> know, if this is possible...

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