Gusts,
I'm excited about your contributions. jQuery has been mostly an enigma to
me, and it would be good to learn more from someone who really groks it.
History on this is that the original direction for OOP (earlier this year)
had to do with getting something going on mobile and other Java-challenged
devices. For that we chose ChemDoodle as a partner, and ChemDoodle uses
jQuery for its AJAX. We didn't have need for all the jQuery CSS stuff at
this stage, so we opted for not using the full jQuery concept. So the model
you see there is the ChemDoodle model of implementation of jQuery.
The original idea was to develop a Jmol plug-in to ChemDoodle, but upon
reflection we ended up going the other way around, and implementing
ChemDoodle (and JME and JSpecView) plug-ins for Jmol instead. The
ChemDoodle experiment was successful -- we can pretty much hide from the
page developer all the complexity of implementing simple applications using
Jmol on non-Java devices. And we now have smooth 2D drawing --> 3D
modeling capability using JME. JSpecView allows linking of the JSpecView
applet with Jmol for linking spectra to structure.
specifics below...
On Wed, Jul 11, 2012 at 6:50 AM, Gusts Kaksis <gusts.kak...@gmail.com>wrote:
> Hello Bob,
>
> I took a deeper look into the new OOP approach, but I have to say it still
> brings some legacy with it - the one I'd suggest you to get rid of. I am
> talking about inline scripting. For example, the new code still looks like
> this (somewhere in between tables, ew :), and body tags):
>
> // The standard call to insert the applet follows.
> // Note that we redefine the variable now to be an object.
> jmol = Jmol.getApplet(jmol, Info);
>
>
And this is a problem because....?
In between tables and body .... You could certainly avoid that by creating
divs and then later populating them, is that what you are thinking?
> And then thease:
> ...
> Jmol.jmolBr()
> Jmol.jmolButton(jmol,"load ? ","Load URL")
> Jmol.jmolBr()
> ...
>
> Which are the things I'm still preaching against. :) First of all - why
> does anyone need a special method to create a <br> tag, I know it would be
> a mess to mix <br><script>...</script><br> and so on,
>
>
Well, if you are preaching, I suggest you come down from your pulpit and
maybe just explain your position. ;) I'll be the first to listen. Much of
what you see there is legacy, going way back, and the jmolBr() is sort of
silly, but if you are creating a page with lots of customized buttons, this
is just a convenience. No one says you have to use it. jmolHtml() is the
same.
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.
> but then why do we need to write button with JavaScript, when there is a
native API for catching events like this:
>
> var button = document.getElementById(' mybutton');
> button.addEventListener(' click', myclick_listener_function); // FF,
Chrome, Safari, others.
> or
> button.attahEvent('click', myclick_listener_function); // IE way
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.
> this code can be placed way out of HTML into a separate code for dynamic
> scripting and can be run at window.onload if you wish so. And then there
> could be a clean HTML code looking like this:
>
> <p><input type="button" id="mybutton" data-script="load ?" value="Load
> URL" /></p>
> <!-- data-* are HTML5 data attributes, where any content unrelated data
> can be stored -->
>
>
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.
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...
> Second, If you say, you are already using jQuery as an AJAX provider, then
> why not use it on fullest?
>
>
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?
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?)
> And third. jMol jQuery plugin is intended only as as "write less, do more"
> wrapper for Jmol applet. It replaces a placeholder (which, by the way,
> could tell people to enable JavaScript if they have it disabled) with a
> Jmol applet. So I propose it as a building block for your OOP approach.
>
>
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.
Certainly you can do that now with Jmol. Just create the div:
<div id="jmoldiv"><noscript>You will need JavaScript to view this
page</noscript></div>
and then, on your body onload event, use:
Jmol.setDocument(0);
document.getElementById("jmoldiv").innerHTML = Jmol.getApplet(....)
> Also, as the modularity is kept intact users could choose weather they
> want to use full blown experience with JmolCore, JmolAPI, etc. or just use
> parts of it - like jQuery plugin, WebGL approach or write <object> tags
> them selves.
>
>
Not seeing that as being different from what we have now. Users can choose
any combination of WebGL/Java Applet/HTML5-only/image only.
> Here are a few suggestions where to start:
> 1. Get rid of legacy button, checkbox, br and any other methods or change
> them into something like Jmol.addScript(jmol_object, html_element,
> script_source). Which, from inside, would look something like this, in
> jQuery's terms:
> ...
> $(html_element).data('script', script_source);
> $(html_element).click(function(e){
> e.preventDefault();
> jmol_object.script($(this).data('script'));
> });
>
Very cool. As long as you can get all the functionality of what we have
now, it certainly looks good to me. Take a careful look at what those calls
allow. It's probably all doable. I think you just have to rewrite
JmolControls.js if you want to implement this. Take a look there and see
what you could do to create JmolControlsJQuery.js. Make sure the actual
functionality is exactly what it does now.
> ...
> Easy as that :) And html_element can be anything.
> 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()
?
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!
Bob
------------------------------------------------------------------------------
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
