On 2012.07.16. 16:31, Robert Hanson
Just to confirm, Gusts, I'm totally with you on this.
I've wanted to learn more about jQuery for a long time, and this
seems like a great opportunity.
Superb, I'll be more than glad to help you there.
My key points:
--Anything you want to do in relation to JmolCore/Applet/Api is
great. Jmol.js is history.
--We don't want to remove any of the functionality of
JmolCore/Aplept/Api/Controls/CD/JME/JSpeView, but certainly a new
JQueryApi.js, for example, that would extend that functionality
would be terrific.
I think it would be for the best to just keep them separated for a
while, because my approach is not fully finished yet and as I said,
it's intended as a lightweight buildingblock (just like
JmolApplet.js is now). As you saw previously, there are some things
I didn't know that were kinda deprecated around here (like <param
name="script"...> etc.), so I have to address these issues first,
and maybe we should think about the opportunities with events and
data objects (pre-parsed callback message strings).
--I'm more than happy to share my experience with
issues. Others on this list know a lot about this as well. Some of
these I'm sure jQuery addresses; maybe some (like "a div
containing an applet may not ever be set to display:none") are
Removing the element or setting it to display=none will crash Java,
am I right?
--ChemDoodleWeb.js must not be adjusted -- or if it
is, that must be done in collaboration with Kevin Theissen (who is
probably reading this)
I think I'll go for JME first, which as much as I saw, does not have
a jQuery wrapper at all, but ChemDoodle is somewhere in between, so
it can stay as is for now. Only afterwards we'll need some wrapper
API (like Jmol is now). I just don't understand why it's still
called Jmol, if it's so much more than just Jmol, it should have
been named Online Chem Toolkit or something. :)
I'm still sceptical about that, I really need to do some proof of
concept testing, that it does not work, because it's thee data, that
HTML is all about.
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.
We just can't put scripts in HTML as tag attributes. Period.
Find some other way. Trust me on that one.
This still breaks the separation attempt. I know that it would be a
painfull, in case, if somebody would like to write HTML by hand, but
with authoring tools today it should not be that kind of pain
anymore, especially when HTML5 introduced special attributes for raw
and crazy data to be held inline.
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.
First of all, scripts could run hundreds of lines. Second, we
have tried escaping these, and besides being a royal pain,
mostly it hasn't worked. HTML tags and <param. values are
just not adequate for holders of scripts. It's totally
unnecessary anyway, I think. the solution has been around for
years, and we have had no problem with it. It seems to me you
will quickly find a different way. Perhaps the "data-script"
simply points to a key in an associative array that is created
in the head using an API, for example.
Don't worry, when I started working as webdev it was all about
tables, spacer images and inline DHTML (buzzword at the time, now
it's all bout jQuery, MVC, and whatever not.), but I just saw the
potential in so called semantic web, and I jumped the train,
although at the time the browser support for all this was really
I should note that Jmol.js and JmolApi.js both
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 :)
Coding web pages is an evolving art. All you see there are
best practices from pre-jQuery days. Some of us have seen the
entire process from the start (no CSS, no DIV, no
document.getElementById, etc.). So it's hard to imagine what
you would be angry about. You are blessed to have missed all
that, I think. Welcome to the club.
Not really. I like whole clean and correct concept, but browsers
still don't care (especially IE) about XHTML, and it will interpret
it as HTML. But still, I tend to write my HTML as strictly as XHTML
(always close tags, use double quotes for attributes, use lower case
tag names, etc.).
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 attributes
Jmol.script(jmol, scriptStr); // This is
where we call Jmol OOP framework and send some
commands to our Jmol applet
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
- like generating HTML where it's not really necessary.
why should one use it create HTML?
Well, for one thing, that was pretty much the original
page. Newer browser capability has allowed that original
function to be expanded greatly, and the combination of CSS
and DOM in particular has greatly extended the use of
=, that seems rather unnecessarily harsh. Even jQuery must use
innerHTML, I think.
If you mean, "Never use document.write," then what you are
basically saying is simply, "Let's move this to XHTML
standards." That's certainly of interest to some Jmol page
developers. We explored this three years ago, and mostly it
didn't go anywhere.
And so, innerHtml is not the same as document.write, for one, it
will allow you to fill a specific element from different location in
the source, where document.write on the other hand writes right in
the place from where it was called.
working with DOM, and if DOM has been initialized as XHTML then
innerHtml, just sends some kind of eval() to the browsers DOM
parser, where it turns into a DOM fragment, whereas it really does
not matter anymore weather it is XHTML or just plain old HTML.
Q: Is jQuery XHTML compliant?
I think it's not really a matter of concern with jQuery. jQuery is
innerHtml in XHTML, the only thing you might have to worry is that
the innerHTML receives correctly formed XHTML source (which I tend
to use anyway).
If you want to remove all document.write, it seems to me
you might as well go to XHTML compliance. That might require
hacking of jQuery, though....
I'd propose a different approach and throw in one more buzzword -
accessibility :) neither Flash nor Java is good with all the screen
readers for blind people, but they are not my main concern here. My
approach would be to show a static image in the placeholder in the
first place and then gradually replace it with Jmol applet
(instantly or with a mouse click). By the way, it's the approach http://www.pdb.org/ are using,
which, I must say, is really thought trough. I think it's called
degrading gracefully. And throwing in an option for file download if
Jmol could not be started is one of them.
Let's say we have my one
and only example:
disabled, this allows user to download a PDB file and open
disabled Jmol.jmolButton(jmol, 'load some_molecule.pdb',
'DNA'); would not even show up.
all Jmol web apps, the app is toast. jQuery is dead, Jmol is
dead, the page is probably totally malformed. I've never seen
ever turned that off and seen how far you can get? But you are
right, probably something more than a blank page is advisable.
In any case, no one wants to download a pdb file as last
resort. That's way too esoteric. (Anyone who could read that
file will not want it this way.) If the applet doesn't load,
the best solution is to provide an image. That's what
JmolApplet.js does, upon request.
in their browsers, I was visiting St. Petersburg two years ago and
this guy, I stayed with, told me that they are kind of paranoid
about the hacker scene there.