Re: [Flashcoders] practical limits to size of XML files?
on the subject of Xpath with large files, i've been impressed with the speed of XMLUtilities for large XML files. granted it really is just a wrapper for the built in XML functions, but i found it very fast and light. and really i hardly use a fraction of what Xpath is capable of anyway. sorry for being off topic, in regards to that matter i feel the subject has been covererd by greater minds than mine. ;) On 3/12/07, Ron Wheeler [EMAIL PROTECTED] wrote: We do the same thing. Once you get the hang of the XML classes it is not too bad and you can really tune your access. If you are doing your own tree climbing it gets easier to deal with a multi-file XML structure that can help reduce the amount of XML that you have to parse in any given operation. You can break the tree from the root or from the leaves to optimize the apparent latency to the user. Ron Merrill, Jason wrote: I agree with what's been said, and would add that if you cannot use Flash 9 AS3 for your XML, then be wary of the third party XML parsers when dealing with XML files of this size. I had been in love with xfactorstudio's Xpath classes (which are mostly great by the way), until I had to read in a large XML file and convert to objects in Flash (I had to convert to objects in order to preprare the data for a webservice transfer). I ended up abandoning those classes and used the build-in XML classes. While very cumbersome to use, it was a huge improvement in performance. Jason Merrill Bank of America Global Technology Operations Learning Leadership Development eTools Multimedia Team ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] practical limits to size of XML files?
I've done in the past something as Rakos says and i think it could be a good choice. If you really have to go for the xml, i'd say: - wherever possible, try to use attributes instead of nodes to avoid unnecessary nesting. - wherever possible, split the xml files so you can read exactly what the user needs and not everything. Good luck : ) On 3/12/07, Rákos Attila [EMAIL PROTECTED] wrote: A while ago I had problems with parsing and processing a large XML. It was too slow even after utilizing some tricks and optimizations, so I decided to convert the XML into an ActionScript source file containing constant arrays and objects. This AS file was then compiled into swf, loaded into the main movie and it became much more faster, there was no noticable processing time. Since on CD you will not need an editable XML, maybe you can try such way, too. Attila ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com -- Juan Delgado - Zárate http://zarate.tv http://dandolachapa.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
RE: [Flashcoders] practical limits to size of XML files?
I agree with what's been said, and would add that if you cannot use Flash 9 AS3 for your XML, then be wary of the third party XML parsers when dealing with XML files of this size. I had been in love with xfactorstudio's Xpath classes (which are mostly great by the way), until I had to read in a large XML file and convert to objects in Flash (I had to convert to objects in order to preprare the data for a webservice transfer). I ended up abandoning those classes and used the build-in XML classes. While very cumbersome to use, it was a huge improvement in performance. Jason Merrill Bank of America Global Technology Operations Learning Leadership Development eTools Multimedia Team ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] practical limits to size of XML files?
We do the same thing. Once you get the hang of the XML classes it is not too bad and you can really tune your access. If you are doing your own tree climbing it gets easier to deal with a multi-file XML structure that can help reduce the amount of XML that you have to parse in any given operation. You can break the tree from the root or from the leaves to optimize the apparent latency to the user. Ron Merrill, Jason wrote: I agree with what's been said, and would add that if you cannot use Flash 9 AS3 for your XML, then be wary of the third party XML parsers when dealing with XML files of this size. I had been in love with xfactorstudio's Xpath classes (which are mostly great by the way), until I had to read in a large XML file and convert to objects in Flash (I had to convert to objects in order to preprare the data for a webservice transfer). I ended up abandoning those classes and used the build-in XML classes. While very cumbersome to use, it was a huge improvement in performance. Jason Merrill Bank of America Global Technology Operations Learning Leadership Development eTools Multimedia Team ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
[Flashcoders] practical limits to size of XML files?
Hi all, I have a project that I have spec'ed for developing in Flash MX 04 (or Flash 8) along with Director MX 04. The project has a large amount of data that will be read into the program. I'm trying to determine whether there are any practical limitations to using XML with Flash. The data lends itself beautifully to XML, and would be an easy conversion to XML from the source documents provided by my client. However, there is a considerable amount of data, consisting of 5000 records in a structure with nodes nested 7-10 levels deep, such as: -- + family + subgroup (1 to n levels of subgroups, varies by family) + subgroup + subgroup + subgroup + part-type + part x part-number x part-description + item x item-type x item-filename x item-label -- + NODE (0 or more of each) x TBD: ELEMENT or ATTR of parent element -- The data will not require sorting. Data will be presented in the sequence contained in the XML file. In addition, searching will only be done by *part-number* with optional filtering by *item-type*. So, I have approx. 5000 *item* records and prefer to do this with XML. The project is CD-based, not an online application. Is it practical to read/parse that much XML into a single XML object in a Flash application running from CD? ...Rob ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] practical limits to size of XML files?
My suggestion would be to create the file with dummy data, and run some processing tests on it on machines of various speeds. My guess is that you'll find it to be pretty slow unless your processing code is very clever. I have a project with a 250KB external XML file as content and certain sorting and filtering options do take a while. Another which is 210KB has similar problems. If your app will tolerate it, you could do processor-intensive operations across multiple frames and present an hourglass to the user or something. If performance is super imporant, you might try organizing your data in a tabular format, which will be a much larger file, but should be quicker to process and sort. Or perhaps you could do it in Flash 9 and take advantage of E4X in AS3. If you know everyone running it will be on super fast machines, then maybe you don't have anything to worry about. -josh On Mar 11, 2007, at 10:34 AM, Hairy Dog Digital wrote: Hi all, I have a project that I have spec'ed for developing in Flash MX 04 (or Flash 8) along with Director MX 04. The project has a large amount of data that will be read into the program. I'm trying to determine whether there are any practical limitations to using XML with Flash. The data lends itself beautifully to XML, and would be an easy conversion to XML from the source documents provided by my client. However, there is a considerable amount of data, consisting of 5000 records in a structure with nodes nested 7-10 levels deep, such as: -- + family + subgroup (1 to n levels of subgroups, varies by family) + subgroup + subgroup + subgroup + part-type + part x part-number x part-description + item x item-type x item-filename x item-label -- + NODE (0 or more of each) x TBD: ELEMENT or ATTR of parent element -- The data will not require sorting. Data will be presented in the sequence contained in the XML file. In addition, searching will only be done by *part-number* with optional filtering by *item-type*. So, I have approx. 5000 *item* records and prefer to do this with XML. The project is CD-based, not an online application. Is it practical to read/parse that much XML into a single XML object in a Flash application running from CD? ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] practical limits to size of XML files?
I would not worry about this. You are on the right track and in the worst case you can break the XML file into a set of xml files referenced by the top level which then acts as a Table of Contents. It is hard to build an XML file that is as big as an sound file. 5000 records of 50 characters is only 250,000 bytes. You might want to use very short node names pt rather than part pn rather than part-number pd rather than part-description it item-type if item-filename il item-label This will help reduce the total file size. In addition to a top level strategy of multiple files, you might want to put the product details in individual XML files since you will most likely only ask for the details for a very small number of parts. This creates a large number of files and you probably need a good directory structure to keep access times small. Other than problems of big directories under windows, computers are pretty good at this sort of stuff. Ron Hairy Dog Digital wrote: Hi all, I have a project that I have spec'ed for developing in Flash MX 04 (or Flash 8) along with Director MX 04. The project has a large amount of data that will be read into the program. I'm trying to determine whether there are any practical limitations to using XML with Flash. The data lends itself beautifully to XML, and would be an easy conversion to XML from the source documents provided by my client. However, there is a considerable amount of data, consisting of 5000 records in a structure with nodes nested 7-10 levels deep, such as: -- + family + subgroup (1 to n levels of subgroups, varies by family) + subgroup + subgroup + subgroup + part-type + part x part-number x part-description + item x item-type x item-filename x item-label -- + NODE (0 or more of each) x TBD: ELEMENT or ATTR of parent element -- The data will not require sorting. Data will be presented in the sequence contained in the XML file. In addition, searching will only be done by *part-number* with optional filtering by *item-type*. So, I have approx. 5000 *item* records and prefer to do this with XML. The project is CD-based, not an online application. Is it practical to read/parse that much XML into a single XML object in a Flash application running from CD? ...Rob ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
