On 2012.07.16. 16:31, Robert Hanson wrote:
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.
Noted
--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 less obvious.
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. :)
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.
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.
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.
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.
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 :)
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.
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 bad. :)
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?
Well, for one thing, that was pretty much the original function of
JavaScript -- to create HTML on the fly for a 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 JavaScript. If you are saying you never want to use
.innerHTML =, 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.
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.).
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.
Q: Is jQuery XHTML compliant?
I think yes, because, it doesn't really matter, as JavaScript is working
with DOM, and if DOM has been initialized as XHTML then JavaScript will
work with it. If I'm not mistaken, the same 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.
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 think it's not really a matter of concern with jQuery. jQuery is just
a mild abstraction over native JavaScript, so if you use 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).
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.
Agreed. But also, if JavaScript is disabled, for just about all Jmol
web apps, the app is toast. jQuery is dead, Jmol is dead, the page is
probably totally malformed. I've never seen a need to cater to users
who turn off JavaScript. Have you 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.
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.
You would be surprised how many people in Russia disable JavaScript 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.
--
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
