where I used the <div> with the backgroud color just to see how large the <object> was, and the file external.html just contained the text
<p>External HTML element</p>
This did indeed make the text appear in the place of the <object> element. (But initially with quite a lot blue space below it, which I could cut away by explicitly limiting the height of the <object>.
I wonder if this could be used for the constant part of the menu definition, or whether it would be harmful for the functioning of menus that there is an extra level of organization between the main menu bar and the sub-menus. Most likely it would work if you packed the entire <NAV> section in an <object>, but then I don't know how you would get the user-specific sub-menu.
But perhaps the 'HTML' that you include through the <object> can in reality be a server-side script. The browser would not know that, request the URL once, and cache what the script sent it, and then keep using that from its cache, rather than requesting it for other pages. If the script to provide a menu bar would need CGI arguments, e.g. for indicating which user (if any) it should customize the menu for, the browser caching will be smart enough not to confuse data loaded from the same script with different arguments. (I.e. it caches data based on the entire URL, also the part behind the '?'.)
If the user is automatically logged out, the main script for displaying the page would know that it has to generate a 'Login' sub-menu rather than a user-customized sub-menu, and it could generate a link to the menu-providing script in the <object> element with an argument that would specify the user is not logged in, and the menu bar would then be generated by the other script accordingly.
I haven't tested this, but it sounds like it could work. Once a user has cached both the menu bar customized for him, and the login menu bar, he would not have to access the menu-providing script anymore, no matter how many pages he loads. Unless he did something that would change his customized menu. But presumably that would change the argument in the URL to the menu-providing script (which could contain a kind of checksum on the contents of the customized sub-menu in addition to the user name in its arguments part).
I read somewhere that with a HTML <object> element you can (amongst other) include HTML from another file. E.g. I tried
<div style="background:blue"><object type="text/html" data="external.html" height="30"></object></div>
where I used the <div> with the backgroud color just to see how large the <object> was, and the file external.html just contained the text
<p>External HTML element</p>
This did indeed make the text appear in the place of the <object> element. (But initially with quite a lot blue space below it, which I could cut away by explicitly limiting the height of the <object>.
I wonder if this could be used for the constant part of the menu definition, or whether it would be harmful for the functioning of menus that there is an extra level of organization between the main menu bar and the sub-menus. Most likely it would work if you packed the entire <NAV> section in an <object>, but then I don't know how you would get the user-specific sub-menu.
But perhaps the 'HTML' that you include through the <object> can in reality be a server-side script. The browser would not know that, request the URL once, and cache what the script sent it, and then keep using that from its cache, rather than requesting it for other pages. If the script to provide a menu bar would need CGI arguments, e.g. for indicating which user (if any) it should customize the menu for, the browser caching will be smart enough not to confuse data loaded from the same script with different arguments. (I.e. it caches data based on the entire URL, also the part behind the '?'.)
If the user is automatically logged out, the main script for displaying the page would know that it has to generate a 'Login' sub-menu rather than a user-customized sub-menu, and it could generate a link to the menu-providing script in the <object> element with an argument that would specify the user is not logged in, and the menu bar would then be generated by the other script accordingly.
I haven't tested this, but it sounds like it could work. Once a user has cached both the menu bar customized for him, and the login menu bar, he would not have to access the menu-providing script anymore, no matter how many pages he loads. Unless he did something that would change his customized menu. But presumably that would change the argument in the URL to the menu-providing script (which could contain a kind of checksum on the contents of the customized sub-menu in addition to the user name in its arguments part).