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

Re: [svg-developers] Shadow Tree

Expand Messages
  • 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 1 of 5 , Jul 2, 2005
    • 0 Attachment
      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 2 of 5 , Jul 4, 2005
      • 0 Attachment
        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 3 of 5 , Jul 5, 2005
        • 0 Attachment
          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.