[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-12 19:33:51
[Download RAW message or body]

On Tuesday, 11. September 2001 08:25, Thomas Zander wrote:
> On Mon, Sep 10, 2001 at 11:02:45PM +0200, Nicolas Goutte wrote:
> > 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.
>
> I never said that the resulting code should be a table beneath a parag.
> Reading your other mail as well, I am afraid you miss the implementation of
> the pattern, the meaning is to create the document as datastructures in
> memory, and ask that datastructure later to print the output stream that
> represents it.

I do not understand why we need again an intermediate layer between KWord and 
the final export format. Today we have already QDom on side of KWord, the 
KWord file and QDom on the KWord side of the office filter. Why would we need 
again another layer that will only cost memory and time for no gain? Or at 
least, I cannot see any gain.

> Note also that the input datastream does not have to result in the caching
> of the document in the director, the builder is the only one who builds the
> document.

From what I have read of the very first message, it is not the builders 
responsability to write the file, but it must give back a method getHTML(). 
And in particular in this point, I think that it is wrong!

>
> A table will be positioned by using a paragraph, but if the spec does not
> allow this then you don't print the tag ;)

Ah! You spoke in KWord's term, I thought you were talking in HTML terms!

>
> You should notice however that inline tables are used quite often, both in
> KWord and in HTML, maybe all those pages are breaking the rules but I do
> think that it is a feature people want...

Then for HTML, we have to close the paragraph, open the table (surely with 
some CSS magic for the flow), write the table, close the table, and start the 
paragraph again!

Have a nice day/evening/night!

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