On Sunday 29 July 2007 08:47:50 Maciej Stachowiak wrote:
> On Jul 28, 2007, at 3:52 AM, Lars Knoll wrote:
> > On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:
> >> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
> >>
> >> Other organizations have requested the ability to use other XML
> >
On Jul 28, 2007, at 3:52 AM, Lars Knoll wrote:
On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:
On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
Other organizations have requested the ability to use other XML
parsers as well, such as expat. Seems like in the long run we want a
diff
On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:
> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
> > On Friday 27 July 2007 16:50:01 Darin Adler wrote:
> >> I'm not happy with the code organization here. XMLTokenizer now has
> >> tons of ifdefs and two separate implementations. It's fin
Hi,
Yes, we had multiple xml parsing backends and were pleased with it at the
time.
The KDOM code is here:
http://websvn.kde.org/trunk/kdenonbeta/kdom/
The relevant code is in backends/ and parser/.
You can request a parser using KDOMParserFactory depending on the
requirements (qdom couldnt handl
Didn't KDOM have an XML parsing abstraction? Would that be worth
studying?
dave
On Jul 27, 2007, at 3:26 PM, Maciej Stachowiak wrote:
On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
On Friday 27 July 2007 16:50:01 Darin Adler wrote:
I'm not happy with the code organization here. XMLToke
On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
On Friday 27 July 2007 16:50:01 Darin Adler wrote:
I'm not happy with the code organization here. XMLTokenizer now has
tons of ifdefs and two separate implementations. It's fine to have a
QXmlStream implementation, but the two implementations sho
On Friday 27 July 2007 21:15:27 Lars Knoll wrote:
> On Friday 27 July 2007 21:05:00 Darin Adler wrote:
> > On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote:
> > > I'm fine with moving to this approach (even though it'll still lead
> > > to some code duplication if we do it the easy way without
> > >
On Friday 27 July 2007 21:05:00 Darin Adler wrote:
> On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote:
> > I'm fine with moving to this approach (even though it'll still lead
> > to some code duplication if we do it the easy way without
> > refactoring).
>
> I don't think we should insist on doing it
On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote:
I'm fine with moving to this approach (even though it'll still lead
to some code duplication if we do it the easy way without
refactoring).
I don't think we should insist on doing it without refactoring. It
seems good to add private member f
On Friday 27 July 2007 20:50:53 Darin Adler wrote:
> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
> > 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp
> > and keep a common XMLTokenizer.cpp for code that is used in both.
>
> I like that option best. It's the pattern used in pla
On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp
and keep a common XMLTokenizer.cpp for code that is used in both.
I like that option best. It's the pattern used in platform for cases
like this.
-- Darin
__
On Friday 27 July 2007 16:50:01 Darin Adler wrote:
> I'm not happy with the code organization here. XMLTokenizer now has
> tons of ifdefs and two separate implementations. It's fine to have a
> QXmlStream implementation, but the two implementations should be in
> separate files, side by side, as we
I'm not happy with the code organization here. XMLTokenizer now has
tons of ifdefs and two separate implementations. It's fine to have a
QXmlStream implementation, but the two implementations should be in
separate files, side by side, as we do in the platform layer.
Or the XML parser should
13 matches
Mail list logo
