Passing hidden info to JavaScript

[KKramsch]

OK, here's the scenario: I have a CGI script that generates a
page with frames (BTW, I'm not crazy about frames, but in this case
the decision to use them is out of my hands). In a typical session,
the user interacts with two of these frames extensively, and up to
the very end of the session, this interaction is handled entirely
client-side by a fairly elaborate JavaScript script. (This
interaction takes place exclusively via HTML buttons, i.e. no
forms). The JavaScript code is printed out by the CGI script as
part of the frameset's head element. Now, this JavaScript code
requires a sizeable chunk of dynamically-generated data from the
server to do its work. More specifically, this data is a table/matrix
of strings, 3 columns wide and typically about 1000 rows long.
This table/matrix of strings is of no interest to the user, so I
don't want it to be visible.

My question is, what is the best way for the CGI script to pass
the data matrix to the client-side JavaScript?

Many thanks!

-Karl

--
Sent from a spam-bucket account; I check it once in a blue moon. If
you still want to e-mail me, cut out the extension from my address,
and make the obvious substitutions on what's left.

[Richard Cornford]

KKramsch wrote:

OK, here's the scenario: I have a CGI script that generates
a page with frames [...] In a typical session, the user
interacts with two of these frames extensively, and up to
the very end of the session, this interaction is handled entirely
client-side by a fairly elaborate JavaScript script. (This
interaction takes place exclusively via HTML buttons, i.e. no
forms).
I always enjoy these long explanations of how, without a word about why.
They are a great way of attracting many inapplicable, irrelevant or
inadequate responses and avoiding any really useful or informed
assistance.
The JavaScript code is printed out by the CGI script as
part of the frameset's head element.
Does that mean it is *all* genuinely dynamically generated code, or is
it just an effort to avoid being able to take advantage of client-side
caching?
Now, this JavaScript code requires a sizeable
chunk of dynamically-generated data from the server
to do its work. More specifically, this data is a table/matrix
of strings, 3 columns wide and typically about 1000 rows long.
This table/matrix of strings is of no interest to the user,
so I don't want it to be visible.
A javascript data structure will only be visible to the user if they go
looking for it. If you don't want them to find it if they go looking for
it then you should not be sending it to the client at all.
My question is, what is the best way for the CGI script to pass
the data matrix to the client-side JavaScript?

(3000 bytes * the average length of string) + demarcation and
formatting; - is something that you probably don't want to be sending to
the client at all. If you are going to send it anyway (and there
probably are smarter alternatives) then Array and Object literals offer
the least overhead.

Richard.

[KKramsch]

In <ce*******************@news.demon.co.uk> "Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:

KKramsch wrote:

OK, here's the scenario: I have a CGI script that generates
a page with frames [...] In a typical session, the user
interacts with two of these frames extensively, and up to
the very end of the session, this interaction is handled entirely
client-side by a fairly elaborate JavaScript script. (This
interaction takes place exclusively via HTML buttons, i.e. no
forms).

I always enjoy these long explanations of how, without a word about why.
They are a great way of attracting many inapplicable, irrelevant or
inadequate responses and avoiding any really useful or informed
assistance.
I included little on the why because I barely know it myself!
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).
The JavaScript code is printed out by the CGI script as
part of the frameset's head element. Does that mean it is *all* genuinely dynamically generated code, or is
it just an effort to avoid being able to take advantage of client-side
caching?
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. 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.
Now, this JavaScript code requires a sizeable
chunk of dynamically-generated data from the server
to do its work. More specifically, this data is a table/matrix
of strings, 3 columns wide and typically about 1000 rows long.
This table/matrix of strings is of no interest to the user,
so I don't want it to be visible. A javascript data structure will only be visible to the user if they go
looking for it. If you don't want them to find it if they go looking for
it then you should not be sending it to the client at all.
Sorry again, what I meant to write was that I don't want the data
to be part of the stuff the browser displays when one visits the
page; I don't care if the user sees it by inspecting the page's
source. Keeping the data secret is not a concern at all here.
My question is, what is the best way for the CGI script to pass
the data matrix to the client-side JavaScript?

(3000 bytes * the average length of string) + demarcation and
formatting; - is something that you probably don't want to be sending to
the client at all.
I don't know how to avoid this and still keep the interaction
mostly client-side. But I'm definitely open to ideas.
If you are going to send it anyway (and there
probably are smarter alternatives) then Array and Object literals offer
the least overhead.

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).

-Karl

--
Sent from a spam-bucket account; I check it once in a blue moon. If
you still want to e-mail me, cut out the extension from my address,
and make the obvious substitutions on what's left.

