Brent Eades wrote:
> I'm working on an intranet project which uses large amounts of
> Javascript. At present I have things structured such that each
> of the several hundred pages on the site has an identical head
> section, which loads seven different external scripts. These
> control drop-down menus, user-customization options and so on.
>
> This is all working fine, but my client is of the opinion that
> it would be preferable to generate each page on-the-fly using
> SSI; i.e., the head would be a separate file that would be
> called with an !--#include. His main objective is to make the
> body of each page easier to maintain, which I suppose it
> would. But it's my (quite possibly faulty) belief that
> overall this would slow down the site's operation, what with
> the constant requests to the server engendered by the SSIs.
What's the difference between calling them from external scripts, or
calling them SSI? In both cases, it would seem to me, one copy of the
script is maintained, and it's "pasted" into the page on the fly.
> My contention is that Netscape 4.x (the browser used by the
> department in question) by default caches JC scripts called
> externally, meaning that they will only have to be requested
> once from the server, and then each page of the site will be
> loaded as needed. Whereas with SSI there would be at least two
> requests for every page, one for the body and the other for
> the included header. Or am I off-base here?
Not sure about the caching. SSI doesn't have to make multiple server
calls, though--as far as the time consumed, it's about the same as
calling an external image. Exact same process as including an <IMG>
tag, essentially, except that the SSI is completed inserted before the
page is sent, and the image gets the benefit of of getting handed off
for loading.
> As it is the head on each page only runs to about 25 lines of
> code, since the various scripts are separate entities called
> externally... it's my view that it's better to leave each page
> a self-contained entity, and dispense with the SSI stuff.
>
> Opinions?
I recently converted a javascript heavy site to SSI, and found numerous
blessings. First, it got the JS far, far away from the client's sloppy
editing. Compacted the "guts" of the page substantially. Because menu
bars, keywords and footers where already SSI's, it got the JS stuff in
sync with the management of the other content.
I think the slight benefit over the external javascripts is that a
slight amount of work is transferred to the server, which is faster than
the client's browser. The SSI "pastes" the script right into the page.
This extends the page, but "loads" the script (and images through it)
with the page. The external reference requires the browser to "use"
something from memory, which means the client has to be loading the page
and finding the parts it's supposed to use. The trade-off is probably
neglible--one produces a longer page, one produces fractionally heavier
client workload.
Heavy techies might know some more specific reasons to do one over the
other . . . but my guess is that in the end the difference is neglible,
and outside the benefit of being comfortable with my SSI architectures,
there wasn't a whole lot else gained . . . if you're more comfortable
with the management approach of your own, you might gain nothing.
Brett
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
