Hi,
I have to pardon my self, I wasn't looking carefully enough at Jmol.js
and JmolCore.js, JmolApplet.js and JmolApi.js, and it looks that I kinda
misjudged the applet initialiation process. Sorry about that :) As you
alerady mentioned in your example "Jmol.setDocument(0);". So there seems
to be no problems with that, my bad. :/
A good challenge for you would be to rewrite
http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htm using
your alternative approach. Allow no JavaScript within the <body>
(right?). Make sure it still works properly on iPad, iPhones, and
Android tablets. The challenge would be to make it as simple as what
you see there.
I say challange accepted, just give me some few weeks, as I have to dig
deeper into ChemDoodle, JME and JSpecView APIs. My main intention was to
create an alternative for Jmol.js only (and kinda stripped down version,
as I said it was intended only for core build-up and communication), but
now I see the possibilities in those new sample pages, where you can
turn Jmol into JME seamlessly, and that kinda intrigues me. I'd be glad
to create a jQuery version for JME too.
jmolButton is simply a higher level interface that allows page
developers to quickly introduce functionality so that they don't have
to mess with "IE way" and "others". We really do not want page
developers messing with that. Three years from now there will be
another way for another random browser. This is asking to have broken
pages that require difficult maintenance. But I think you know that
and must mean that these would be within some other API.
The "IE way" and "others" example was intended to show low level
JavaScript approach, that I saw proper. If I manage to somehow convince
you to start using jQuery, all that pain would go away, because jQuery
smoothly wraps all these different browser event binding problems away
from us.
Well, actually, that won't work. Jmol scripts can be quite
complicated, and some have enough quoting in them that they don't lend
themselves to being expressed as attributes. jmolButton and other
controls allow for a higher level of use that hides all that
complexity. Are you suggesting the page developer writes that tag
themselves? If so, then I think you are just going back to an earlier
stage in our process (about 8 years ago) and not appreciating the
advantage of a JavaScript library such as Jmol.js. If you mean that
some API would write this tag, OK, but I don't see the advantage then
of that over jmolButton.
If we return to my point of separating JS from HTML, I say don't worry
about complicated scripts. HTML was intended (by Sir Tim Berners Lee) as
a markup for data.
So I say there is no problems with writing simple HTML with data
attributes containing some hard core scripts. Maybe, if you have some
really nasty examples, that have strict indenting and line breaks, that
you could show me and I could test them, then, please, show me them.
As for quotes - always escape them. If the site is running with some
kinda CMS, that can be done automatically in WYSIWYG, if the site is
prepared with some authoring tool, like, for example, Dreamweaver, then
it will also do it for you.
I should note that Jmol.js and JmolApi.js both allow simple
<div id="xxxx"></div>
within the body and all Jmol calls in the head to populate those. Most
developers I've talked with just don't find that any easier. I
actually like it, because it nicely separates the page formatting (in
the body) from the dynamics (in the head). But still, I rarely do it
unless I really have to. Jmol calls within the body are really just
implementing static code anyway, so one could argue that's where they
should be. But that's probably old school...
Yes, I was not paying enough attention to whole inner workings of
Jmol.js and JmolApplet.js, maybe beause I was more looking at example
code that used inline scripting, and that kinda made me a wee bit angry :)
We could probably do a lot more with jQuery, but since it's only
needed for the AJAX, we haven't felt it necessary to do more with it.
var jmol; // This is the Jmol object on which we are working on
function myclick_listener_function(e){
e.preventDefault(); // If it's a link tag for example, we kill
it's default behaviour
var scriptStr = $(this).data('script'); // We could store all
the scripting in HTML code in HTML5 data attributes
Jmol.script(jmol, scriptStr); // This is where we call Jmol OOP
framework and send some commands to our Jmol applet
}
$(document).ready(function(){
$('#mybutton').bind('click', myclick_listener_function);
});
And this is easier than
Jmol.jmolButton(jmol, "myscript", "mytag")
? What makes that particularly appealing to you?
Jmol.jmolButton() returns HTML instead of HTML already being prepared in
the body, that's it. Basically, the main concern I see is that
JavaScript is doing stuff it could be freed of - like generating HTML
where it's not really necessary. JavaScript is great for adding action
to static HTML, but why should one use it create HTML? Let's say we have
my one and only example:
<p><a href="some_molecule.pdb" class="jmol-load">DNA</a></p>
If Jmol didn't load properly or JavaScript has been disabled, this
allows user to download a PDB file and open it up in whatever software
he likes. If JavaScript is disabled Jmol.jmolButton(jmol, 'load
some_molecule.pdb', 'DNA'); would not even show up.
I think a better argument would be that if you used the jQuery
framework, you could have a much richer user interface -- tabs,
buttons of all sorts, flying images, etc. That, to me, would be a
distinct positive, and I think some interesting examples using, say,
tabbed applet panels (that work -- i.e. never use "display:none")
would be very interesting. (You know about never using display:none
with an applet, right?)
Well fancy stuff is a nice side effect for jQuery, but that is not what
I'm into here.
First, despite the convention, please don't use "jMol" -- we've had
issues with this before and other application. It should just be
"Jmol". Please. Maybe jQuery-Jmol if you must start with a lower-case
letter.
OK jQuery-Jmol it will be.
...
2. Get rid of document.write - it's a fast feature, but it forces
developer to use inline coding. Instead I'd suggest to use native
DOM methods for appending DOM fragments, or the nasty, but still
easy inlineHtml or jQuery's append() or replaceWith();
That is, make all calls after the page has finished loading and the
</body> tag is processed. Right? From
$(document).ready(function()
?
Yes
And then have all of JmolControls.js be implemented using jQuery. I
would welcome that. I just would suggest not looking at all at
Jmol.js. We need to move forward, not backward!
Well not only that, JmolApplet.js could be completely replaced with my
jQuery plugin, as it's what my plugin does - it creates a Jmol applet
and places a HTML code in the placeholder tag.
--
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
