Re: [gdome]Gdome and External node data?

[Tobias Peters <t-peters gmx de>]

On Wed, 3 Apr 2002, Luca Padovani wrote:
> Hi John,
>
> > nodes.  I was wondering if Gdome allows for either arbitrary data to be
> > attached to nodes
>
> yes, this is possible. There is a field "user_data" associated to each
> node which is usually used to store a pointer to another data structure
> (layering). It is an oversimplified version of the "user data" capability
> in DOM level 3 (still to become recommendation)

John, be sure to understand the reference counting memory management used
by gdome, and read Luca's mail from Dec 4 with subject "problem with
user_data" which describes how to protect your precious user_data pointers
from disappearing. Search the mailing list archives.

> > or the ability to subclass Gdome nodes to include new
> > functionality while still being able to "look" like a Gdome tree to the
> > Gdome interfaces?
>
> you are referring to the inheritance vs. layering extension
> mechanism. Inheritance is not supported by the C implementation, not now
> at least. But it might be the case that some bindings for other languages
> (Ruby? Perl?) allow this. The bindings I've been working on are for C++

Ruby supports extending classes and even single objects with methods at
any time. To achieve the desired behaviour, you would probably extend
the DOM classes like this:

module Gdome
  class Element
    def svg_x
      return Float(getAttribute("x"))
    end
    def svg_x=(new_x)
      setAttribute("x", String(new_x))
      return new_x
    end
  end
end

# and then do
point.svg_x += translation_vector.x

You could also do some very smart things and add methods only to specific
Elements based on their tag names or something similar, but this would
require quite some experience with ruby. I am almost sure you could do
something similar in Perl.

The ruby wrapper is not up to date, I regret. The current wrapper supports
gdome2 0.6.9, the next release will support 0.7.1 and will be available
within this month. (And will only wrap the DOM Core module, no Events etc,
since I don't need these)

> > multiple tags or attributes into one attribute.  To access the simple
> > attributes as text would be both slow and require parsing of the
> > attributes every time a point needed to be changed.
>
> This is true. It is also true, however, that in many cases when you modify
> attributes you are doing editing, and that the speed you edit the document
> is millions of time slower that the speed of parsing attributes.

I can only second that. Write your own get_float_attribute,
set_float_attribute functions to avoid having your parsing code cluttered
all over the place, and you're done.

> > My other question is can Gdome's scripting bindings be passed a Gdome
> > tree from C, manipulate it and return the results back?
>
> I can answer "yes" for my bindings (Ocaml and C++). In that case I access

The function "pass a Gdome tree from C" is not yet implemented, but I
would include it in the next release. The ruby binding also modifies the
Gdome2 nodes immediately.

Tobias