I am sorry, but as the maintainer of the HTML export filter, I am not as 
euphoric as many people seems to be.

I am not against common code between KSpread's HTML export and KWord's but 
the following implentation seems to contradict what I have wanted to do as 
library for the KWord export filters (like the directors you propose here.)

For example, I have always paid attention to have the document only one time 
in memory, on the KWord side as DOM. Right, for now the export side is still 
in a QString but it is one of the goal of my library for KWord export 
filters, it is to get rid of that QString and to use a QTextStream instead 
(and to open it to binary file formats by being able to choose QDataStream 
instead.)

However, I do think that KSpread HTML export filter could make, as if it was 
parsing a KWord file and gives the information to the KWord HTML export 
filter (what it will be after the library is finished.) That's the only way I 
see it can be done without starting again from scratch.

Somehow, I have the bad feeling that we are talking about the same thing but 
that we do not describe it the same way! :-(

Have a nice day/evening/night!

On Monday, 10. September 2001 14:16, Eva Brucherseifer wrote:
> 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