Copybook code vs DLL - in the Frame philisophical analogy sense

[Richard Maher]

Hi,

Now that I am aware that JS on a page in Frame A can directly call a
function on a page in Frame B, I no longer have to continue with my
frameB.location.reload() fudge in order to get some code to run in B's
context. This is fantastic news, and I'm having a ball!

But before running off with all my convert's zeal and converting all my
<script src="common.js"> copy-books to direct parent.frame.function() calls
I'd like to pause for a moment as ask everyone if you think it makes sense?
If I was on the mainframe there would be no question and I'd go for the
Shareable-Image/DLL 99.8% of the time; everyone sees the same copy in memory
and they pick up any new version the next time they run. But does it make
that much difference, here in JS linkerless interpreter-land, that each page
has its own local copy of function(s) and data?

To pose the question another way, If a given function is stateless
(non-variant is the closest SQL expression that comes to mind) is there any
point in FrameB calling a parent.frameA.function1 rather than having it's
own copy of function 1? Now if function1 was stateful and maybe keeping a
counter of all calls from all frames, then clearly there are logic reasons
why this keeper of the Global knowledge should have only one instance, but
if it just takes some parameters and returns a result (or affects the
screen) then who cares?

Few more bytes of memory? Extract another.JS file to upload? (but what about
the first time being cached?) Neatness? Goodness?

Question 2:

Speaking of uploading, If I have three frames each with their own page, is
there a predicable ONLOAD sequence of the frame/page loads? (I take it http
can multithread this if it chooses? but not the script execution) I know
that trying to access an Applet method looks like a bit of a synch point,
but a lot of what I want to do/reference in Frame B's load function is not
available 'cos frame A hasn't constructed all it's objects yet. If ONLOAD
happens too early for me, can I have a init() function in each frame and
then call it from the onload() event in the driving/mainline Frame? But then
there's that timing race condition again, or is there?

I just don't want to have to re-initialize a whole lot of variables
needlessley every time a frame becomes visible/active.

Thanks for any help.

Cheers Richard Maher

 

[Marc]

Hi,

Now that I am aware that JS on a page in Frame A can directly call a
function on a page in Frame B, I no longer have to continue with my
frameB.location.reload() fudge in order to get some code to run in B's
context. This is fantastic news, and I'm having a ball!

But before running off with all my convert's zeal and converting all my
<script src="common.js"> copy-books to direct parent.frame.function()
calls
I'd like to pause for a moment as ask everyone if you think it makes
sense?
If I was on the mainframe there would be no question and I'd go for the
Shareable-Image/DLL 99.8% of the time; everyone sees the same copy in
memory
and they pick up any new version the next time they run. But does it make
that much difference, here in JS linkerless interpreter-land, that each
page
has its own local copy of function(s) and data?

To pose the question another way, If a given function is stateless
(non-variant is the closest SQL expression that comes to mind) is there
any
point in FrameB calling a parent.frameA.function1 rather than having it's
own copy of function 1? Now if function1 was stateful and maybe keeping a
counter of all calls from all frames, then clearly there are logic reasons
why this keeper of the Global knowledge should have only one instance, but
if it just takes some parameters and returns a result (or affects the
screen) then who cares?

Few more bytes of memory? Extract another.JS file to upload? (but what
about
the first time being cached?) Neatness? Goodness?

Question 2:

Speaking of uploading, If I have three frames each with their own page, is
there a predicable ONLOAD sequence of the frame/page loads? (I take it
http
can multithread this if it chooses? but not the script execution) I know
that trying to access an Applet method looks like a bit of a synch point,
but a lot of what I want to do/reference in Frame B's load function is not
available 'cos frame A hasn't constructed all it's objects yet. If ONLOAD
happens too early for me, can I have a init() function in each frame and
then call it from the onload() event in the driving/mainline Frame? But
then
there's that timing race condition again, or is there?

I just don't want to have to re-initialize a whole lot of variables
needlessley every time a frame becomes visible/active.

Thanks for any help.

Cheers Richard Maher

Hi Richard,

Just my two cents:

