There is nothing "wrong" with have queries in the presentation layer if they store data for the presentation layer.  But I am not saying store the queries in your presentation layer, just pass a "query" instead of an "array".  A query in CF is an object in it's own right and can be created and manipulated compeltely separate of getting it from a database.
 
In comparison between the two methods, the STRUCT will probably be quicker if you have one and only one way of accessing the data (i.e. one key) and you don't need to reorder the data at any time after you first get it.  The QUERY method will allow you to still filter the data if need be as well as reorder the data.  All these are valid PRESENTATION things you may want to do - so a QUERY can be a very useful tool in doing this.
 
Regards,
Gary
 
On 6/25/05, Chad Renando <[EMAIL PROTECTED]> wrote:
The first shall be last, last shall be3 first and all that, so Mike,
you're up...

> I don't understand why you do that "MyArray[75]['red']" instead of "MyArray[75] = 'red'" - maybe it's obvious, but I have never seen
> anything like that before.

It's because of the level of abstraction for my form building thingie.
I have forms in one table, form fields in another.  Some form fields
can be drop-down lists, and some have multiple dependant drop down
lists (Country / City / State type of thing).  I have one template for
the defining of all form fields, and one for the presentation of all
form fields.

As I am defining the form fields, I am looping, and looping, and whoa!
I come across a drop down list.  So if the drop down list is based on
multiple dependent drop down lists, I need to capture what I am going
to call these drop down lists.  So I say MyFormField[FieldID][1] =
MyFieldName1 and MyFormField[FieldID][2] = MyFieldName2.

Now Gary's turn...

>  1. why dont you just... store the query and then re-query the query (we do that)
>  2. why dont you just... create a struct and use the ID as a key in that struct and then
>  store the rest of the data as a struct under that key (we do that too)

1. Because I want to try to avoid defining queries in my presentation
layer.  I may have to give in and do query of queries, but hope not.
Just my own framework.

2. Looks interesting, I will have a play, thanks!

Chad
who was very cold from 5:30am to 7:30am yesterday broken down on the
side of the road

---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/

--- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to