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

List:       koffice-devel
Subject:    [RFC] filter redesign
From:       Eva Brucherseifer <eva () rt ! e-technik ! tu-darmstadt ! de>
Date:       2001-09-10 11:29:10
[Download RAW message or body]


Hi,

some time ago, I made the html filter for kspread in a fast hack. Some people 
already applied patches (thank you!) to it, due to missing features. So far I 
didn't continue with it, because I have the feeling of doubling effort (yes, 
I am pretty lazy sometimes ;-). The problems that exist in html import/export 
are already very well solved in the kword html filters and I didn't want to 
copy paste all stuff. 

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.

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 buildFooter(...);
	virtual buildParagraph(...);
	virtual buildTable(...);
	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()").

The Director class is then very similar to the existing filter class. But it 
now contains a pointer to the Builder and uses it's interface:

buildDocument(documenttitle);
buildHeader(htmlversion, charset, content, title); // maybe the Builder class 
should contain a dialog to ask the user for the export configuration?
buildBody(bgcolor, textcolor);
....


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

Well, any comments are welcome.

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]