Help, tied up by the chain

[Niko Sams]

On Fri, May 14, 2010 at 19:00, Ruan Strydom <ruan at jcell.co.za> wrote:
> I need additional info for elements in DTD so what I have done was created a
> class ElementDeclaration extending ClassDeclaration (and the data classes).
>
> ElementDeclarationData has the following members:
>    KDevelop::IndexedString contentType;
>    bool openTagRequired;
>    bool closeTagRequired;
what element doesn't need an open tag?
and what is contentType?

> The problem is that the parser now depends on this, as I need to use DTD
> (parsed and built before SGML) to correctly parse SGML. So I have a recursive
> dependency. In addition to this, all new libs that use the DUChain for SGML
> will now have a dependency on the SGML DUChain lib. And I need to expose the
> headers. Also now the DUChain is not as nicely abstracted anymore.
>
> Should I collapse the dependency tree and make the parser and duchain one lib
> or is there another way of storing this info so that it accessible using the
> abstract classes only?
I don't think they needs to be separated, it's just easier to test
that way. If you need
the DTD and DUChain is the best way to store the DTD - why not.

>
> ps: If the enum uses where int's or if C++ allowed extending enums I could
> have used some of the existing members.
>
> Let me know if I should commit the code/changes and point you to the problem
> area.
yes, please commit somewhere, I would be interested on how the parser
uses the DTD.

Niko