>From: Matt Liotta [mailto:[EMAIL PROTECTED]
>Sent: Monday, October 06, 2003 12:51 AM
>To: CF-Talk
>Subject: Re: Sorting CFCs: Structures over Arrays in collections
>
>> Just finished a marathon coding session and thought I'd share/get
some
>> opinions on some of the things I've found concerning CFCs and
sorting.
>> I'm new CFCs and OO, so much of this may seem amateurish, but I
expect
>> that many CFers are in the same position.��I hope it may help
somebody
>> or prompt discussion that heads off bad habits before they set in.
>>
>You may find better responses if you send each of your questions
>separately as this email is rather long and touches on several
subjects.
Well - there wasn't really any questions at all here. ;^)
This was meant to be just a general "here's what I've found out; what do
you think" message - not a query so much as something to kick off
discussion.
>> I began, as everything I've read suggests, by creating an internal
>> array
>> to hold the components.��I now think that was a mistake and have
>> switched to structures to maintain the internal data.��However
>> structures can't maintain an explicit order, something Arrays do by
>> design.
>>
>It can often be hard to choose between arrays and structures since
>sometimes you want properties of each one. Thus, it is often necessary
>to create a data structure that has the properties you want instead
>working around a problem in an available data structure.
True. In this case I think that's what I've done (sorta). I want the
properties of a structure (easy random access, sorting, etc) inside the
comoponent, but want it to return ordered data (properties of an array).
>> Sorting arrays of components is a pain.��ArraySort() won't work on
>> arrays of complex objects so you're left with doing some sort of
bubble
>> sort, going back out to the database, or using some sort of proxy
>> (creating, for example, a query using Query of Queries).��All of
these
>> are inelegant solutions in my opinion.
>>
>Implementing a well known sorting algorithm shouldn't be that difficult
>since all the popular ones are well documented and have examples
>available in many different programming languages. Bubble sort is
>generally not a very good one. Generally speaking, quick sort is
>usually the best choice.
"Bubble Sort" wasn't actually what I did - it's just the first example
that came to mind. If I had had to really do it then I probably would
not have used bubble sorting anyway - although in some of my cases it
may have actually been quite effective (small amounts of nearly sorted
data).
QuickSort is definitely a better choice generally however. I've never
needed it in CF (yet) but I have used it in _javascript_.
In any case implementing an algorithm may be simple - but leveraging the
core sorting capabilities of the language seems a better choice to me -
at least for simple sorts.
More complex sorts may require custom coding... but that's what makes
them "complex". ;^)
>> As always I'd love to hear opinions on this from those that know more
>> than I do (which includes... well, pretty much everybody).��Are there
>> actually good reasons to use arrays rather than structs?
>>
>IMHO, since all you want is to maintain key/value pairs in order, what
>you need is a Map that keeps its entries in order. The JDK provides two
>classes that do this, LinkedHashMap and TreeMap. Additionally, Apache
>Jakarta Commons has a number of other Map implementations that keep
>their entries in order. If you'd like an example of using one of these
>classes let me know.
>
>Of course, you may want nothing to do with Java and would rather handle
>the problem in CFML. If so, I would suggest creating your own ordered
>Map as a CFC. To do that you would create both an array and a structure
>to hold your data. The CFC would manage keeping the two in sync, which
>shouldn't be hard considering one would likely only hold references to
>the other. Then whenever you need to access your data as an array you
>have an array to access it with. When you need to access your data as a
>structure then you also have a structure to access it with.
At this point it's not so much that I want nothing to do with Java (I
will get there eventually) but that it really doesn't seem like I need
it. The solution I have is working just fine (for this application, of
course - it may break down under different requirements).
Right now I'm creating the array on demand - because I plan to cache
them immediately. However creating the array on construction instead
(and having them updated accordingly with the add() and delete()
methods) would, I think, effectively create the ordered Map you describe
(although not a generically applicable one).
In that case (it seems) I would have several Map components which would
have to be managed. Since I want to return a single set of components
sorted several different ways I think that what I have works best for
this.
Of course that's not to say I won't hit a roadblock at some point and
need to backpeddle. ;^)
Jim Davis
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
