Forum Moderators: mack
Example:
<table><tr><td>
<table>
<tr><td>left header</td><td>right header</td></tr>
</table>
</td></tr><tr><td>
<table>
<tr><td>distinct recordset generated menus</td>
<td>filtered recordset data returned from menu selection</td>(only part that changes)</tr>
</table>
</td><td>
<table>
<tr><td>recordset filtered Ad1</td></tr>
<tr><td>recordset filtered Ad2</td></tr>
<tr><td>recordset filtered Ad3</td></tr>
<table>
</td></tr>
<tr><td>contact info and footer-type stuff</td></tr>
</table>
I like using tables because the look is clean and the behavior works well with my design.
How frequently does that content change? If it isn't very often then one approach would be to create static files from the information in the database, and then update those files when database records change.
I was trying to create something my wife could run. She can do a database and ftp upload, but coding isn't her thing.
Is there a good way with asp to create static files. There are three options each with 10 variables in a given request so I would need a lot of pages.
The page works great but is painfully slow.
Have you done deep experimenting to determine exactly what is slowing you down? It seems to me that even a slow loading frame, iframe, or dynamic content loaded via Ajax (which is one way to do what you're asking) is still a PROBLEM.
A quick way: load up one of the slowest pages you can find. View source, copy to a static file, test.html. Load this static file on your server and measure it's load time.
The point is, it may not be the page itself, but you may have some process that is slow on delivery, not browser rendering. If the above test loads quickly, you're chasing the wrong bug.
One example: it's a common method to print-as-you-process, that is,
one = some_function;
print "one";
two = some_other_function;
print "two";
.... etc. The argument here is you are freeing up memory as you go. My argument against this is each time you print, you have to wait for the gateway to connect to the browser before moving on to the next command. I have had far superior results by printing when I'm done:
one = some_function;
final = one;
two = some_other_function;
final = final + " " + two;
print final;
Another is to examine the various loops in your "filter." Often I see
for each record [db_query_results] {
for each record [what_i_have_stored] {
if [this_record_is_not_in_what_i_have_stored] {
[add_to what_i_have_stored]
}
}
}
The previous (silly?) example basically steps through all records of a result and stores it in an array (list.) But to avoid duplicates, an inner loop checks the array each time a record is read, so the number of loops here is num_records X num_records - an intense amount of processing that can probably be more efficient by reworking the initial select statement to avoid duplicates in the first place.
If it turns out to be the page itself, then I'd review my tables and nesting and take another approach. I had this with select lists once, a hundred or so on a page with each list exceeding 100 items brought the page to it's knees. It didn't work and I had to do something else.