[Lazarus] How to get the package version from a LPK file?

Graeme Geldenhuys graemeg.lists at gmail.com
Tue Nov 29 10:50:53 CET 2011

On 29/11/2011, Hans-Peter Diettrich <DrDiettrich1 at a....> wrote:
> Right, using XML without documentation sucks :-(

In this case, I don't think even documentation would have helped.

> I had the same impression when I tried to implement XML output of fpdoc
> projects right now.

I feel your pain. :-)

> I'm not sure why the XML implementation is cluttered into an stack of
> derived classes, when only TDomElement is halfways usable.

As far as I can see, XML handling should be rather simple. After all,
it is a classic case of a tree hierarchy of data elements. Two classes
only. TXMDocument and TXMLNode. That should be all that is needed to
find anything in XML. TXMLNode represents itself, and acts as a
container for its child nodes. A basic Composite Design pattern

> maybe 'key' or something else. That makes a general Find method near
> impossible :-(

I disagree. Just read the following article I found. This guy use the
same idea I mentioned in my example, and as I mentioned above - about
composite design pattern.


For those too lazy to read the article, here is the gist of it.

    TxmlNode = class
      property Name: string;
      property Value: string;
      property Parent: TxmlNode;
      property Child[Idx: integer]: TxmlNode;
      property ChildrenCount: integer;
      property Node[Path:string]: TxmlNode; default;

A simple easy to understand API. Node[] takes a Path not a Name. So
you can do things like


...and if you need to retrieve a list of nodes...

   n := MyNode.Node[/Config/Package/Files];
   if Assigned(n) then
      for i := 0 to n.ChildrenCount-1 do

I would even add a FindNode() method which internally uses Node[] -
just to make in very clear to the developer using this class.

I guess if I ever need to work with XML (lets hope that never
happens), I'll implement my (yet again) own classes. Programming is
supposed to solve problems, not create more. The alternative would
have been to modify the FCL DOM code, but that would probably cause
breakages all over existing code (eg: fpdoc, makeskel etc) - so FCL
DOM code is now stuck in near unusable limbo land. :-(

  - Graeme -

fpGUI - a cross-platform Free Pascal GUI toolkit

More information about the Lazarus mailing list