On Mon, Oct 18, 2004 at 01:41:04PM +0100, Angus Leeming wrote: > Andre Poenitz wrote: > > May I suggest a slightly different approach? > > > > Let's have some MetaInset that's a proper LyX inset, i.e. deriving > > from InsetBase, but which mainly acts as a data storage capable to > > store attribute and CDATA contents. The parser (expat or whatever) > > only generates a tree of these MetaInsets and in a second pass we > > transform this into 'real' insets. > > Which is nice, in that the 'big', LyX file parser is simple, but > nasty in that each individual inset must have it's own little parser > to read these data. That's essentially what we have now with > Inset::read.
Indeed. > Not that I'm saying that that's a bad thing... Not really. We know it works and there's a point I might not have mentioned: Some insets may decide not to do any parsing at all but keep their few and rarely accessed attributes in exactly the same form the MetaInset keeps them. So there's not much of a parser needed and there is some 'normative pressure' on all the insets towards a more uniform interface to access attributes. Apart from that, the situation is symmetric: Each inset has a _writer_, too. Andre'
