On Tue, December 7, 2004 10:31 am, Derek Broughton said: > If you're going to do something that makes it worthwhile putting the JS in > the > frame, you probably should be using a script file - in which case it is > cached anyway and you get the same savings.
What is caching it? The browser? In that case you can't rely on it. Also, if you use a script file, you lose all notion of state. This I think is a bit of a blurry line between data and code, but I think it's more code. Of course you get into a lot of questions about best practices here... Think of a situation like drop-down menus where you want to grey out inactive items (a UI metaphor that is wrong frankly, but we're not discussing THAT now :) )... How would you handle this? If you go the script file approach, you either have to (a) pass those menu states from page to page, (b) store it on the server, probably in session or (c) have some code that sets the menu states according to the application state on each page. Now, we're not talking about a huge volume of data to store here, so there's not much concern with using session, aside from using session in the first place, and it's not as if the code to set the state is going to be an especially big deal. But, this is information that really only has to do with the UI, information that you really shouldn't have to deal with every page, so why not have this functionality and state information in a hidden frame? I suppose you could have a hidden frame with JUST the state information, and load the actual code to use that information from a script file, but isn't that in a sense breaking encapsulation? I'd rather have it all together. This is all debatable I admit, and I'm not saying the script file idea is bad in any way, just pointing out alternatives that from experience I know work very well. Frank
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
