dcsimg
A Flash Developer Resource Site

Page 1 of 3 123 LastLast
Results 1 to 20 of 53

Thread: 'id' attribute in my XML file - strange things happening

  1. #1

    'id' attribute in my XML file - strange things happening

    Hello all,
    I have been working on a project that brings in an XML file generated by a CMS. As a result of the CMS, many of the tags have an 'id' attribute - either a number, or descriptive word 'Main_copy', 'popups' etc.

    Now heres the funny thing -

    When looking at my debugger I happened to notice these id names popping up at the root level of my XML object, and hey presto, I could actually reference any xml node, no matter where it is in the heirarchy of the document using the value of the id attribute. ie: say myXML looks something like this:

    Code:
    <CMSpage SECTION="PLATFORMS" TITLE="Eurosport" id="esport" sectionId="platf">
    <ContentItem id="Main_Copy">
         <EditElement id="first_para">yadda yadda</EditElement>
    </ContentItem>
    </CMSPage>
    then

    Code:
    myXML.first_para = <EditElement id="first_para">yadda yadda</EditElement>
    has anyone else found this / is there any documentation?...

    let me know if you need more info




  2. #2
    btw - this seems to be happening in both F5 (player Win,5,0,30) and MX - havent tried a mac yet

  3. #3
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    So... you're saying that when you load an XML document like you've been using - you can reference the ID attribute as a variable on the root timeline, and that variable holds the node???

  4. #4
    Almost - I can use the id name of a node to reference any childNode (or grand childNode for that matter) so that in the example, if myXML is the name of the XML object I wrote above, then:
    Code:
    myXML.childNodes[0].childNodes[1].childNodes[1]
    
    is the same node as
    
    myXML.first_para
    I know this sounds a bit weird, and I can send you the source files if it would make it any clearer...

  5. #5
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    No - it makes sense, but where did you get the ID atttribute from?? Did you just code it in yourself?

    Each ID attribute is unique - right ?

  6. #6
    The id attribute is part of the XML file produced by the content management system. Yes the id attributes are all unique. I have also found that if you give a numerical id - id="1", id="2" etc, then you can get at them using array notation - ie: myXML[1], myXML[2] etc

  7. #7
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    So.... WOW!! That's cool. Am I missing something?? This CMS... is it a specific language/program?? It sounds like it can be anything... right?? I mean, as long as there are ID attributes in the nodes it sounds like Flash can directly reference them... which would ROCK!!

  8. #8
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    HOLY I CAN'T BELIEVE HOW STUPID I AM!!!!

    THE ID ATTRIBUTE IS NATIVELY PART OF THE XML SPECIFICATION!!!

    (I'm off to research.... )

    Thanks for smackin' me in the forehead with this one!!

  9. #9
    Aha,
    thats news to me (the id bit being a part of the XML spec). I'm just a humble flash cadet who seems to have stumbled accross something v useful!

    Let me know how the research goes - if it'd be useful, I can email you what I've been working on to get a head start...

  10. #10
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    Research done. I just ran to the O'Reilly book I had on XML - which I thought I had gotten everything out of.. guess there were parts I fell asleep in!

    The ID part of the XML spec::

    In your DTD you can define an attribute as type: ID, and that attribute can be placed in any node. The ID attribute has to be unique, and will return the element that the attribute describes.

    I'm thinking that since Flash doesn't really use a DTD to validate XML... it just made the attribute 'id' of type ID.. if that made sense... in other words - any time you add an attribute ID to an element, you should be assigning it a unique identifier, that should return that element (you could just as easily substitute 'node' for 'element').

    So.... what you say should be true. You should be able to reference any node of your XML document by asking for it using it's ID attribute.

    Which leads me to wonder - does the ID attribute have to be a number?? I would say no. Which then leads me to ask - does that mean that you can create a type of hash table reference to nodes in an XML document using the ID attribute with alphanumeric values??

    Holy poopies.... I'm off to open Flash. BRB...

  11. #11
    no, the id number does not have to be numeric. Because of the setup of the xml file I am using, I have both numeric and text values for id - ones even called 'sportex' ! go figure, and I can reference them all in the same way (except that if they are numeric you have to get at them using array notation...)

    It seems the debugger has been useful after all!

  12. #12
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    HOLY-I-THINK-I'M-GONNA-WET-MY-PANTS!!!

    It worked. Just like we thought....

    Use this code::

    Code:
    myXML = new XML;
    myXML.onLoad=handleLoad;
    myXML.load("xml.xml");
    
    function handleLoad(status){
    	status ? parseXML() : trace ("XML not parsed.");
    }
    
    function parseXML(){
    	_root.basic = myXML.firstChild.childNodes[1];
    	_root.next = myXML[1];
    	_root.last = myXML["thisElement"];
    
    	trace("Basic:: "+myXML.firstChild.childNodes[1]);
    	trace("Next:: "+myXML[1]);
    	trace("Last:: "+myXML["thisElement"]);
    
    }
    With this XML:: (spaces added)

    Code:
    < top >
            < first >
                    Here's the first node.
            < / first >
            < second id="1" >
                    Here's the second node.
            < / second >
            < third id="thisElement" >
                    Here's the third node.
            < / third >
    < / top >
    And the results in the output window::

    Code:
    Basic:: < first >
    
                    Here's the first node.
    
            < / first >
    Next:: < second id="1" >
    
                    Here's the second node.
    
            < / second >
    Last:: < third id="thisElement" >
    
                    Here's the third node.
    
            < / third >
    OH YEAH BABY!!!

    .... * thinks and realizes that maybe everybody already knew this.... and he's the only one who didn't.. so he's gonna look stupid for getting so excited over this....

    ... * realises he doesn't care

    OH YEAH BABY!!!

  13. #13
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    After reading back over the posts in this thread I realise two questions weren't really answered::

    1. You can use simple dot notation to 'call' the elements using the ID attribute (for example - using the above XML - myXML.thisElement would return the same as myXML["thisElement"], which makes sense).

    and

    2. You can NOT refer to the ID attribute as if it were an element. For instance _root.thisElement will NOT return the same as myXML.thisElement or myXML["thisElement"]. Which also makes sense.

    WAIT - I just found more that makes sense...

    This type of reference is similar to for-in or hash referencing - if two elements have the same ID attribute value, then you wont know which one will get called (The last one top-to-bottom has been referenced). Which is part of the spec as well - you shuold use unique identifiers for your elements.

    And, last for now - The referencing is not 'nestable'. In other words - you can not say myXML.thisElement.inside and expect to get an element in return. Again, this makes sens, since the ID attirbute has to be unique - you wouldn't need to do that (myXML.thisElement.inside) to get yor element - you could jsut say myXML.inside...

    Well - off to my 'bill-paying' job... I'm excited for the possibilities here...

  14. #14
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    On the last point, could you just set another XML object to the node:

    newXML = myXML.allTheCode;

    then get at the elements inside.

    That would be cool for stuff where you need to reference a node that is deep in the XML structure.

    BTW -- I love watching the posts where you get more and more excited about this.

    Thanks

    Luke
    (Now officially Scum)
    [Edited by tupps on 04-17-2002 at 11:17 PM]

  15. #15
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    Finally - a reply.. I was beginning to think I was invisible...

    I thin kit is exciting... it's almost like MM planed this 'Easter egg hunt' with their software...

    MORE EGGS!!! MORE EGGS!!!

    < narcileptically falls into silence>

    < was that a word?? >

  16. #16
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    You are on Fig Leaf, with the guys who hunt through all the FSCommand stuff working out what the hidden commands are. They are the guys find the Eggs.

    I think this is intended behaviour. I just wonder why Macromedia never documented this stuff. I can understand why some of the save files and shelling commands are undocumented, but this should be in the XML documentation.

    It is also a helpful way to combat the whitespace brigade. It seems to me that peoples biggest problem is actually finding the start of their XML as most people put whitespace between the document reference and the start of the XML.

    Thanks

    Luke



  17. #17
    Junior Member
    Join Date
    Apr 2001
    Posts
    7

    Re: Uhh...

    This is a cool feature, if you have an XML structure that will allow for it. The only problem with this is being able to assign unique IDs to everything and have it all make sense. The reason that you name the XML nodes the way you do is to make it readable and structured. Using the ID feature _could_ quickly throw structure out the window.

    Still, within a smaller context, this could be very useful. It would also be an easy way to check for the XML's EOF by having a node tacked onto the end that had a specific ID.

    Still ... there isn't an icon to express your excitement, is there. ;o)

  18. #18
    I was beginning to think this was gonna be mine and VayKent's best kept secret!

    I know what you are saying OPus, but there is a difference between the tag name - which I tend to use to define the 'type' of info, and the id attribute - which by its name defines a unique identifier for a piece of information.

    So this really is as useful as I thought it could be - Yay!...


  19. #19
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    I could also imagine it could be usefull in session tracking type applications.

    Eg: XML that describes books by different categories. Now you might have 20 categories but I always want to open in the technical section. There i could put an ID tag there so I can go to and display that section. While all the categories get displayed as options.

    Thanks

    Luke



  20. #20
    Junior Member
    Join Date
    Mar 2002
    Posts
    7

    Wow!

    I've been learning all about XML and how to parse it in flash, and so far there just hasn't been a clean way to do it... even for the simplest XML docs, there's a mess of arrays and other junk involved just to display it. BUT THIS ROCKS! AWESOME FIND GUYS! Using IDs I've been able to reduce what was once a page of ActionScript to just several lines!

    Code:
    theXML = new XML();
    theXML.onLoad = parseXML;
    theXML.load("http://myurlwhichiamhiding.com/doc.xml");
    
    function parseXML () { display = theXML.name1 +" = "+theXML.email1 }
    I'm going to explore this method of doing things a ton over the next few (work)days, and see what other amazing things can be done with it. I know a lot of people are always talking about speed of parsing XML in Flash and theres Nitro and all those scripts... but I really don't care about speed as the XML docs I work with really aren't THAT large anyways. Wether this is faster or slower in the end is of no concern to me, but I would be interesting to know none-the-less...

    THANKS YOU TWO!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center