On 2012.08.06. 16:20, Robert Hanson wrote:
On Mon, Aug 6, 2012 at 6:38 AM, Gusts Kaksis <gusts.kak...@gmail.com
<mailto:gusts.kak...@gmail.com>> wrote:
On 2012.08.06. 14 <tel:2012.08.06.%2014>:07, Robert Hanson wrote:
It's the same as why do you need an addButton method then :) If
you're building a helper library to aid development, it's for the
best to add more helpful functions than less. And it's still the
same argument between you and me, weather molecule files should be
linked with an anchor, which in case of Jmol's/JavaScript's or any
other failure would allow the client to download it and view it
in, for example, Avogadro.
That's why we have the WRITE command. But I think you were thinking
that this would be useful specifically if JavaScript is disabled, not
as a way to generally download a file. It's not for me to say remove
it, only to point out its limited usefulness.
In my case, it's the real life scenario - students can (left) click and
view them in Jmol or right-click and save them on their computer, to do
some editing in ISIS.
For example my father is hosting all the molecular data files him
self, so it would be useful for him, to load them as a file from
server, meanwhile allowing his students to download the mol file
and edit it in ISIS/Draw. So I don't see a point why not.
I don't know. That site is reporting that I don't have JavaScript
enabled, which I do. So something is amiss there.
Which browser (version) does report that? Might be cache? I just
opened it up in IE8, Firefox 13, Chrome and it works.
Looks like you got it. It's working now.
Then it might be cache related, because I didn't change anything. IE
really likes to cache stuff and refuses to let go. :)
I get the applet in Firefox, but the Show/Hide MEP button is not
working. (That's just because you are using an older version of
Jmol.)
Yes, I see - if you use Load + MEP it will show MEP and "Show/Hide
MEP" button will hide it, but it will not restore it. There seems
to be a problem either in the version of Jmol (I'm using 12.2.32)
or the script itself (it's in data-script attribute). But I copied
it from your site, so I don't know...
exactly. You need 12.3 for that, now 13.0.RC4
OK, got that. I'll update to 12.3 or 13.0
The trick with IE8 and 9 is that you have to use XDR
(XDomainRequest), which is basically the same as XHR, just,
as usually, the Microsoft way. And with this jQuery plugin
iecors (https://github.com/dkastner/jquery.iecors) it adds
XDR as an AJAX driver (instead of default XHR), so to speak.
Ah, interesting. Good. Still, that requires sites delivering the
proper header.
You mean "Access-Control-Allow-Origin: *"? Yes it does, but it's
the default cross-domain behavior.
No, it's not. You need that or at least XHR does not work. Absolutely
not the default behavior. I just recently requested several sites
implement that, and only after that implementation did the
cross-browsing option work.
But it is. It's called "same origin policy" that most of the browsers
implement. It is to protect clients from malicious javascript code (for
example, posted by other client in an article comment section) to steal
cookies or do key/mouse tracking. See here:
http://en.wikipedia.org/wiki/Same_origin_policy
And this is where CORS come in handy (See here:
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing), it allows
you to do cross domain requests. Although it breaks the previous
security restrictions. I've never understood why does the remote server,
have to say who's allowed to connect, not the current one. As it would
have made more sense, that you say - ok my site will be allowed to
request stuff from this and that other domain, rather than the other
domain says - ok that one can do requests. It just opens up the same
security hole.
Anyway, nevermind that, as long as it works for 80-90% of users - it's
good to go.
<http://en.wikipedia.org/wiki/Same_origin_policy>
Also, how are you handling the caching of script requests
prior to applet initialization?
It's done. You can actually call my jmolscript() prior to any
initialization, but you might need an id attribute set.
Q: What about the destroy method in Jmol applet's interface?
Is it possible to create one? And will it help the situation
with IE, when I want to remove applet from DOM tree without
crashing the browser? I've done server side Java
development, but I've never developed Java browser applet's
so that's kind of an unknown territory for me.
The applet detects when it has been destroyed and clears itself
out, passing a callback to appletReadyCallback with a parameter
false.
I have not experimented with removing the applet from the DOM
tree, but even doing a display:none on it in CSS destroys the
applet in MSIE. Don't do that.
Ahh, OK, well I'll play around that and do my internal cleanup in
onDestroy callback (jQuery-Jmol callback, not Jmol). This thing is
kind of important for performance. For example I'm showing a
placeholder image of some molecule instead of Jmol applet, and I
have some 30-60 molecules on the page.
This is considered bad design. We strongly disrecommend it. A single
applet, a scrollable interface, or something like that is preferred.
Certainly, of course, you can somehow start up a new applet each time.
A possibility is to move the div elegantly from one to the other
without the user being the wiser and just use one applet. Or populate
data in divs on the fly rather than have some long scrolling list of
images/applets.
Of course, I can make it "lightbox" style view - with one Jmol viewer
and a thumbnail strip. Still, it would be a nice way to do some cleanup
on long running sites (like modern webapps), by killing Jmol when it's
not needed any more, without doing a page reload. Or as my previous
example - do some switching.
As for repositioning a div element - it might crash IE, as you remove it
from DOM tree before appending it back - this way destroying Java
instance (but in IE, it seems that it does not kill it completely - same
as display:none). Only option left is to use absolutely positioned Jmol,
that just changes it's position on the page.
But it all seems to hit the wall of IE - the biggest reason for every
web developers headaches.
So I'd like to enable Jmol on click and disable other Jmol
instance that's already visible. I'm afraid of the performance hit
on client side with 60 instances of Jmol. :/
--
Gusts Kaksis
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
