[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-10 19:08:56
[Download RAW message or body]

On Mon, Sep 10, 2001 at 02:16:12PM +0200, Eva Brucherseifer wrote:
> 
> Hi,

Hi Eva!

> At work I had a similar problem and finally found a wonderful solution from 
> the design patterns, that might suit here too. It is the builder patterns, 
> which consists of 2 parts: the director and the builder.
> 
> 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.

This fits perfectly for the HTML export of kspread and kword, yes. One director
per application (maybe inhariting a basic implementation) looks very good to me!

> 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.
> 
> 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 void addHeader(QString name, QString value); // sets author stuff, known meta \
tags are converted.
> 	virtual buildFooter(...);
> 	virtual buildParagraph(...);
> 	virtual buildTable(...);
    don't forget that this method needs a created paragraph as an argument. (actually \
an ID, see below)

> 	virtual buildTableRow(...);
> 	virtual HTMLDocument* getHTML();
> }
> 
> The HTMLDocument can be another internal structure than easily can be parsed 
> afterwards or a string (or you add another function "getString()").
> 
<snip>

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

The builder has as many methods as needed to provide all the functionality of the
export filter, this is inharent to the pattern.
If you make a method like buildTable have an paragraphId as argument, and also
use the paragraphId on creating the paragraph itself, then the elements dont
have to be called in the same order as they are presented in the output file.

Consider the following;
    int parag=1;
    myBuilder.buildParagraph(parag++);  // create parag 1
    myBuilder.buildParagraph(parag++);  // create parag 2
    int table=1;
    myBuilder.buildTable(1,table);    // create table 1 in parag 1
    int row=1;
    myBuilder.buildTableRow(table,row++); // create tableRow 1 in table 1
    myBuilder.buildTableRow(table,row); // create tableRow 2 in table 1
    myBuilder.buildTableCell(table,row,1,3,4); // create tableCell 1 in table 1 in \
row 2, table cell has width=4 height=3

This simply builds the HTML in a internal structure inside the builder, calling this \
in another order does not make to much of a difference, as long as something is \
created before you use it. I don't think you will find to many problems with document \
structures if you do it like this.

> Well, any comments are welcome.
> 

I think this is a very nice addition, and maybe you can check with Frank what 
he has allready then the solve will form itself.
ps. Frank has posted his source on: 
  http://www.student.kuleuven.ac.be/~m9823990/html2kwd.tbz2

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