Thank you, Stephen (and Pau). I see the relevance now to the original
question. Unfortunately, while undoubtedly "the way to go" for normal Web
pages, and an approach that I will definitely keep in mind for future
applications, I'm afraid this approach is not appropriate for our
application. Again, we are dealing with an AS/400 app with approximately
1500 screens. On one page we have a horizontal drop-down menu with eight
main headings, each of which has a dozen or more sub-headings, some of which
have as many as 36 sub-sub-headings (one sub-heading has so many entries it
has to be vertically scrolled on an 1152 X 864 screen). It is this menu
which is being built on the fly, and the tool doing the building is a
third-party tool which we have licensed (and which, therefore, we do not
control).
Basically, when a page is requested, the AS/400 WebOptions runtime takes the
HTML generated by the Markup Language Skeleton, looks through it for field
and variable replacement markers, looks up the appropriate values to insert,
and inserts them into the (60kb limit--boo!) stream as the HTML is being
delivered. Meantime, the menu generation script is determining the
appropriate menu elements for that page and building the menu (which is in a
separate iFrame with its own source).
The process of adding and dropping event listeners described in the article
is undoubtedly sound, portable, standards-compliant, etc. All good stuff, no
doubt. However, in our case it would add a level of complexity to the app an
order of magnitude greater, or more, than what we have now (which, believe
me, is quite complex enough). Furthermore, the processing time required to
hang all those event listeners would make our response times unacceptable,
even assuming that we pinkware types could figure out where in the process
to intercept the necessary information and precisely how to structure the
event listeners to make them work as in the existing mechanism.
See, here's the basic problem: The Web version does not *replace* the 5250
green screen app. We anticipate many years before all of our global users
have moved from terminal-based access to Web access of the app. Therefore,
while we are building the Web app, we can do *no* modifications to the basic
AS/400 application or to its data stream. It must continue to function
precisely as it always has for terminal users, even after the Web version
goes live, and is in fact "live" for 5250 sessions even as we build the Web
version. Our job is to try to pick out of the data stream the information
that we need to build usable Web pages. This complicates the matter
considerably, as you can probably imagine.
It is a good article, and I really do see the benefits of the approach, but
I'm afraid it's just not something that's going work in our, admittedly
peculiar, situation. Thanks for the reply.
Cheers,
Scott
----- Original Message -----
From: "Stephen Caudill" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 25, 2004 11:27 AM
Subject: [wdvltalk] RE: Abbreviation for "javascript" (??)
What the article (which /is/ very good) is implying is that you should
be using event listenters rather than making a call to the javascript
protocol in the href attribute. In your instance, something like:
(given the following html)
<a href="/path/to/myfile.html" id="widget">contextual link</a>
<!--
if there is no file you're linking to, don't use an anchor... if this
is just to call a javascript function, it would be more appropriate to
attach an event to an image or some such...
-->
here's the appropriate JS (regardless of what element you choose, so
long as it has the id):
<script type='text/javascript'>
var oWidg = document.getElementById('widget');
oWidg.addEventListener("click",foo,false);
function foo(){
// do something
}
</script>
Now, by extension, the idea should be that if you encapsulate and
modularize the code in such a fashion, you should be able to automate
the attachment of these behaviors... perhaps you actually target an
element that is parent to a group of elements that need the behavior,
then loop through it's children attaching these behaviors... that
would definitely eliminate the necessity for writing lots of inline
calls to the JavaScript protocol... not to mention making the document
degrade gracefully in browsers that can't handle the JS.
- Stephen
On Wed, 25 Aug 2004 10:26:07 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hmm, very good article, and I've bookmarked it, but after reading all five
> sections I didn't see anything germane to the question of a replacement
for
> the javascript token in an href function call. Did I miss something? What
> section was it in?
>
> Cheers,
> Scott
>
> ----- Original Message -----
> From: "Pau Garcia i Quiles" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 24, 2004 6:42 PM
> Subject: [wdvltalk] RE: Abbreviation for "javascript" (??)
>
> Maybe this (http://www.sitepoint.com/article/behaved-dhtml-case-study) can
> help.
>
> >-- Original Message --
> >Reply-To: [EMAIL PROTECTED]
> >From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: [wdvltalk] Abbreviation for "javascript" (??)
> >Date: Tue, 24 Aug 2004 15:22:57 -0400
> >
> >
> >Don't know if such a beastie exists, but my boss just asked me about it,
> >so
> >I thought I'd see if anyone here had heard of one. In constructions such
> >as
> >this, <a href="javascript:foo(bar);", is there any shorter token that the
> >parser will recognize than "javascript" to indicate the function call?
> l
> >have not personally ever seen or heard of one, but then, I haven't seen
> or
> >heard of a lot of things that exist nonetheless.
> >
> >So, anyone know if there is an abbreviated token to use for "javascript"
> >in
> >these HREF calls? Almost as good would be a definitive answer that there
> >is
> >not, so I could pass that along. BTW, the reason for this is that we have
> >a
> >menu with some thousand items (not, of course, at the same level) and our
> >wonderful AS/400-based gen tool has a 60kb limit to its stream, which
means
> >we're getting partially loaded pages and blown up scripts, which we could
> >avoid by eliminating (or shortening) all those repetitious "javascript"
> >tokens.
> >
> >Cheers,
> >Scott
> >
> >
> >____ ? The WDVL Discussion List from WDVL.COM ? ____
> >To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED]
>
> > Send Your Posts To: [EMAIL PROTECTED]
> >To set a personal password send an email to [EMAIL PROTECTED] with the
> >words: "set WDVLTALK pw=yourpassword" in the body of the email.
> >To change subscription settings to the wdvltalk digest version:
> > http://wdvl.internet.com/WDVL/Forum/#sub
> >
> >________________ http://www.wdvl.com _______________________
> >
> >You are currently subscribed to wdvltalk as: [EMAIL PROTECTED]
> >To unsubscribe send a blank email to %%email.unsub%%
> >
> >To unsubscribe via postal mail, please contact us at:
> >Jupitermedia Corp.
> >Attn: Discussion List Management
> >475 Park Avenue South
> >New York, NY 10016
> >
> >Please include the email address which you have been contacted with.
> >
>
> --
> Pau Garcia i Quiles
> MSN Messenger: [EMAIL PROTECTED]
> http://www.elpauer.org
>
> ____ . The WDVL Discussion List from WDVL.COM . ____
>
>
> To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED]
> Send Your Posts To: [EMAIL PROTECTED]
> To set a personal password send an email to [EMAIL PROTECTED] with the
> words: "set WDVLTALK pw=yourpassword" in the body of the email.
> To change subscription settings to the wdvltalk digest version:
> http://wdvl.internet.com/WDVL/Forum/#sub
>
> ________________ http://www.wdvl.com _______________________
>
> You are currently subscribed to wdvltalk as: [EMAIL PROTECTED]
> To unsubscribe send a blank email to %%email.unsub%%
>
> To unsubscribe via postal mail, please contact us at:
> Jupitermedia Corp.
> Attn: Discussion List Management
> 475 Park Avenue South
> New York, NY 10016
>
> Please include the email address which you have been contacted with.
>
> ____ . The WDVL Discussion List from WDVL.COM . ____
> To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED]
> Send Your Posts To: [EMAIL PROTECTED]
> To set a personal password send an email to [EMAIL PROTECTED] with the
words: "set WDVLTALK pw=yourpassword" in the body of the email.
> To change subscription settings to the wdvltalk digest version:
> http://wdvl.internet.com/WDVL/Forum/#sub
>
> ________________ http://www.wdvl.com _______________________
>
> You are currently subscribed to wdvltalk as: [EMAIL PROTECTED]
> To unsubscribe send a blank email to
%%email.unsub%%
>
> To unsubscribe via postal mail, please contact us at:
> Jupitermedia Corp.
> Attn: Discussion List Management
> 475 Park Avenue South
> New York, NY 10016
>
> Please include the email address which you have been contacted with.
>
>
____ . The WDVL Discussion List from WDVL.COM . ____
To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED]
Send Your Posts To: [EMAIL PROTECTED]
To set a personal password send an email to [EMAIL PROTECTED] with the
words: "set WDVLTALK pw=yourpassword" in the body of the email.
To change subscription settings to the wdvltalk digest version:
http://wdvl.internet.com/WDVL/Forum/#sub
________________ http://www.wdvl.com _______________________
You are currently subscribed to wdvltalk as: [EMAIL PROTECTED]
To unsubscribe send a blank email to %%email.unsub%%
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016
Please include the email address which you have been contacted with.
____ • The WDVL Discussion List from WDVL.COM • ____
To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED]
Send Your Posts To: [EMAIL PROTECTED]
To set a personal password send an email to [EMAIL PROTECTED] with the words: "set
WDVLTALK pw=yourpassword" in the body of the email.
To change subscription settings to the wdvltalk digest version:
http://wdvl.internet.com/WDVL/Forum/#sub
________________ http://www.wdvl.com _______________________
You are currently subscribed to wdvltalk as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016
Please include the email address which you have been contacted with.
