KKramsch said:
I included little on the why because I barely know it myself!
Good client-side scripting (and by extension, web applications that use
client-side scripting) is quite heavily dependent upon good script
design and architecture (more than seems to be commonly appreciated).
Once the design is right the implementation follows from it fairly
simply. But you need to understand the design and not being able to
explain anything about it is not an indicator of understanding.
This is sort of legacy code that I'm working with. The
JavaScript guru in our shop left abruptly for another job,
and I'm stuck with finishing this project, even though my
JavaScript experience is pretty scant. I'm just sticking
to the general architecture used in the rest of the
project (per instructions from above).
There is a feeling (not uncommonly held by programmers (exclusively) of
'proper' languages, and propagated to managers) that javascript is a
"toy" language that any fool can code. It is not, however, a belief held
by anyone who has become familiar with javascript beyond the completely
trivial. Unfortunately, a consequence of that belief is that people with
a minimal knowledge of javascript (and usually less of browser
scripting) get presented with tasks that are realistically beyond them,
and little choice but to struggle on with them regardless. A failure on
the part of the management to recognise the need for an application of
skills that will probably cost them more because of the extra time it
takes the unknowledgeable to produce something that meets the minimum
criteria for "works", and result in code that is objectively bad, with
additional costs following directly form that.
I appreciate that you have no real choice, and want to do the best job
you can of the task you have been assigned (which is admiral), but it
doesn't sound to me like you are ready for this project and trying to
learn on the job you will probably find that there is more to learn than
time available to learn it in.
Sorry, I'm a JavaScript newbie; I don't understand exactly how
your comments follow from mine, but to answer your question, no,
not all of the code is dynamically generated. In fact, most of it
isn't. And no, there's no particular interest in forgoing
client-side caching, though I don't understand how putting the
code in the frameset's head element thwarts client-side caching.
In principle, if a page is dynamically generated with a CGI script then
it doesn't want to be cached (at least beyond a duration that relates to
the frequency at which the contents will change), and would be sending
HTTP headers that discouraged client-side caching. Thus each request for
the resource is likely to result in it being re-fetched from the server.
But everything on the page that does not change dose not necessarily
need to be going back and forth each time. There isn't that much choice
with the HTML parts but a mass of constant javascript functions could be
moved out into a separate JS file and imported by a single script
element on the page. If the headers for that file encourage caching, and
the page is in the client's cache then the browser would not tend to be
re-requesting it from the server and so the page would load quicker with
less bandwidth use and server load.
I think the reason this JavaScript code is in the frameset is
that it must know about what's going on in several frames at
once, so it seems (to me at least) a logical choice to put it
there.
It is logical that the code should be included by, and execute in the
context of, the frameset page, but it doesn't have to all be included on
the HTML page for that to happen. Importing the constant functions using
an external JS allows that code to be cached independently of the
framset page and any dynamic scripted content it might have.
I don't know how to avoid this and still keep the interaction
mostly client-side. But I'm definitely open to ideas.
Unfortunately ideas that go beyond wild and baseless speculation can
only come form an understanding of the whys involved. I don't even know
what this large structure of strings if for, only that you assert the
necessity of its existence.
Thanks, that's great. I hadn't even *thought* of sending the
data as part of the JavaScript code! I was still thinking in
terms of HTML elements (in case any additional proof of my lack
of JavaScript experience were required).
You are welcome, but I tend to agree with Andrew Thompson (and also
suspect that the underlying design might be seriously flawed).
Richard.