Keep on reading about Javascript, eventually you'll find that using frames
can be a bit of a pain to handle...
Instead, think of getting rid of the frames and start learning
xmlhttprequest. (or the so popular term ajax)

Q1
Do not duplicate functions as this can be more trouble worth it, store all
functions in one js file and load it in the parent frame.

Q2
There's no predictable load. Perhaps having a timer in the main frame
checking out if a certain variable is available in it's child frames is a
way to go (and indeed using the child frame onload).

Consider the following, someone is using your application, filling out all
sorts of stuff, calculations are being made and stored in variables... but
then, oh horror... he/she presses F5, everything reloads... and the 'fun'
starts all over again...

Hope this sort of helps...

 

[Richard Maher]

Hi Marc,

Thanks for the reply

Just my two cents:

Keep on reading about JavaScript, eventually you'll find that using frames
can be a bit of a pain to handle...

You seem confident; all of my experience to date (admittedly somewhere shy
of oodles has been to the complete contrary! Frames, at least to me, are
an incredibly useful addition to the Web Client armoury, and provide a level
of JavaScript code demarcation, or segmentation, and modularity that I find
difficult to conceive of elsewhere.

Instead, think of getting rid of the frames and start learning
xmlhttprequest. (or the so popular term ajax)

Marc, before I launch into a rant, can you please point out why you think
that I should deploy the cheese to solve my problem rather than the chalk?
Or why a deployment of xmlhttprequest has to be to the mutual exclusion of
Frames and vice versa? What is it, functionality wise, that you imagine that
I'm doing with Frames that can be solved with one wave of Ajax? (I certainly
do not "Submit" anything!)

<rant>

But In all honesty I would rather stick my head in a boiling chip-pan than
attempt to shoe-horn an ill-conceived, context-devoid, and feature-starved,
pile-of-pooh (such as http) into the role of Application Middleware
Protocol! Cookies? Session IDs? Caching of Passwords? Domain-wide
contextless client Authorization? All frightening stuff!

Just my 2c

Q1
Do not duplicate functions as this can be more trouble worth it, store all
functions in one js file and load it in the parent frame.

Emotionally, I'm on the same hymn-sheet as you with this but do we have any
tangibles to go on? In my particular case I was thinking of my Socket read
routines (Where all context its maintained in the Applet object anyway). I
can see the Applet and all its methods from any Frame so is there any
overhead or other pros/cons of having a local copy of a function that says
inBytes = chan.readMessage(howMany) or call a single common routine
inBytes=parent.mainFrame.getData(howMany)?

If I went the first way, I suppose I'd really have to say
parent.mainFrame.chan.readMessage(inBytes) other wise I'd have to initialize
"chan" somewhere locally with a getElementById("applet") or chan =
parent.mainFrame.chan and it's that desire for one-off initialization that
led to question 2.

I think I'll take your advice on this one. Thanks.

Q2
There's no predictable load. Perhaps having a timer in the main frame
checking out if a certain variable is available in it's child frames is a
way to go (and indeed using the child frame onload).

That's interesting. OK, I'm walking away with I have to re-initialize my
variables each time before the previous Frame hands-over (by calling
frameB.getReady()) or I simply have to use global variables that were
initialized in the manFrame. I can live with that.

Consider the following, someone is using your application, filling out all
sorts of stuff, calculations are being made and stored in variables... but
then, oh horror... he/she presses F5, everything reloads... and the 'fun'
starts all over again...

Ok, let's consider it; no, let's discuss what actually happens. After
pressing refresh my Applet's destroy() method gets invoked and I close the
socket connection to the server. Client/Server affinity is managed at that
end and if a request was currently being actioned by a server process then
that process is sent an Asynchronous System Trap (AST) telling it that the
connection is dead, and any future attempts to send data back to the client
will be met with a t3$_chanclose status. (This is similar functionality to
the hot-abort key that I spoke of earlier. If the user is sick of waiting
they hit the cancel button and an OOB is sent (if possible) to the server. I
use the setSoTimeout() method, for "long" queries so that an erstwhile
blocking read can surrender the thread for other event (such as the cancel
button) processing. Otherwise the "cancel" occurs between reads. <--
Context-Rich protocol!)

