> -----Original Message----- > From: Kenton Gray [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 08, 2005 10:41 AM > To: CF-Talk > Subject: Re: Sorting of Nested Structures Headaches > > Would using an XML object be more effective? Is there a large > performance penalty for that? I am amazed that something as seemingly > essential as order is uncontrollable. The list sort works, but I can > imagine this issue coming up again, and it could make the code > difficult to maintain.
XML might be more effective at keeping order - but Arrays are MOST effective at maintaining ordered data. That's all they're designed for - which is why you've got "insertat()" and "append()" and "prepend()" and all the other order-specific functions available to arrays but not to structs. While, technically, they share some aspects Arrays are generally known as "indexed" objects - they maintain order - while structs are considered "unindexed" objects (or "associative arrays"). Indexed objects maintain relationships to the data via position or order. You access the "third element" or the "last element". Unindexed objects maintain relationships between the labels and the data. You access "this field" or "that key". Barney is right, of course, that you can get the key list and sort it outside of the struct - but that only works if your order is represented in the key names. For example it would work fine with "Name1", "Name2" and "Name3" - the order is implicit in the names. However it wouldn't work with "FirstName", "MiddleName", and "LastName" since the order of the name isn't implicit in the names. However in either case an array would work fine. Remember that arrays can be stored as structure data and vice-versa - you can have an array or structs or a struct full of arrays or any mixture in-between. Also, if you want to go in the direction of a new data type don't consider XML (XML isn't good as a data type - just as a transport medium and possible long term storage). CF Queries do most of what you want: they maintain order of the columns, are accessible via both indexed and unindexed notation and can store any data type (including complex objects although this is rarely done). In your original example it seems like you've hit a conceptual wall, not a technical one. What is this "beginning date"? Is it a property (key name)? If so why are trying to access things "on order" instead of by name. If you want "beginning date" first just access mystruct.beginingdate first. If "beginningdate" is a field (a structure unto itself) then you can still do it either by having a structure where the keys names are the field names (so you can still access something like "allfield.beginningdate") or place all fields in an array in the order they appear. In the latter case you could then loop over the set and display the fields. In really complex cases you might need two data structres. For example a struct of all of the fields in no particular order and an associated array of references to those structs in the order you want. In any case it's a good rule of thumb: if you'll be accessing your data by name and order is not important, use a struct. If you'll be accessing your data by position and/or order is important use an array. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208979 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
