Loading ...
Sorry, an error occurred while loading the content.
 

Shadow Tree

Expand Messages
  • Mitzie
    Hello, I ve searched the net as well as the SVG 1.1 and 1.2 specs for an actual definition of a shadow tree. I ve found the definition For storage of the
    Message 1 of 5 , Jul 1, 2005
      Hello,
      I've searched the net as well as the SVG 1.1 and 1.2 specs for an
      actual definition of a shadow tree. I've found the definition "For
      storage of the distributable files, we create "object trees" which
      mimic the organization of the
      source code directory /usr/src (see figure 2). There is one object
      tree for each different architecture or
      operating system. We called the directories where object files are
      stored, "Shadow Trees", because their
      structure is a projection of the source code tree.
      "
      however this really does not apply to the RCC rendering model used in
      SVG. Can anyone explain what a shadow tree is and why it is such an
      advantage to use it?

      Thanks.
    • Holger Will
      ... Hi Mitzie ok, let me try, if you have a element, the used content gets cloned and virtually appended to the element. this cloned content is a
      Message 2 of 5 , Jul 2, 2005
        Mitzie schrieb:

        > Hello,
        > I've searched the net as well as the SVG 1.1 and 1.2 specs for an
        > actual definition of a shadow tree. I've found the definition "For
        > storage of the distributable files, we create "object trees" which
        > mimic the organization of the
        > source code directory /usr/src (see figure 2). There is one object
        > tree for each different architecture or
        > operating system. We called the directories where object files are
        > stored, "Shadow Trees", because their
        > structure is a projection of the source code tree.
        > "
        > however this really does not apply to the RCC rendering model used in
        > SVG. Can anyone explain what a shadow tree is and why it is such an
        > advantage to use it?
        >
        > Thanks.
        >
        Hi Mitzie

        ok, let me try, if you have a <use> element, the used content gets
        cloned and virtually appended to the <use> element.
        this cloned content is a "shadow tree" of the original element that
        gets <use>ed.
        RCC or now sXBL is taking the concept of "shadow tree"s a step further,
        by giving you more controll of the creation process and insertion points
        of a "shadow tree".

        hope im not to far off.
        cheers
        Holger
      • sholla@alpine-la.com
        Let me add my bit here - since I recently explored using the shadow tree for the sue element itself: By directly replacing content into the main tree you
        Message 3 of 5 , Jul 2, 2005
          Let me add my bit here - since I recently explored using the shadow tree
          for the sue element itself:

          By directly replacing "content" into the main tree you lose modularity.
          Here is my situation embed an SVG file within a parent SVG file. No big
          deal. But, what if you have styling and other defs which have similar id's
          to the parent/sibling documents. The way it works in SVG is that the last
          instance will override all others in terms of these id's - so in effect you
          would probably "lose" some elements of the parent document . This applies
          to any other elements too such as graphics elements/scripts/etc. So, if you
          need to have "object oriented" SVG and associated styling/etc. this shadow
          tree is the way to go. In terms of the overhead I think its there but not
          that significant compared to the advantages.




          Holger Will
          <holger@treebuilder To: svg-developers@yahoogroups.com
          .de> cc:
          Sent by: Subject: Re: [svg-developers] Shadow Tree
          svg-developers@yaho
          ogroups.com


          07/02/2005 12:01 PM
          Please respond to
          svg-developers






          Mitzie schrieb:

          > Hello,
          > I've searched the net as well as the SVG 1.1 and 1.2 specs for an
          > actual definition of a shadow tree. I've found the definition "For
          > storage of the distributable files, we create "object trees" which
          > mimic the organization of the
          > source code directory /usr/src (see figure 2). There is one object
          > tree for each different architecture or
          > operating system. We called the directories where object files are
          > stored, "Shadow Trees", because their
          > structure is a projection of the source code tree.
          > "
          > however this really does not apply to the RCC rendering model used in
          > SVG. Can anyone explain what a shadow tree is and why it is such an
          > advantage to use it?
          >
          > Thanks.
          >
          Hi Mitzie

          ok, let me try, if you have a <use> element, the used content gets
          cloned and virtually appended to the <use> element.
          this cloned content is a "shadow tree" of the original element that
          gets <use>ed.
          RCC or now sXBL is taking the concept of "shadow tree"s a step further,
          by giving you more controll of the creation process and insertion points
          of a "shadow tree".

          hope im not to far off.
          cheers
          Holger


          -----
          To unsubscribe send a message to:
          svg-developers-unsubscribe@yahoogroups.com
          -or-
          visit http://groups.yahoo.com/group/svg-developers and click "edit my
          membership"
          ----

          <?---- LSpots keywords ?> <?---- HM ADS ?>
          YAHOO! GROUPS LINKS

          Visit your group "svg-developers" on the web.

          To unsubscribe from this group, send an email to:
          svg-developers-unsubscribe@yahoogroups.com

          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        • tony_bursey
          That is not entirely true. Although it is true that elements later in the document are drawn over elements previous in the document, if you try
          Message 4 of 5 , Jul 4, 2005
            That is not entirely true. Although it is true that elements later
            in the document are drawn over elements previous in the document, if
            you try document.getElementById('someID'), the first element in the
            document matching that ID is returned rather than the last one.

            --- In svg-developers@yahoogroups.com, sholla@a... wrote:
            >
            > Let me add my bit here - since I recently explored using the
            shadow tree
            > for the sue element itself:
            >
            > By directly replacing "content" into the main tree you lose
            modularity.
            > Here is my situation embed an SVG file within a parent SVG file.
            No big
            > deal. But, what if you have styling and other defs which have
            similar id's
            > to the parent/sibling documents. The way it works in SVG is that
            the last
            > instance will override all others in terms of these id's - so in
            effect you
            > would probably "lose" some elements of the parent document . This
            applies
            > to any other elements too such as graphics elements/scripts/etc.
            So, if you
            > need to have "object oriented" SVG and associated styling/etc.
            this shadow
            > tree is the way to go. In terms of the overhead I think its there
            but not
            > that significant compared to the advantages.
            >
            >
            >
            >


            > Holger
            Will

            > <holger@treebuilder To: svg-
            developers@yahoogroups.com

            > .de>
            cc:

            > Sent by: Subject: Re:
            [svg-developers] Shadow
            Tree
            > svg-
            developers@yaho

            >
            ogroups.com

            >


            >


            > 07/02/2005 12:01
            PM

            > Please respond
            to

            > svg-
            developers

            >


            >


            >
            >
            >
            >
            > Mitzie schrieb:
            >
            > > Hello,
            > > I've searched the net as well as the SVG 1.1 and 1.2 specs for an
            > > actual definition of a shadow tree. I've found the
            definition "For
            > > storage of the distributable files, we create "object trees"
            which
            > > mimic the organization of the
            > > source code directory /usr/src (see figure 2). There is one
            object
            > > tree for each different architecture or
            > > operating system. We called the directories where object files
            are
            > > stored, "Shadow Trees", because their
            > > structure is a projection of the source code tree.
            > > "
            > > however this really does not apply to the RCC rendering model
            used in
            > > SVG. Can anyone explain what a shadow tree is and why it is
            such an
            > > advantage to use it?
            > >
            > > Thanks.
            > >
            > Hi Mitzie
            >
            > ok, let me try, if you have a <use> element, the used content gets
            > cloned and virtually appended to the <use> element.
            > this cloned content is a "shadow tree" of the original element that
            > gets <use>ed.
            > RCC or now sXBL is taking the concept of "shadow tree"s a step
            further,
            > by giving you more controll of the creation process and insertion
            points
            > of a "shadow tree".
            >
            > hope im not to far off.
            > cheers
            > Holger
            >
            >
            > -----
            > To unsubscribe send a message to:
            > svg-developers-unsubscribe@yahoogroups.com
            > -or-
            > visit http://groups.yahoo.com/group/svg-developers and click "edit
            my
            > membership"
            > ----
            >
            > <?---- LSpots keywords ?> <?---- HM ADS ?>
            > YAHOO! GROUPS LINKS
            >
            > Visit your group "svg-developers" on the web.
            >
            > To unsubscribe from this group, send an email to:
            > svg-developers-unsubscribe@yahoogroups.com
            >
            > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
            Service.
          • sholla@alpine-la.com
            I agree with that. But, I think the way the drawing happens is the last element overwrites any previous element by that id. So, though you d get the first
            Message 5 of 5 , Jul 5, 2005
              I agree with that. But, I think the way the drawing happens is the last
              element overwrites any previous element by that id. So, though you'd get
              the first element by that id the effective display shows the last element -
              which means it overwrites the earlier elements when drawing. Additionally,
              if you want to access the elementById() for the child document - no way
              unless you walk through the whole document tree!

              So one possibility is to change the id's of all elements that are to be
              embedded - or at least those that match any sibling/parent document element
              id's - that's too much processing I believe; but we can get the right DOM
              access to the id and the right drawing effect too. Or just use the use
              element and one can get the elements via the DOM as you suggested and get
              the right drawing effect too.



              "tony_bursey"
              <tony_bursey@yahoo. To: svg-developers@yahoogroups.com
              com> cc:
              Sent by: Subject: [svg-developers] Re: Shadow Tree
              svg-developers@yaho
              ogroups.com


              07/04/2005 01:07 PM
              Please respond to
              svg-developers






              That is not entirely true. Although it is true that elements later
              in the document are drawn over elements previous in the document, if
              you try document.getElementById('someID'), the first element in the
              document matching that ID is returned rather than the last one.

              --- In svg-developers@yahoogroups.com, sholla@a... wrote:
              >
              > Let me add my bit here - since I recently explored using the
              shadow tree
              > for the sue element itself:
              >
              > By directly replacing "content" into the main tree you lose
              modularity.
              > Here is my situation embed an SVG file within a parent SVG file.
              No big
              > deal. But, what if you have styling and other defs which have
              similar id's
              > to the parent/sibling documents. The way it works in SVG is that
              the last
              > instance will override all others in terms of these id's - so in
              effect you
              > would probably "lose" some elements of the parent document . This
              applies
              > to any other elements too such as graphics elements/scripts/etc.
              So, if you
              > need to have "object oriented" SVG and associated styling/etc.
              this shadow
              > tree is the way to go. In terms of the overhead I think its there
              but not
              > that significant compared to the advantages.
              >
              >
              >
              >


              > Holger
              Will

              > <holger@treebuilder To: svg-
              developers@yahoogroups.com

              > .de>
              cc:

              > Sent by: Subject: Re:
              [svg-developers] Shadow
              Tree
              > svg-
              developers@yaho

              >
              ogroups.com

              >


              >


              > 07/02/2005 12:01
              PM

              > Please respond
              to

              > svg-
              developers

              >


              >


              >
              >
              >
              >
              > Mitzie schrieb:
              >
              > > Hello,
              > > I've searched the net as well as the SVG 1.1 and 1.2 specs for an
              > > actual definition of a shadow tree. I've found the
              definition "For
              > > storage of the distributable files, we create "object trees"
              which
              > > mimic the organization of the
              > > source code directory /usr/src (see figure 2). There is one
              object
              > > tree for each different architecture or
              > > operating system. We called the directories where object files
              are
              > > stored, "Shadow Trees", because their
              > > structure is a projection of the source code tree.
              > > "
              > > however this really does not apply to the RCC rendering model
              used in
              > > SVG. Can anyone explain what a shadow tree is and why it is
              such an
              > > advantage to use it?
              > >
              > > Thanks.
              > >
              > Hi Mitzie
              >
              > ok, let me try, if you have a <use> element, the used content gets
              > cloned and virtually appended to the <use> element.
              > this cloned content is a "shadow tree" of the original element that
              > gets <use>ed.
              > RCC or now sXBL is taking the concept of "shadow tree"s a step
              further,
              > by giving you more controll of the creation process and insertion
              points
              > of a "shadow tree".
              >
              > hope im not to far off.
              > cheers
              > Holger
              >
              >
              > -----
              > To unsubscribe send a message to:
              > svg-developers-unsubscribe@yahoogroups.com
              > -or-
              > visit http://groups.yahoo.com/group/svg-developers and click "edit
              my
              > membership"
              > ----
              >
              > <?---- LSpots keywords ?> <?---- HM ADS ?>
              > YAHOO! GROUPS LINKS
              >
              > Visit your group "svg-developers" on the web.
              >
              > To unsubscribe from this group, send an email to:
              > svg-developers-unsubscribe@yahoogroups.com
              >
              > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
              Service.




              -----
              To unsubscribe send a message to:
              svg-developers-unsubscribe@yahoogroups.com
              -or-
              visit http://groups.yahoo.com/group/svg-developers and click "edit my
              membership"
              ----

              <?---- LSpots keywords ?> <?---- HM ADS ?>
              YAHOO! GROUPS LINKS

              Visit your group "svg-developers" on the web.

              To unsubscribe from this group, send an email to:
              svg-developers-unsubscribe@yahoogroups.com

              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            Your message has been successfully submitted and would be delivered to recipients shortly.