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

List:       koffice-devel
Subject:    Re: [RFC] filter redesign
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2001-09-10 21:02:45
[Download RAW message or body]

On Monday, 10. September 2001 21:08, Thomas Zander wrote:
> 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)

You cannot have this! <TABLE> cannot be a child of <P> according to strict 
DTD of HTML 4.01.

>
> > 	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()").
>
> (...)
_______________________________________________
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]