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