From koffice-devel Fri Sep 14 17:49:36 2001 From: Thomas Zander Date: Fri, 14 Sep 2001 17:49:36 +0000 To: koffice-devel Subject: Re: [RFC] filter redesign X-MARC-Message: https://marc.info/?l=koffice-devel&m=100049002713552 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--KsGdsel6WgEHnImy" --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2001 at 12:35:38AM +0200, Nicolas Goutte wrote: > On Thursday, 13. September 2001 16:59, Eva Brucherseifer wrote: > > Hi Nicolas, =2E.. > > So far your filter seems to head towards a kword filter only. That is w= hy I > > started to think about how to share work. And the result is the design, > > that I proposed, and that Zander was able to explain much better than me > > (Thank you for helping ;-). I didn't want to overrun you, that is why I > > proposed the whole thing here first. :-) > It is not your idea in general that made me felt "overran", it is the fac= t=20 > that I have started to write the library for KWord export filter two week= s=20 > ago, with no much comment but an interested welcome from David Faure. I feel a bit guilty in this, I know Eva is quite buzy, so I was quite excit= ed to see her put some time into this, sorry I forgot about you here.... I ho= nestly do appriciate both your work!! :) > The library was meant by me mainly to encapsulate problematic code in the= =20 > ASCII-like export filters (of KWord.) This part of code is known to be=20 > problematic everytime that the file format of KWord is changed, in partic= ular=20 > when it is simplified. So I had wanted to separate it, so that modificati= ons=20 > in the KWord file format could be changed at only one point for most of t= he=20 > filters and not in each (KWord) export filters like now. This is also the controller, builder background idea. It even can be extend= ed to have different directors talk to different builders, so you can just pas= te together 2 classes to create a filter. However powerful this concept may be= , the limit lies on the specification of the Interface (API) between the builder = and the controller. So this will probably be good for every ascii like format, = but not much more. > I thought that I could make it evolve a little and have classes with meth= od=20 > like StartElementP, charactersElementP, EndElementP, as they exists in=20 > KWord's AbiWord import the functions. They would have told that a paragra= pgh=20 > was started, that we had some characters for that paragraph and that the= =20 > paragraph was closed. The class that need to implement this methods are n= ot=20 > the builders, as you have defined them. In the meantime, I think that it = is=20 > not that problematic, as something I call "glue" can be made between the= =20 > parser-like idea I had and builders in the sence of your definition. Maybe you can just avaid the problem by adding code to the builder that alw= ays creates a correct structure. So calling addTableRow would add a paragraph, = and=20 a table if they did not exist before. Then the parser can be simplified and the builder knows more about the docu= ment structure it implements. For example the paragraph and table structures do = not have to be added in case of a plain ascii text. So that builder does not im= plement it. > > Your is not so different from what I was proposing. You already have a > > hierarchy which very much is the builder side. All the "getXXX" functio= ns > > are functions that are part of a builder. > > What Mr. Gamma called the director in his book, is in your function > > ClassExportFilterBase::filter(...) and all the "ProcessXXX" functions t= hat > > are not part of any class. >=20 > The problem is that exactly those Process* function is part of the proble= m in=20 > the ASCII-like filters! :-( >=20 > So for me, your proposal was going back to the start somehow! hmm, Eva's proposal puts the changing file format proplem in the director. = I would imagine a piece of code like; director::doParag(QDomElement ¶g) { // interpret xml tree here, and then; QString text=3D getAttribute( parag, "text", ""); //etc.. builder.addParagText(paragNum, text); builder.setBold(paragNum, bolding); } etc. (ok, this won't work, but you get the idea) Which means that the code which parses the DOM tree interprets it, and the = builders implementation is irrelevant in this case. > > That was another long mail, although I should type... typist's neuritis= :-( oops.. :( --=20 Thomas Zander zander@earthling.n= et The only thing worse than failure is the fear of trying something new --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7okMwCojCW6H2z/QRAgOgAJwJm4eMDhOMUH6UhR6KwvXOthmEOACgvNNB CiTlwe9sRyaSo5S06XboXBM= =/aYP -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- _______________________________________________ Koffice-devel mailing list Koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel