On 2005-04-21 (16:25) Bob Hanson wrote:
>>
>>1. add an id param to your applet tag:
>>
>>id="jmol"
>>
>>send scripts via getElementById:
>>
>>document.getElementById('jmol').script()
>
>Remind what breaks down when. Using getElementById() fails in some
>Mac browsers as noted previously. But I gather that by doing this
>you have it running on your machine. I note that jmol.js uses
>document.applets.targetname or, if that doesn't work,
>document.targetname. So I'm curious as to why getElementById() would
>be necessary.
>
I don't have time to look this up right now, but I believe it has to do with
the complexity of the DOM. getElementById doesn't seem to have any trouble
finding elements, no matter the complexity of the page. I think the other
method is more error-prone, especially when things are being written to the
page via javascript. but this is anecdotal evidence only! I have to go
research whether or not it makes any sense.
apart from OS 10.3.8, are there other systems that do not 'allow'
getElementById? this is an accepted method for accessing page elements via
javascript, not a hack or anything, so I usually don't see a problem with using
it. and 10.3.8 has other, unrelated issues with the JVM - how certain are you
that getElementById is the culprit?
>>I see that you are essentially writing your entire page using
>>javascript. this has many disadvantages, including being very
>>difficult to debug, forcing the client machine to do all of the
>>parsing, and making it somewhat dicey to call document objects via
>>javascript (at least on some systems). also, a user can completely
>>shut down the page simply by disabling javascript.
>
>I figure if the user is going to disable JavaScript they are out of
>luck with ANYTHING I would be writing. All my material is heavily
>JavaScript dependent. I guess I'm not interested in coding for that
>crowd. Is that too harsh?
>
<shrug> personal preference, I suppose. I like to show users *something* of
the page, so they can judge whether or not they want to take the necessary
steps to view it in its entirety.
>>
>>if you are open to suggestions... switch to php or cgi for your html
>>generation. both are dynamic, and both allow you to modularize your
>>code using includes, which seems to me to be what you are trying to
>>accomplish now with js. also, you can get rid of a lot of painful
>>headaches concerning client-side vagarities in js implementation. and
>>finally, when you do run into trouble, it is much, much easier to
>>debug. :-)
>
>Can't use serverside processes here, as the St. Olaf server machines
>are not "my" machines, but I appreciate the suggestion.
>
not even php, eh? bummer. oh well; it was worth a shot ;-)
regards,
tim
--
Timothy Driscoll
molvisions - see, grasp, learn.
<http://www.molvisions.com/>
usa:north carolina:raleigh
"Reality is that which, when you stop believing in it, doesn't go away." -
Philip K. Dick
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
