On Tue, 15 Jun 1999, Asger Alstrup Nielsen wrote:
> Some time ago, we did discuss this problem briefly. I proposed that we
> had only one method for all writers, but that it was kept inside the
> Insets. The improvement compared to now is that we don't have to
> introduce a new method for a new export format, but we would still have
> to change in many places. (The writer method would locally dispatch to
> write the correct format.) The reason I don't like to collect all
> output to one place is that I fear that we would have a hard time to
> maintain all output formats when new Insets are introduced. Then,
> finding the unsupported Insets for a particular format requires a lot of
> work, because you have to do it by hand.
My suggestion, outlined here several years ago, was to remove completely
the writting methods from insets, but all insets would have an id key so
the specific document language writer would get a syntax definition and
write the corresponding code. Of course the inset still has to
give its contents.
This way, to define a new document language we just have to write the
language syntax definition in a simple way (it won't be used to parse but
to write documents). So, instead of adding a docbook entry in all insets,
the WriterDocBook would have an entry corresponding to the insets allowed
to write in docbook, in it's internal syntax definition table. For most
insets it would not have to have any definition.
A clear example can be obtained from Jose's patch to insetlabel.C. He did:
file += "<anchor id=\"" + getContents() +"\" >";
as you see he is just putting the contents of the inset inside a docbook
construction. The new writer would get from it's syntax table that the
corresponding name for a label is "name" and that the contents corresponds
to the parameter "id" so it writes the same construction.
> The advantage of having a collected, monolithic writer routine would be
> that we might be able to decouple it completely from the kernel. This
> in turn would imply that we could have export formats completely outside
> the main kernel, which obviously is a good thing. Among other things,
> this would allow us to dynamically link in export formats as modules,
> similar to the Gimp architechture.
Exactly. It would be modular, it would browse the document trhough
iterators. I think this is the way we should follow.
Greets,
Alejandro