[Andrew Thompson]

On Thu, 5 Aug 2004 17:04:06 +0000 (UTC), KKramsch wrote:

If you are going to send it anyway (and there
probably are smarter alternatives) then Array and Object literals offer
the least overhead.

Thanks, that's great. I hadn't even *thought* of sending the
data as part of the JavaScript code!

I feel this bodes very badly..

You are being dumped in at the deep end on
a project at an advanced stage.

The code you inherited is (starting to seem)
like inherently poor code and design, yet
your management wants you to complete this
bad design when you are not well versed
with Javascript.

I think you need to convince management
to get a JS specialist in to review and
redesign (or alternately scrap and completely
rewrite) the code.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

[KKramsch]

In <1d****************************@40tude.net> Andrew Thompson <Se********@www.invalid> writes:

On Thu, 5 Aug 2004 17:04:06 +0000 (UTC), KKramsch wrote:

If you are going to send it anyway (and there
probably are smarter alternatives) then Array and Object literals offer
the least overhead.

Thanks, that's great. I hadn't even *thought* of sending the
data as part of the JavaScript code!

I feel this bodes very badly.. You are being dumped in at the deep end on
a project at an advanced stage. The code you inherited is (starting to seem)
like inherently poor code and design, yet
your management wants you to complete this
bad design when you are not well versed
with Javascript.

This management is notorious for such myopic directives. This
one is benign in comparison to other ones I've witnessed (and/or
labored under). E.g. they are *allergic* to the mere notion of
refactoring.

You say that the code and the design appear to be "inherently
poor". Any specific comments you may have would be a great help.
I'm trying hard to do my best, and the project is 90-95% complete.
As backwards as it may sound, I think this management will be more
receptive to the idea of hiring or contracting a JS expert for the
next version of this application once the current version is out
the door.

-Karl

--
Sent from a spam-bucket account; I check it once in a blue moon. If
you still want to e-mail me, cut out the extension from my address,
and make the obvious substitutions on what's left.

[Andrew Thompson]

On Thu, 5 Aug 2004 20:22:29 +0000 (UTC), KKramsch wrote:

In Andrew Thompson writes:

On Thu, 5 Aug 2004 17:04:06 +0000 (UTC), KKramsch wrote: (R.C.)

If you are going to send it anyway (and there
probably are smarter alternatives) then Array and Object literals offer
the least overhead.

Thanks, that's great. I hadn't even *thought* of sending the
data as part of the JavaScript code!

....The code you inherited is (starting to seem)
like inherently poor code and design,

.... You say that the code and the design appear to be "inherently
poor". Any specific comments you may have would be a great help.

I may have given the wrong impression,
but my reasoning is this.

The transfer of such large amounts of data between
server and client requires careful consideration
about both the upper limit to the transfer, and
the form in which it is delivered.

Both these factors need to be considered in the
initial design of the system, and thereafter, the
choice of technologies used to implement that design.

Is there any indicationin the existing JS (or any
supporting documents) about how the previous JS
programmer was moving the data (or planning to)?

If not, it indicates that necessary design was
never done.

The company may find that in order to 'implement'
the current (lack of) design using the current
code takes longer than to design the system properly
and start fresh. E.G. they might find they are
lumbered with a web-app that is three months
overdue and still buggy as the harried programmer
(read you) is desperately trying to work out
design, data handling and presentation within
the constraints of poorly thought out legacy
scripts written by a person who probably knew
they were leaving the company at least two months
prior to suddenly disappearing out the door.

Sorry I cannot be more specific, that would require
a lot closer inspection of the overall web-app, and
I *may* be presuming some things that turn out to
be incorrect. But I have seen many IT based projects
die when the management would not let go of an
inherently bad 'almost complete' system rather
than admit at an earlier (potentially recoverable)
stage that they made a fundamental error.

(shrugs) You are in the best position to judge,
ultimately.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

[Richard Cornford]

KKramsch wrote:

Richard Cornford wrote: <snip>

I always enjoy these long explanations of how,
without a word about why. ... <snip> 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.

<snip>

Does that mean it is *all* genuinely dynamically generated
code, or is it just an effort to avoid being able to take
advantage of client-side caching?

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.

<snip>

My question is, what is the best way for the CGI script
to pass the data matrix to the client-side JavaScript?

(3000 bytes * the average length of string) + demarcation and
formatting; - is something that you probably don't want to be
sending to the client at all.

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.
If you are going to send it anyway (and there
probably are smarter alternatives) then Array and Object literals
offer the least overhead.

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.