This content has been marked as final. Show 11 replies
Make the query a session variable.
actually cacheing query seems a lot less intensive (which i did) but was just asking why an iframe cannot find an array in "top" page....
If you are running the query in the parent page and refreshing the content of the iframe, caching the query achieves nothing.
To access variables in the parent page scope the variable with parent. At least I think that's how you do it, I always use session variables because it is so much simpler.
- There is no "parent" scope.
- Think of an iframe as any other page that is in the same session.
- Only to the client is the iframe a sub of the parent. ColdFusion knows nothing about this relationship.
- If this data is consistent across the entire application then I recommend caching the entire query or saving it to application scope. You can access the necessary info with array notation when needed #picQuery[rowNumber]["columnName"]# (preceed with "application." if in that scope), or if you need to grab a row from the query based on something other than the rowNumber use a query of a query (dbtype="query").
- If this is user specific data and accessed often by each users then you can throw it into session scope. If this isn't going to be hit often per user then it's not worth worrying much about.
Let me know if you have any questions.
Just to clarify so there is no confusion.
The main page will output the iframe tag with the src attribute pointing to another cfm page.
The CF page called in the iframe will make db call with the cache attributes and do query of queries as necessary.
The setting of the data in application or session can occur anywhere and then you'll need to scope the variable names when accessing them in the cfm page appearing with-in the iframe.
FYI. Each time a query's sql changes, usually with-in the where clause, that is a different cached query. ColdFusion servers have a limit on the number of cached queries, set in the CF Administrator with I believe less than 10 by default. You should reduce the number of cached queries, so they don't just overwrite each other, by grabbing a lot of data in a query that is to be cached instead of grabbing individual rows.
first, thanks all the responses...
the home page contains iframe and not only a pic but descriptive text is displayed in iframe file... site owner can change/add to list of pics/text that display via backend tools.
i have cached query on iframe page which creates array. then just pull data from array with loopcount selecting row. the pics/text loops (refreshes page) thru list 3 times, then stops on first pic/text.
array is rebuilt each refresh (query cached) but seems to work very fast... 10ms
home page is only page that uses this action but same all visitors so don't know if app scope would lighten server load...?
I sounds like a cached query is the way to go since items could be added and removed often. If the data is in the application scope you'll need to write code to check if it needs to be reloaded so might defeat the purpose a bit.
tnx again.... seems except for query which is always the same (barring owner additions) and is cached (probably will set for days with owner tools refresh), everything else must be recreated by visits - the array, etc.
as this seems to happen very fast and puts little stress on server, dont see advantage of js. also as visitors may be govt with very high security settings or industrial types running dated software, get a little nervous with js.
You mentionned the array... a quick FYI, if you are just using the array as a way to pick out individual records then you can use array notation to access query object records directly: queryName[rowNumber]["columnName"]
Anyways, good luck with everything.