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. :/
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.
A good challenge for you would be to rewrite
<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.
The "IE way" and "others" example was intended to show low level
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.
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.
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.
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
mean that some API would write this tag, OK, but I don't see
the advantage then of that over jmolButton.
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.
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 :)
I should note that Jmol.js and JmolApi.js both allow simple
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...
Jmol.jmolButton() returns HTML instead of HTML already being
prepared in the body, that's it. Basically, the main concern I see
for adding action to static HTML, but why should one use it create
HTML? Let's say we have my one and only example:
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
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
Jmol.script(jmol, scriptStr); // This is where we call
Jmol OOP framework and send some commands to our Jmol
And this is easier than
Jmol.jmolButton(jmol, "myscript", "mytag")
? What makes that particularly appealing to you?
allows user to download a PDB file and open it up in whatever
'load some_molecule.pdb', 'DNA'); would not even show up.
Well fancy stuff is a nice side effect for jQuery, but that is not
what I'm into here.
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?)
OK jQuery-Jmol it will be.
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.
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
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.
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