Gennadiy Rozental wrote:

  Here is my vision on the problem, couple ideas on XML parser design:
1. No xmlChar type -> template parameter

hmm, what code did you look at ? I *do* use templates for this. I use 'xmlChar' internally as that's the type used by libxml2. But that part is private, the public interface uses a 'string' template parameter in conjunction with a 'convert' trait that delivers the in/out conversion between xmlChar and 'string'.

2. No hardcoded virtual functions. In some refinements it still may come to
use virtual functions here and there. One way to achieve this is to supply
implementation as template parameter:

I don't understand what's so 'outdated' about virtual functions. Why must I avoid them and use templates everywhere ?

But I see your point, I could bind individual callback handlers with boost::function<>...

3. Most probably above may not be good enough. For better reusability let
then use multiple template parameters for different types of handlers:

Hmm, that looks pretty clumsy, considering the number of different handlers, and thus the numbers of template parameters. Why not just bind each handler callback individual to the parser, as parser already is a stateful object.


4. There maybe several "flavors" of document handlers. One simple: as usual
concrete handler needs to expose methods like on_start_element and accept
the name plus attributes. As an alternative we may consider document
handlers supporting "named callbacks" (in a form of boost::function<...>)
registration. IOW such handler would call a callback when element with
desired name encountered. There are other alternatives.

interesting. However, I'd suggest to add such convenience on top of a basic layer that is 'functionally complete'.

I am sure that there also could be Spirit-based or Spirit-like solution.
Check with the Spirit guys.

Well, sure, people can always rewrite xml parsers. But as I suggested earlier, that is a *big* job, and there is much more than parsing, at least if you look not only at sax but dom etc.

Regards,
                Stefan

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to