Imagine 3 select menus: one listing Locations, another listing Systems (deployed at a location), and a third listing Components (that make up a system).
The interface would work such that by choosing a location, that location's systems would be displayed, and by choosing a system it's component's would be displayed. I have done this type of interface before with small data sets by dynamically creating Javascript that preloads arrays, but in the interface in question the Component's table will have thousands of rows so using the javascript technique would result in a very large script download.
If I am reading this right you could always treat this as multiple pages(unless you wanted one huge list). You could show 50, 100 or 200 components at a time, with the navigation for "previous page 1-50 51-100 101-150 next page" etc. This would make your query of the data faster to load. With so many components per system per location it would almost be easier to make a simple little search engine that took in direct queries for sets of data on the server side. From each set allow the user to select a specific component.
Zach,
I probably didn't explain my intent clearly. For the situation you responded too, I will be dynamically building a form. The idea is to present a series of select menus so that when the user chooses a parent item it's child menu is populated with valid choices and so on, and so on. In the application in question we will have a number of interfaces that would behave this way. Some forms would have up to 4 or 5 menus forming a parent-child hierarchy . If you want to look at some rough documentation that shows what I'm talking about goto <http://www.twppo-dev3.lanl.gov/external/pages/usr/perkins/ARM_OADB/Mockups/>. Keep in mind this is internal documentation that is directed at my customer, but the form mockups should give you an idea of what the interface will look like.
FWIW, a system may have anywhere from 1 to a few dozen components. However there are in excess of two hundred tracked systems deployed at over 3 dozen sites. My point about the thousands of components was that I could preload a bunch of JS arrays to dynamically generate the select menus client-side, but this would require repeatedly downloading a potentially huge dynamically generated script.
I see possible solutions to either of these scenarios involving response to a "form event" that would trigger a query back to the database that would return some information that would be parsed and used to populate a specific select menu or form input field. I would also like to do this without having to request and render an entire page. I seem to recall discussions on this or other lists that hinted this could be achieved using Javascript and a small frame (invisible?) that is used as a "broker" to send and receive query results?
You could use the <IFRAME> tag anywhere in your web page like:
<---HTML CONTENT--> <---MORE HTML CONTENT-->
and you could use javascript to perform the form submissions and data requests into the iframe, then pull them into the parent frame as needed.
Thanks for this info. In playing around with some ideas today I'd realized that what you describe is the general strategy I need to follow. What I'm not clear on is how to "pull them into the parent frame as needed". Also isn't "IFRAME" an IE specific tag? I will need this to work on various browsers. As an alternative, I'd assume I would use a very small frame or have a frame that is forecolor on bgcolor frame with really small text.
Thanks,
Brad