The browser then reloads the original page(s) and my Applet's init() method
gets called, and I, once again, send up a modal dialogue box asking the user
to logon an re-authorize. (Username/Password)

I certainly like it! (But maybe that's just me

Thanks again.

Cheers Richard Maher

PS. If they don't want to logon again then simply don't hit refresh. Or
don't close the browser, or don't turn off the PC, or. . .

 

[Richard Maher]

Hi Again,

Can you also confirm that confirm that *each* frame has to have its *own*
copy of all prototype definitions in use? For example, my testing has shown
that there is no global inheritance of the new "trim" method on the String
object if I include "String.prototype.trim =" only in the mainFrame or
<framset> page. Are my observations correct?

So I still need copy-books if I'm going to have just one set of code to
maintain, and include in pages as necessary? If it's good enough (or a
requirement) for prototypes then why not (1)functions?

Cheers Richard Maher

(1) Once again functions that are not statefull or are designed to effect
the page they are being hosted by.

 

[Richard Maher]

Hi -Lost,

Thanks for the reply.

I am not even sure what a "copybook" is, :

A "header file" maybe? A single disk resident section of source code that is
physically merged with outher source at (pre)compile time?

but, you may want to take a look at the jQuery
plugin mentioned by Yansky in this thread

Ok, I'll have a look.

Cheers Richard Maher

 

[-Lost]

Hi Again,

Can you also confirm that confirm that *each* frame has to have its *own*
copy of all prototype definitions in use? For example, my testing has shown
that there is no global inheritance of the new "trim" method on the String
object if I include "String.prototype.trim =" only in the mainFrame or
<framset> page. Are my observations correct?

So I still need copy-books if I'm going to have just one set of code to
maintain, and include in pages as necessary? If it's good enough (or a
requirement) for prototypes then why not (1)functions?

I am not even sure what a "copybook" is, but, you may want to take a look at the jQuery
plugin mentioned by Yansky in this thread:

http://groups.google.com/group/comp...625aaf81f94/2bd1011a7488eef0#2bd1011a7488eef0

Perhaps you could review the code and find out how it gives itself the ability to be
present in any or all frames at once.

Not sure if it will help though... I just thought it sounded very similar.

-Lost

 

[Richard Maher]

Hi Again,
similar.

Certainly a good tip! And definitely the sort of functionality I'm after,
but you couldn't just give us the Reader's Digest version could ya? Look, I
now it sounds lazy (and I am a lot of the time but I've honestly got so
much new crap whirling around in my head that I'd really struggle to have
the cycles to decern how much is JQuery infrastructure and how much is
vanilla JavaScript. "Tough shit!" you might say (and you'd be right) but if
you/someone could just say soemthing like: -

1) He just uses an interval to recheck every Nmsecs for DOM in the subFrame

2) He appends a child node for the function into the Fame's DOM tree at
branch Id number 12 Attribute A

3) He uses eval() and just has a function in each page called x() that
executes a variable

Maybe JQuery is the future and I'm sure John Wilson's code is more than
worthy of greater respect than spending only 10mins looking at it, but I'd
very much like the run 'o the mill, missionary position, javascript ideology
behind it if at all possible?

The other of my requirements/questions is different, in that I don't need
any dynamic run-time discovery functionality at all, as I know what pages
I'll be displaying in what Frames and I know which ones call which
functions. It's just if more than one page calls the same function do I a)
duplicate the function in each page or b) call page A's function from page B
(Doesn't have to execute in the other Frame at all)

Is John Resig's book on Ready function concepts online? (Does it have
pictures

Is this functionality more about a generic way to establish JQuery (or
a.n.other scripting infrastructure environment) dynamically in new
run-time-discoverable-only (I)frames and pages? Does nobody code vanilla
javascript anymore but instead employ JQuery or Google's or Yahoo's
toolkits?

Once again, apologies for my ignorance and for rambling!

And yes; I *do* just want to roll-up like some johnny-come-lately, put in
very little effort, and expect to pick the brains and hard work of those who
have gone before! What of it

Cheers Richard Maher