> For example, the user interacts with the visible frame, though if you > (as > the developer) need > to access the the database for whatever reason, you just set the params > of the hidden frame and do a GET request, parsing the response, (with > some > help from Javascript > of course). With the output, perhaps combos could be loaded or anything > else done using Javascript or perhaps the content sent to another > window - > the sky's the > limit really.
I think I'm getting a better idea. The idea is using javascript to allow you to change the contents of a drop down menu, or redraw a table without submitting a form. Is that what you're talking about? Moving more of the display processing to the web browser? If that's what you're talking about, then I don't know of any other ways to accomplish it. You'll still need a hidden frame to send and receive a GET request, and use JavaScript to parse the response and then redraw the displayed page accordingly. You could use Velocity templates to format the data into JavaScript arrays, so that your scripts only have to eval the response. I think there is merit to the idea of moving display processing to the client. It would reduce the bandwidth required for a web page and leverage processing power on the client. But I prefer to avoid it so I don't have to be bothered with the dialect and DOM differences between the various browsers. -Eric -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
