From: Gusts K. <gus...@gm...> - 2012-07-10 15:47:35
|
Hello! I would like to propose a completely standalone jQuery plugin for Jmol. I searched the web and found only one solution that works as a wrapper for Jmol.js, so I took my time and wrote this alpha version, which does not use Jmol.js at all. I've hosted it on GitHub: https://github.com/gusc/jMol A brief history. My father is a Ph.D in bio chemistry, and he's still using Chime plugins for old Firefox (well he even used to use Netscape some 2 years ago), but the times are changing, and it's getting harder for him to show his students how to get that old software running on new PCs or even Macs. So I set up to help him out. Being a web developer for almost 10 years now and also having a masters degree in physical chemistry, although after graduation my work has mostly been concentrated on software and web development, there's still a small part of me that's been fascinated about the work on Jmol. First of all it's cross platform, with all the scripting possibilities and it's kind of easy to use in a web environment. And so there was this "kind of easy to use" part in me, that made me create this jQuery plugin, because you know, it's a professional cretinism thing. :) It's a new era in web development (for about 6 years now), and it was really like, throwing me back a few years, when I found out that I have to use inline scripting. But don't get offended guys, you've done great job, so that's why I would love to share with you this prototype of jMol (mind the small j :)) which could be a complete replacement of Jmol.js. I've currently tested it on (and it works with some small quirks): Google Chrome on Windows - works Firefox 12.0 on Windows - works Firefox 13.0.1 on Windows - started up, but displayed status message "Jmol script terminated" Internet Explorer 8.0 - works Safari 5.1.7 on Mac - works Safari 5.1.4 on Windows - could not load Java at all (as in plug-in not found) Opera 11.61 on Windows - started up, but could not execute scripts as a script method was not found on an object (might be something with a HTML object tag formatting on Opera) And if we are still on a subject, where can I find some documentation on external methods, that can be accessed through JavaScript? I've looked though Jmol site for 2 days straight, but it's all about scripting options and Jmol.js, except for a applet.script() method. I looked in to SVN, but all I could find was this undocumented applet source (which as much as I understood is the front-end of an applet, isn't it?): http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/src/JmolApplet.java?revision=16759&view=markup Sincerely Yours, Gusts Kaksis http://gusc.lv/ |
From: A. H. <ang...@ua...> - 2012-07-10 18:22:26
|
Hello Gusts You will receive replies from more authoritative sources, but I will share my 2 cents. First, although Jmol.js is the standard way of using Jmol applets, there is a recent replacement that uses an object-based syntax. You should make sure to look at it (only for Jmol 12.3.x). It's made up with JmolCore.js, JmolApi.js, JmolApplet.js, JmolControls.js, etc http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/appletweb/ I have used Jmol with jQuery without trouble, but I'm not an expert on jQuery at all. Please be careful with the upper/lowercase. There have been concerns before with other software, so there should be no change in the name. > Firefox 13.0.1 on Windows - started up, but displayed status message > "Jmol script terminated" Do you have a test URL? I'd like to have a look. > And if we are still on a subject, where can I find some documentation on > external methods, that can be accessed through JavaScript? Whatever is available in Jmol.js is what most of us use to interface with Jmol. But you will get advice from Bob. > except for a applet.script() method I bet that's pretty old. For most browsers the applet tag is not being used, but the object tag is. And from that it has been born the new "Jmol object" model that I mentioned above. That creates a Jmol DOM/javascript object and has methods for it. I Haven't gone through details yet, as this is quite recent.. |
From: Gusts K. <gus...@gm...> - 2012-07-10 19:27:27
|
Hello Angel! > First, although Jmol.js is the standard way of using Jmol applets, there is a recent > replacement that uses an object-based syntax. You should make sure to look at it (only for > Jmol 12.3.x). It's made up with JmolCore.js, JmolApi.js, JmolApplet.js, JmolControls.js, etc > > http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/appletweb/ > > I have used Jmol with jQuery without trouble, but I'm not an expert on jQuery at all. Yes, I took a look into the new JavaScript API, but it still does not fix the problem I see. Of course, jQuery isn't the only solution, as there are other powerful frameworks used today, like Prototype, Mootools, YUI, extJS, etc., but as jQuery currently is one-of the popular frameworks around, I thought my work could help. The problem mostly, and I don't want to be a new guy in town bragging about stuff, is that current JavaScript solutions do not work well with modern web development paradigms. The paradigm goes like this: 1. HTML is used only for laying out the data (Java guy's should see this in a similar way as XML - which is a human readable data markup language, but it does not include any information about visual or programmatic behaviour), which still is just a text - the majority of information floating around the web; 2. CSS is used to add some visual sugar to our data 3. JavaScript is used to add some dynamic actions to our data (like displaying molecular data on the page, where if you do not posses Java or JavaScript you should be allowed to download this data, to use locally, with your own viewer) 4. And last but not least - keep them all separated. This is why in my example on GitHub I've used a separate file named main.js where all the JavaScript logic happens, keeping HTML code free from any in line actions, like onclick="javascript:Jmol.doSomething();" - this is considered bad now days. In the coming day's I should probably come up with some good examples of how I, as a web developer, see these things should be done, so that I don't stir a tornado in the glass of water for nothing :) > Please be careful with the upper/lowercase. There have been concerns before with other > software, so there should be no change in the name. I agree, maybe not the best choice, but it was more like pun-intended. :) Also because some of jQuery plugins are named starting with a lowercase j and then some other name starting with a capital letter, explicitly pointing out that it's something to do with jQuery. >> Firefox 13.0.1 on Windows - started up, but displayed status message >> "Jmol script terminated" > > Do you have a test URL? > I'd like to have a look. Sorry, I think I found the source of error already - it looks like, there are times when Java does not, or misses the point when to, register external methods with a browser, that's why my call to the script() when into the error log (which I didn't check, sorry), and the message was that HTMLObject does not have a function called script() >> And if we are still on a subject, where can I find some documentation on >> external methods, that can be accessed through JavaScript? > > Whatever is available in Jmol.js is what most of us use to interface with Jmol. But you will get > advice from Bob. Well, yes, the point for me still remains to avoid Jmol.js, so I was looking for more information about external methods available directly on applet from JavaScript. >> except for a applet.script() method > > I bet that's pretty old. For most browsers the applet tag is not being used, but the object tag > is. > And from that it has been born the new "Jmol object" model that I mentioned above. That > creates a Jmol DOM/javascript object and has methods for it. I Haven't gone through details > yet, as this is quite recent.. Don't worry, it's a name of a private variable not the real window.applets. I should have made my self clear: var applet = $('#jmol-viewer').get(0); // The jQuery way or var applet = document.getElementById('jmol-viewer'); // native JavaScript way and then applet.script('load /my_molecule.pdb'); But as I've seen on the applet source (and Jmol.js), there seems to be even more external methods like loadInline, syncScript, etc. And I wanted to find out more about them, because there is no documentation in the source, or should I look in some other source files? -- Gusts Kaksis Web Developer |
From: Robert H. <ha...@st...> - 2012-07-11 02:39:52
|
Gusts, Very interesting idea. I guess our recent work had a different approach -- Use jQuery as an accompaniment to Jmol, ChemDoodle, JME, and JSpecView, but don't build Jmol INTO any of those. Please do check out http://chemapps.stolaf.edu/jmol/docs/examples-12 and related examples -- http://chemapps.stolaf.edu/jmol/chemdoodle http://chemapps.stolaf.edu/jmol/jme http://chemapps.stolaf.edu/jmol/jspecview These illustrate our new object-based approach that does use jQuery (for AJAX primarily) to access server-side functionality and xhr2 protocols. Feel free to illustrate what the advantages of a Jmol plug in to jQuery would be. Bob Hanson -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Gusts K. <gus...@gm...> - 2012-07-11 11:50:24
|
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 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, 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 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 --> Second, If you say, you are already using jQuery as an AJAX provider, then why not use it on fullest? 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 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. 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. 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')); }); ... 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(); So that's my little thought :) By the way, I composed a little web site with examples for the plugin: http://gusc.lv/jmol/ Best Wishes, Gusts On 2012.07.11. 5:39, Robert Hanson wrote: > Gusts, > > Very interesting idea. > > I guess our recent work had a different approach -- Use jQuery as an > accompaniment to Jmol, ChemDoodle, JME, and JSpecView, but don't build > Jmol INTO any of those. Please do check out > http://chemapps.stolaf.edu/jmol/docs/examples-12 and related examples -- > > http://chemapps.stolaf.edu/jmol/chemdoodle > http://chemapps.stolaf.edu/jmol/jme > http://chemapps.stolaf.edu/jmol/jspecview > > These illustrate our new object-based approach that does use jQuery > (for AJAX primarily) to access server-side functionality and xhr2 > protocols. Feel free to illustrate what the advantages of a Jmol plug > in to jQuery would be. > > > Bob Hanson > -- > Robert M. Hanson > Larson-Anderson Professor of Chemistry > Chair, Chemistry Department > St. Olaf College > Northfield, MN > http://www.stolaf.edu/people/hansonr > > > If nature does not answer first what we want, > it is better to take what answer we get. > > -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 > > > > > ------------------------------------------------------------------------------ > 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 > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- Gusts Kaksis |
From: Gusts K. <gus...@gm...> - 2012-07-11 18:16:40
|
Hello, it's me again! I just found out one interesting thing about Jmol applet and I wanted to clear things up. As it seems, the appletReadyCallback delivers 4th and undocumented attribute, which is an internal object of the applet (applet wrapper) with all the public methods? Is it so? Well I tested it and it works, and it works more reliable, than trying to catch the object with document.getElementById('applet_id'), which for some reason, every almost 2nd time threw an error message that object has no method called script(), again this object received by callback works flawlessly. I pushed updates to GitHub now and updated my example page, and it would be nice if somebody could give me some response on testing. Source: https://github.com/gusc/jMol Examples and documentation: http://gusc.lv/jmol/ Current testing results: Google Chrome on Windows - works Firefox 13.0.1 on Windows - works Safari 5.1.4 on Windows - still does not work, because it can not find JRE Safari 5.1.7 on Mac - works (at some point it didn't and it showed a security exception in Java console, then I read the article on Jmol wiki about UseCommandThread and that solved the problem) Opera 11.61 on Windows - works Internet Explorer 8.0 on Windows - works And I still have some questions about this JmolApplet class and it's public methods. I'm going to name them, and maybe somebody could send me some info about their usage. If I'm correct, then applet's entry point is located in this file: http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/src/JmolApplet.java?revision=16759&view=markup or is this the wrapper object returned to appletReadyCallback? So the methods: String getPropertyAsString(String infoType) String getPropertyAsString(String infoType, String paramInfo) String getPropertyAsJSON(String infoType) String getPropertyAsJSON(String infoType, String paramInfo) Object getProperty(String infoType) Object getProperty(String infoType, String paramInfo) String loadInlineArray(String[] strModels, String script, boolean isAppend) String loadInlineString(String strModel, String script, boolean isAppend) String loadNodeId(String nodeId) - are thease connected to DOM object's ID attribute? String loadDOMNode(JSObject DOMNode) - same? void script(String script) - this one is clear, it's where all the scripting code goes void syncScript(String script) Object setStereoGraphics(boolean isStereo) String scriptNoWait(String script) String scriptCheck(String script) String scriptWait(String script) String scriptWait(String script, String statusParams) String scriptWaitOutput(String script) Can someone give me an explanation about input/output of thease methods and maybe some intentions on their usage? Gusts |
From: Robert H. <ha...@st...> - 2012-07-14 14:48:50
|
On Wed, Jul 11, 2012 at 1:16 PM, Gusts Kaksis <gus...@gm...>wrote: > Hello, it's me again! > > I just found out one interesting thing about Jmol applet and I wanted to > clear things up. As it seems, the appletReadyCallback delivers 4th and > undocumented attribute, which is an internal object of the applet > (applet wrapper) with all the public methods? Is it so? Well I tested it > and it works, and it works more reliable, than trying to catch the > object with document.getElementById('applet_id'), which for some reason, > every almost 2nd time threw an error message that object has no method > called script(), again this object received by callback works flawlessly. > > You are probably calling document.getElementById too early, before the applet is initialized. This problem is solved using JmolApi.js. There is not problem if you do it right. But there is also no need to use the getElementById call. I get the sense you are going backward on this, not forward. The API provides much better handling of calls to Jmol. Not sure what you are after here. > I pushed updates to GitHub now and updated my example page, and it would > be nice if somebody could give me some response on testing. > > Source: https://github.com/gusc/jMol > Examples and documentation: http://gusc.lv/jmol/ > > Current testing results: > Google Chrome on Windows - works > Firefox 13.0.1 on Windows - works > Safari 5.1.4 on Windows - still does not work, because it can not find JRE > Safari 5.1.7 on Mac - works (at some point it didn't and it showed a > security exception in Java console, then I read the article on Jmol wiki > about UseCommandThread and that solved the problem) > Opera 11.61 on Windows - works > Internet Explorer 8.0 on Windows - works > > We have never had any problems on any of these platforms, so I would be surprised if you did. > And I still have some questions about this JmolApplet class and it's > public methods. I'm going to name them, and maybe somebody could send me > some info about their usage. If I'm correct, then applet's entry point > is located in this file: > > http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/src/JmolApplet.java?revision=16759&view=markup > or is this the wrapper object returned to appletReadyCallback? So the > methods: > > Please see JmolApi.js. It covers all the public methods. > String getPropertyAsString(String infoType) > String getPropertyAsString(String infoType, String paramInfo) > String getPropertyAsJSON(String infoType) > String getPropertyAsJSON(String infoType, String paramInfo) > Object getProperty(String infoType) > Object getProperty(String infoType, String paramInfo) > String loadInlineArray(String[] strModels, String script, boolean isAppend) > String loadInlineString(String strModel, String script, boolean isAppend) > String loadNodeId(String nodeId) - are thease connected to DOM object's > ID attribute? > String loadDOMNode(JSObject DOMNode) - same? > void script(String script) - this one is clear, it's where all the > scripting code goes > void syncScript(String script) > Object setStereoGraphics(boolean isStereo) > String scriptNoWait(String script) > String scriptCheck(String script) > String scriptWait(String script) > String scriptWait(String script, String statusParams) > String scriptWaitOutput(String script) > > Can someone give me an explanation about input/output of thease methods > and maybe some intentions on their usage? > > See the code, and JmolApi.js. The DOM methods were an experiment that didn't go anywhere, really. > Gusts > > > ------------------------------------------------------------------------------ > 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 > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Robert H. <ha...@st...> - 2012-07-14 15:59:56
|
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 <gus...@gm...>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 |
From: Robert H. <ha...@st...> - 2012-07-14 22:32:58
|
Gusts, OK, taking a look now at http://gusc.lv/jmol/assets/js/jquery.jmol.js So I think this is based on Jmol.js, not JmolCore.js, right? In any case, some advice: We need this class to overcome stupid "functionName"-as-a-string passed to Java Applet Note that JmolApi does access the function directly, but I don't know that there is an alternative to sending a String to the Java applet. This function name is (or can be) set by Jmol scripting, so it starts as a String and is saved as a String. Within Java we just access the method with that name. Are you thinking there's a way around that? _cbMeasure = function(id){ switch (arguments[3]){ case 'measurePicked': I guess it's not clear to me why you are implementing callbacks in such a specific way. Page developers generally substitute in their own callbacks to handle their own specific needs. I guess some defaults like this might be handy, but it needs to be clear how someone would override these with their own methods. Remember that hover and pick callback messages can be tailored by the developer. I wouldn't be parsing that string. That's a real hack. var jMol = (function(){ /** * Default option set */ var _defaults = { // Jmol initialization properties appletUrl : '', useSigned : false, syncId: 0, memLimit: 512, width: 400, height: 300, menuUrl : '', modelUrl : '', background: '#000000', // Jmol callback events onEcho: null, // param: msg onMessage: null, // param: args onScript: null, // param: args onSync: function () { return 1; }, }, /** * Unsigned applet file */ _appletFile = 'JmolApplet0.jar', /** * Signed applet file */ _appletFileSigned = 'JmolAppletSigned0.jar', It's important to have a random number indicated as the sync id. Don't just assign 0. See JmolApi for several more defaults. Be sure to make it clear how one overrides these. _htmlTemplate = '<object type="application/x-java-applet" id="%id%" name="%name%" width="%width%" height="%height%"%add_attr%>' + '<param name="syncId" value="%sync_id%"/>' + '<param name="progressbar" value="true">' + '<param name="progresscolor" value="blue">' + '<param name="boxbgcolor" value="%bg_color%"/>' + '<param name="boxfgcolor" value="black">' + '<param name="boxmessage" value="Downloading JmolApplet ...">' + '<param name="mayscript" value="mayscript">' + '<param name="codebase" value="%applet_url%" />' + '<param name="archive" value="%applet_file%" />' + '<param name="code" value="JmolApplet.class" />' + '<param name="java_arguments" value="%java_args%"/>' + '<param name="script" value="%script%"/>' + '%add_param%' + '<param name="appletReadyCallback" value="JmolCallbackWrapper.cbReady" />' + '<param name="hoverCallback" value="JmolCallbackWrapper.cbHover" />' + '<param name="loadStructCallback" value="JmolCallbackWrapper.cbLoad" />' + '<param name="pickCallback" value="JmolCallbackWrapper.cbPick" />' + '<param name="measureCallback" value="JmolCallbackWrapper.cbMeasure" />' + '<param name="syncCallback" value="JmolCallbackWrapper.cbSync" />' + '<p>You do not have Java applets enabled in your web browser, or your browser is blocking this applet.<br>' + 'Check the warning message from your browser and/or enable Java applets in<br>' + 'your web browser preferences, or install the Java Runtime Environment from <a href="http://www.java.com">www.java.com</a><br></p>' + '</object>', The browser checking in Jmol.js and JmolApplet.js probably looks unnecessary to you, but the general philosophy is to make sure this runs on all browsers possible. There's a reason for that. I wouldn't mess with it. Just use JmolApi to deliver this, please. + '<param name="appletReadyCallback" value="JmolCallbackWrapper.cbReady" />' + '<param name="hoverCallback" value="JmolCallbackWrapper.cbHover" />' + '<param name="loadStructCallback" value="JmolCallbackWrapper.cbLoad" />' + '<param name="pickCallback" value="JmolCallbackWrapper.cbPick" />' + '<param name="measureCallback" value="JmolCallbackWrapper.cbMeasure" />' + '<param name="syncCallback" value="JmolCallbackWrapper.cbSync" />' Well, if we can avoid creating multiple objects it would be better. How many primary objects are you creating here -- only JmolCallbackWrapper? Can that all be within "Jmol." ? Also, you don't necessarily do yourself a favor to generate unnecessary callbacks in Jmol. You are loading it up with callbacks when you don't know that the user is interested. That's just wasted communication. /** * It seems that "appletReadyCallback" return's an internal wrapper object * Which we kindly store here to use instead of document.getElementById('some_applet') and then wonder * why an object does not have a method for no reason. */ _applets = {}; yes, that's right, and it works great. That's what we do now in JmolApi. Not sure why you are doing anything with _applets. // Funny thing about Jmol Java applet :) // Hacking is the way to the victory _applets[id] = args[3]; Agreed. I think that one got missed in the documentation. On the ready signal, you need to send all cached scripts. _appletScript = function(id, command){ var applet = _appletFind(id); _appletFind is obsolete. The idea is to always pass the object to the function so that there is no finding anything. This was a legacy default that has caused all sorts of grief and it is good to be done with it. html = html.replace('%script%', script); oooh, I really don't think that is going to work. You aren't escaping double quotes there. Basically we don't send script to the applet in param tags anymore. It just doesn't work reliably. Instead, take any script and append it to a growing script that needs to be sent when you receive the applet ready signal. Most importantly, you need to make sure you never access the applet except after its ready callback. no scripts sent; no queries made. Overall, I think it has great potential. Q: Will changes to jQuery have to be made to ensure the applet never experiences CSS style.display = "none"? Q: Would you be willing to create a version that is built around JmolCore.js instead of Jmol.js? Q: What's your plan for integrating JME, JSpecView, and ChemDoodle into this? Bob -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Gusts K. <gus...@gm...> - 2012-07-16 10:41:09
|
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 |
From: Gusts K. <gus...@gm...> - 2012-07-16 11:32:06
|
> OK, taking a look now at http://gusc.lv/jmol/assets/js/jquery.jmol.js > > So I think this is based on Jmol.js, not JmolCore.js, right? In any > case, some advice: Well, it's kinda based, I just looked up a few things - like what methods are available through public interface from applet to JavaScript and HTML <param> tag options for setting callbacks and initializing some colors etc. > > We need this class to overcome stupid "functionName"-as-a-string passed to Java Applet > > Note that JmolApi does access the function directly, but I don't know > that there is an alternative to sending a String to the Java applet. > This function name is (or can be) set by Jmol scripting, so it starts > as a String and is saved as a String. Within Java we just access the > method with that name. Are you thinking there's a way around that? There isn't. Saddly this is the way web and plugins work together, even in ActionScript you have to call ExternalInterface.call("functionName", someParam); Which is kinda stupid, that you cannot send a pointer/reference to a real function. But I think it's because of the way JavaScript is - it's an interpreted scripting language, so there are no real function hanging somewhere in RAM, that's why you have to use string name from Java side, and the browser looks it up in some kind of hash table of functions. > > _cbMeasure = function(id){ > switch (arguments[3]){ > case 'measurePicked': > > I guess it's not clear to me why you are implementing callbacks in > such a specific way. Page developers generally substitute in their own > callbacks to handle their own specific needs. I guess some defaults > like this might be handy, but it needs to be clear how someone would > override these with their own methods. Remember that hover and pick > callback messages can be tailored by the developer. I wouldn't be > parsing that string. That's a real hack. It's this one beautiful jQuery way of doing things - write less do more. I'm translating all the callbacks into events, so that a developer can subscribe to them and unsubscribe from them on the fly using jQuery APIs, as esasy as : $('#jmol').bind('pick', myPickHandler); and $('#jmol').unbind('pick'); And of course if you send a "set callbackName functionName" script to Jmol then this event mechanism will be broken :( What is the possible output from these callbacks (measure, hover, pick), like what arguments can I expect and what do they mean? I just thought that preparing a consequent data object for these callbacks are more useful for a developer then a raw string. For example, hover and pick methods send really simple data, that can be prepared as I've already done. The measurement is a little bit tougher, and there is really no documentation on your site about all the parameters, so I was doing a wild guess there. :) I know that you can call "set callbackName functionName", but if we're doing it jQuery way, then events are more versatile than callbacks, as you can bind multiple functions to the same event, which is not possible with callbacks. At least I think it isn't, what's happening on Java side there - does set callbackName overwrite previous callback function name? > It's important to have a random number indicated as the sync id. Don't > just assign 0. See JmolApi for several more defaults. Be sure to make > it clear how one overrides these. Random or unique? Because, if it's 0, a real number will be assigned in _appletBuild method which is an applet counter (it increments every time a new applet instance is created in page), that should be unique enough. Or have I forgotten about some inter-window (or even inter-browser) communication? > The browser checking in Jmol.js and JmolApplet.js probably looks > unnecessary to you, but the general philosophy is to make sure this > runs on all browsers possible. There's a reason for that. I wouldn't > mess with it. Just use JmolApi to deliver this, please. This is just a template for HTML output. It's there for clarity, everything else happens in _appletBuild, where I check the browser and OS and, for example, add additional classid and codebase for IE, etc. > > + '<param name="appletReadyCallback" value="JmolCallbackWrapper.cbReady" />' > + '<param name="hoverCallback" value="JmolCallbackWrapper.cbHover" />' > + '<param name="loadStructCallback" value="JmolCallbackWrapper.cbLoad" />' > + '<param name="pickCallback" value="JmolCallbackWrapper.cbPick" />' > + '<param name="measureCallback" value="JmolCallbackWrapper.cbMeasure" />' > + '<param name="syncCallback" value="JmolCallbackWrapper.cbSync" />' > > > > Well, if we can avoid creating multiple objects it would be better. > How many primary objects are you creating here -- only > JmolCallbackWrapper? Can that all be within "Jmol." ? Also, you don't > necessarily do yourself a favor to generate unnecessary callbacks in > Jmol. You are loading it up with callbacks when you don't know that > the user is interested. That's just wasted communication. It's more like a private class intended to intercept callbacks and translate into events. It should never be used as a real class. And it's static, so there is only one instance. As the Jmol itself sends an ID/name of applets <object> tag, this class forwards all the calls to the appropriate jQuery wrapper. As for communication, I agree, I should strip it down even more and use "set callbackName functioName", only for now I can not intercept when user calls jQuery's bind() method. I'll probably have to work on some cheat here, like wrapping jQuery itself. > > > /** > * It seems that "appletReadyCallback" return's an internal wrapper object > * Which we kindly store here to use instead of document.getElementById('some_applet') and then wonder > * why an object does not have a method for no reason. > */ > _applets = {}; > > > yes, that's right, and it works great. That's what we do now in > JmolApi. Not sure why you are doing anything with _applets. I'm not, it's just my private variable, that i've named _applets (as in Java applets, not <applets>) > > // Funny thing about Jmol Java applet :) > // Hacking is the way to the victory > _applets[id] = args[3]; > > Agreed. I think that one got missed in the documentation. Thank god, we cleared up this one, so it's safe to use that 4th argument as the real applet's interface. > > On the ready signal, you need to send all cached scripts. > > _appletScript = function(id, command){ > var applet = _appletFind(id); > > _appletFind is obsolete. The idea is to always pass the object to the > function so that there is no finding anything. This was a legacy > default that has caused all sorts of grief and it is good to be done > with it. Umm, I'm not using any of Jmol.js methods, it's only my jQuery Jmol plugin (as I said, it's completely standalone for now), without any dependencies to Jmol.js or JmolApi.js at all. And _appletFind is my private method to get an applet's interface from internal cache (array) named _applets; > > html = html.replace('%script%', script); > > > oooh, I really don't think that is going to work. You aren't escaping > double quotes there. Basically we don't send script to the applet in > param tags anymore. It just doesn't work reliably. Instead, take any > script and append it to a growing script that needs to be sent when > you receive the applet ready signal. OK, script cache it is then. Thease scripts were intended only for 2 things - a menu file and initial model file which are simple commands and you cannot write anything else, just initialize a jQuery plugin with thease options set: menuUrl : 'my_menu.mnu', modelUrl : 'my_model.pdb' and it translates into script variable like this: menu my_menu.mnu; load my_model.pdb That's it, but we can turn it into cached script if you say, that it's the new way of Jmol. > Most importantly, you need to make sure you never access the applet > except after its ready callback. no scripts sent; no queries made. OK. I still need to work on callback setters when needed, and the only callback that will be left at initialization time is ready callback. > Overall, I think it has great potential. Thanks :) > > Q: Will changes to jQuery have to be made to ensure the applet never > experiences CSS style.display = "none"? I think this is close to impossible, as it can happen any way from a different script, written by user. > Q: Would you be willing to create a version that is built around > JmolCore.js instead of Jmol.js? Currently this code is completely stand alone, it does not use any of Jmol's JavaScript APIs. I was thinking of leaving it that way, and maybe propose you to use my solution as a replacement for JmolApplet.js. We just need to agree on a few things if you wish. > > Q: What's your plan for integrating JME, JSpecView, and ChemDoodle > into this? I think it's doable, but I'd preffer to create them as a sepparate projects. You see, jQuery Jmol is intended only as a building block for <object> tag and a communication channel, everything else should be developed by the user or implemented in Jmol's JavaScript APIs. Then I could create jQuery JME for example which is also just a small building block, that replaces a placeholder <div> with an <object> tag and releases some communication channels to outside world, which can be grabbed by higher level API and used. -- Gusts Kaksis |
From: Robert H. <ha...@st...> - 2012-07-16 13:31:49
|
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. 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'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. --ChemDoodleWeb.js must not be adjusted -- or if it is, that must be done in collaboration with Kevin Theissen (who is probably reading this) On Mon, Jul 16, 2012 at 5:40 AM, Gusts Kaksis <gus...@gm...>wrote: > 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. > Great!! > > 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. > > We just can't put scripts in HTML as tag attributes. Period. Find some other way. Trust me on that one. > 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. > > 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. > > 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. Q: Is jQuery XHTML compliant? 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.... > 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 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. > Thanks. > > ... >> >> 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. > Sounds good. I'm totally game for that. JmolApplet.js is simply the current stage in development. I think it should be much easier to work with than Jmol.js since everything is already compartmentalized for you. Looking forward to seeing some pages from you, Bob -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Robert H. <ha...@st...> - 2012-07-16 14:20:22
|
Leap-frogging here.... On Mon, Jul 16, 2012 at 6:31 AM, Gusts Kaksis <gus...@gm...>wrote: > > > > We need this class to overcome stupid "functionName"-as-a-string passed > to Java Applet > > > > Note that JmolApi does access the function directly, but I don't know > > that there is an alternative to sending a String to the Java applet. > > This function name is (or can be) set by Jmol scripting, so it starts > > as a String and is saved as a String. Within Java we just access the > > method with that name. Are you thinking there's a way around that? > There isn't. Saddly this is the way web and plugins work together, even > in ActionScript you have to call ExternalInterface.call("functionName", > someParam); Which is kinda stupid, that you cannot send a > pointer/reference to a real function. But I think it's because of the > way JavaScript is - it's an interpreted scripting language, so there are > no real function hanging somewhere in RAM, that's why you have to use > string name from Java side, and the browser looks it up in some kind of > hash table of functions. > Java can save the JSObject for the function. We could do that; we just don't. I don't think once the function is parsed it is in string form anymore. Evidence of this is that at least with MSIE the function string version is different from what the user typed. Like the way tags are not string anymore after HTML is parsed. They are part of the DOM at that point. > > > > _cbMeasure = function(id){ > > switch (arguments[3]){ > > case 'measurePicked': > > > > I guess it's not clear to me why you are implementing callbacks in > > such a specific way. Page developers generally substitute in their own > > callbacks to handle their own specific needs. I guess some defaults > > like this might be handy, but it needs to be clear how someone would > > override these with their own methods. Remember that hover and pick > > callback messages can be tailored by the developer. I wouldn't be > > parsing that string. That's a real hack. > It's this one beautiful jQuery way of doing things - write less do more. > I'm translating all the callbacks into events, so that a developer can > subscribe to them and unsubscribe from them on the fly using jQuery > APIs, as esasy as : $('#jmol').bind('pick', myPickHandler); and > $('#jmol').unbind('pick'); And of course if you send a "set callbackName > functionName" script to Jmol then this event mechanism will be broken :( > > Well, you need to figure out how to handle that, then, or there's a problem. Callbacks have to be scriptable. > What is the possible output from these callbacks (measure, hover, pick), > like what arguments can I expect and what do they mean? see http://jmol.sourceforge.net/jslibrary/#jmolSetCallback > I just thought > that preparing a consequent data object for these callbacks are more > useful for a developer then a raw string. For example, hover and pick > methods send really simple data, that can be prepared as I've already > done. But the format of those strings is totally programmable by the page developer. You are just using the default settings, so that amounts to a hack. Fine for a demo; not appropriate for a general solution. > The measurement is a little bit tougher, and there is really no > documentation on your site about all the parameters, so I was doing a > wild guess there. :) > > yes, that's a bit hard to find: http://jmol.sourceforge.net/jslibrary/#jmolSetCallback > I know that you can call "set callbackName functionName", but if we're > doing it jQuery way, then events are more versatile than callbacks, as > you can bind multiple functions to the same event, which is not possible > with callbacks. At least I think it isn't, what's happening on Java side > there - does set callbackName overwrite previous callback function name? > Yes, it sets the callback function name to a new function. > > It's important to have a random number indicated as the sync id. Don't > > just assign 0. See JmolApi for several more defaults. Be sure to make > > it clear how one overrides these. > Random or unique? Because, if it's 0, a real number will be assigned in > _appletBuild method which is an applet counter (it increments every time > a new applet instance is created in page), that should be unique enough. > Or have I forgotten about some inter-window (or even inter-browser) > communication? > These need to be unique across an entire session, not just a page. Someone could easily have multiple pages with Jmol applets, and for rapid inter-applet communication we need to register the applets. Thus they need unique names. 10 digits of randomness is sufficient, though not perfect. > > The browser checking in Jmol.js and JmolApplet.js probably looks > > unnecessary to you, but the general philosophy is to make sure this > > runs on all browsers possible. There's a reason for that. I wouldn't > > mess with it. Just use JmolApi to deliver this, please. > This is just a template for HTML output. It's there for clarity, > everything else happens in _appletBuild, where I check the browser and > OS and, for example, add additional classid and codebase for IE, etc. > > > > + '<param name="appletReadyCallback" > value="JmolCallbackWrapper.cbReady" />' > > + '<param name="hoverCallback" > value="JmolCallbackWrapper.cbHover" />' > > + '<param name="loadStructCallback" > value="JmolCallbackWrapper.cbLoad" />' > > + '<param name="pickCallback" > value="JmolCallbackWrapper.cbPick" />' > > + '<param name="measureCallback" > value="JmolCallbackWrapper.cbMeasure" />' > > + '<param name="syncCallback" > value="JmolCallbackWrapper.cbSync" />' > > > > > > > > Well, if we can avoid creating multiple objects it would be better. > > How many primary objects are you creating here -- only > > JmolCallbackWrapper? Can that all be within "Jmol." ? Also, you don't > > necessarily do yourself a favor to generate unnecessary callbacks in > > Jmol. You are loading it up with callbacks when you don't know that > > the user is interested. That's just wasted communication. > It's more like a private class intended to intercept callbacks and > translate into events. It should never be used as a real class. And it's > static, so there is only one instance. As the Jmol itself sends an > ID/name of applets <object> tag, this class forwards all the calls to > the appropriate jQuery wrapper. > > Take a look at what is done in JmolApplet.js. There is no issue of ID there. The applet is sent the correct function name up front for the callback, and that always goes to the proper _Applet straight away. No need for checking later. See if you can do this with out the _applets associative array. > As for communication, I agree, I should strip it down even more and use > "set callbackName functioName", only for now I can not intercept when > user calls jQuery's bind() method. I'll probably have to work on some > cheat here, like wrapping jQuery itself. > ouch. > > > > > > /** > > * It seems that "appletReadyCallback" return's an internal > wrapper object > > * Which we kindly store here to use instead of > document.getElementById('some_applet') and then wonder > > * why an object does not have a method for no reason. > > */ > > _applets = {}; > > > > > > yes, that's right, and it works great. That's what we do now in > > JmolApi. Not sure why you are doing anything with _applets. > I'm not, it's just my private variable, that i've named _applets (as in > Java applets, not <applets>) > I think you are using it to find the correct applet. This should not be necessary. > > > > // Funny thing about Jmol > Java applet :) > > // Hacking is the way to > the victory > > _applets[id] = args[3]; > > > > Agreed. I think that one got missed in the documentation. > Thank god, we cleared up this one, so it's safe to use that 4th argument > as the real applet's interface. > It's just very new. Came with JmolApplet.js and Jmol 12.3. > > > > On the ready signal, you need to send all cached scripts. > > > > _appletScript = function(id, command){ > > var applet = _appletFind(id); > > > > _appletFind is obsolete. The idea is to always pass the object to the > > function so that there is no finding anything. This was a legacy > > default that has caused all sorts of grief and it is good to be done > > with it. > Umm, I'm not using any of Jmol.js methods, it's only my jQuery Jmol > plugin (as I said, it's completely standalone for now), without any > dependencies to Jmol.js or JmolApi.js at all. And _appletFind is my > private method to get an applet's interface from internal cache (array) > named _applets; > RIght. That's what I'm trying to avoid if possible. Can you set up a simple page with two applets and show us how we can query them in different ways and get different callbacks? For example, get the state from one and pass it to the other? > > > > html = html.replace('%script%', script); > > > > > > oooh, I really don't think that is going to work. You aren't escaping > > double quotes there. Basically we don't send script to the applet in > > param tags anymore. It just doesn't work reliably. Instead, take any > > script and append it to a growing script that needs to be sent when > > you receive the applet ready signal. > OK, script cache it is then. Thease scripts were intended only for 2 > things - a menu file and initial model file which are simple commands > and you cannot write anything else, just initialize a jQuery plugin with > thease options set: > > menuUrl : 'my_menu.mnu', > modelUrl : 'my_model.pdb' > > and it translates into script variable like this: > > menu my_menu.mnu; > load my_model.pdb > > Nice for a demo; not of general use. People don't just load files, generally. > That's it, but we can turn it into cached script if you say, that it's > the new way of Jmol. > > Most importantly, you need to make sure you never access the applet > > except after its ready callback. no scripts sent; no queries made. > OK. I still need to work on callback setters when needed, and the only > callback that will be left at initialization time is ready callback. > It's the ready callback that probably should initialize all the other callbacks. Otherwise your buttons will be active prior to the applet being ready, and a press of a button could crash the browser. (really) > > Overall, I think it has great potential. > Thanks :) > > > > Q: Will changes to jQuery have to be made to ensure the applet never > > experiences CSS style.display = "none"? > I think this is close to impossible, as it can happen any way from a > different script, written by user. > It must not happen, and it must not be possible to do this inadvertently -- specifically because jQuery might happen to do this in some context the user is not aware of. This is absolutely necessary. I would say this is a major concern. Unfortunately, for many browsers it does not matter, so someone not testing on MSIE will think their page works great, and if they have, say, used jQuery extensively and built their page around some cool jQuery functionality such as tabbed divs, they could be in for a huge surprise way late in the game. So, if nothing else, we need to identify exactly when jQuery would do that and have very visible information for users to NOT use that particular functionality. Just a quick look at an old jQuery code I have on hand: // Go through and make them visible, but in reverse // (It would be better if we knew the exact display type that they had) for ( var i = 0; i < stack.length; i++ ) if ( color( stack[ i ] ) ) { swap[ i ] = stack[ i ].style.display; stack[ i ].style.display = "block"; } // Since we flip the display style, we have to handle that // one special, otherwise get the value ret = name == "display" && swap[ stack.length - 1 ] != null ? "none" : ( getComputedStyle && getComputedStyle.getPropertyValue( name ) ) || ""; // Finally, revert the display styles back for ( var i = 0; i < swap.length; i++ ) if ( swap[ i ] != null ) stack[ i ].style.display = swap[ i ]; Death to the applet in MSIE. Animation, for example, would probably be in this category. > > Q: Would you be willing to create a version that is built around > > JmolCore.js instead of Jmol.js? > Currently this code is completely stand alone, it does not use any of > Jmol's JavaScript APIs. I was thinking of leaving it that way, and maybe > propose you to use my solution as a replacement for JmolApplet.js. We > just need to agree on a few things if you wish. > Long range, that sounds good. If it were me, I'd build off JmolCore and then, once it all works, abandon JmolCore. Seems to me starting from scratch would be hugely more difficult. But that's just me. > > > > Q: What's your plan for integrating JME, JSpecView, and ChemDoodle > > into this? > I think it's doable, but I'd preffer to create them as a sepparate > projects. You see, jQuery Jmol is intended only as a building block for > <object> tag and a communication channel, everything else should be > developed by the user or implemented in Jmol's JavaScript APIs. Then I > could create jQuery JME for example which is also just a small building > block, that replaces a placeholder <div> with an <object> tag and > releases some communication channels to outside world, which can be > grabbed by higher level API and used. > The main issue in my mind is that functionality is not lost. Bob > > -- > 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 > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Gusts K. <gus...@gm...> - 2012-07-16 15:01:32
|
On 2012.07.16. 17:20, Robert Hanson wrote: > Leap-frogging here.... > > > On Mon, Jul 16, 2012 at 6:31 AM, Gusts Kaksis <gus...@gm... > <mailto:gus...@gm...>> wrote: > > > > > We need this class to overcome stupid "functionName"-as-a-string > passed to Java Applet > > > > Note that JmolApi does access the function directly, but I don't > know > > that there is an alternative to sending a String to the Java > applet. > > This function name is (or can be) set by Jmol scripting, so it > starts > > as a String and is saved as a String. Within Java we just access the > > method with that name. Are you thinking there's a way around that? > There isn't. Saddly this is the way web and plugins work together, > even > in ActionScript you have to call > ExternalInterface.call("functionName", > someParam); Which is kinda stupid, that you cannot send a > pointer/reference to a real function. But I think it's because of the > way JavaScript is - it's an interpreted scripting language, so > there are > no real function hanging somewhere in RAM, that's why you have to use > string name from Java side, and the browser looks it up in some > kind of > hash table of functions. > > > > Java can save the JSObject for the function. We could do that; we just > don't. I don't think once the function is parsed it is in string form > anymore. Evidence of this is that at least with MSIE the function > string version is different from what the user typed. Like the way > tags are not string anymore after HTML is parsed. They are part of the > DOM at that point. Then a static callback wrapper class will be necessary, or maybe there is a possibility to introduce a new method in applets public interface where I could add private methods, not just a string name. Just like a script() method. Something like addCallback(callbackName, callbackFunctionPtr). Because private methods (functions within functions in JavaScript) are not accessible globally. thus they can not be set with "set callbackName functionName". > > What is the possible output from these callbacks (measure, hover, > pick), > like what arguments can I expect and what do they mean? > > > see http://jmol.sourceforge.net/jslibrary/#jmolSetCallback I'm more intereseted weather the syntax of hover's 1st parameter will allways be "atom atmo_num x y z"? And what about those parameters of measurement? "Angle H #2 - C #1 - H #3 : 109.477165", 3, "measurePicked", 109.47716522216797 1st - a string representation of a mesurement 2nd - ? 3rd - action name? 4th - the angle as a float, right? I think it would be easier for a developer if thease values would be presented in a nice and documented structure, so that they can create whatever output they wish from it. > > I just thought > that preparing a consequent data object for these callbacks are more > useful for a developer then a raw string. For example, hover and pick > methods send really simple data, that can be prepared as I've already > done. > > > But the format of those strings is totally programmable by the page > developer. You are just using the default settings, so that amounts to > a hack. Fine for a demo; not appropriate for a general solution. Aah, so you can script the output of these callbacks through Jmol's scripting? > > The measurement is a little bit tougher, and there is really no > documentation on your site about all the parameters, so I was doing a > wild guess there. :) > > > yes, that's a bit hard to find: > http://jmol.sourceforge.net/jslibrary/#jmolSetCallback Well the question is about all the parameters, this documentation just covers the string output, but as I mentioned before, there are more arguments coming out from Jmol. > > I know that you can call "set callbackName functionName", but if we're > doing it jQuery way, then events are more versatile than callbacks, as > you can bind multiple functions to the same event, which is not > possible > with callbacks. At least I think it isn't, what's happening on > Java side > there - does set callbackName overwrite previous callback function > name? > > > Yes, it sets the callback function name to a new function. So for jQuery user's it would be more convenient to use events, I just need to think of a hack to catch a moment when someone binds a listener to some of my custom events (like, hover or pick) > > > It's important to have a random number indicated as the sync id. > Don't > > just assign 0. See JmolApi for several more defaults. Be sure to > make > > it clear how one overrides these. > Random or unique? Because, if it's 0, a real number will be > assigned in > _appletBuild method which is an applet counter (it increments > every time > a new applet instance is created in page), that should be unique > enough. > Or have I forgotten about some inter-window (or even inter-browser) > communication? > > > These need to be unique across an entire session, not just a page. > Someone could easily have multiple pages with Jmol applets, and for > rapid inter-applet communication we need to register the applets. Thus > they need unique names. 10 digits of randomness is sufficient, though > not perfect. Ok, noted, I'll implement Jmol's solution then. > > > Well, if we can avoid creating multiple objects it would be better. > > How many primary objects are you creating here -- only > > JmolCallbackWrapper? Can that all be within "Jmol." ? Also, you don't > > necessarily do yourself a favor to generate unnecessary callbacks in > > Jmol. You are loading it up with callbacks when you don't know that > > the user is interested. That's just wasted communication. > > It's more like a private class intended to intercept callbacks and > translate into events. It should never be used as a real class. > And it's > static, so there is only one instance. As the Jmol itself sends an > ID/name of applets <object> tag, this class forwards all the calls to > the appropriate jQuery wrapper. > > > Take a look at what is done in JmolApplet.js. There is no issue of ID > there. The applet is sent the correct function name up front for the > callback, and that always goes to the proper _Applet straight away. No > need for checking later. See if you can do this with out the _applets > associative array. Well I had problems there. Even after I received a message from readyCallback, the applets object still does not have a script() methods exported to JavaScript. That's why I'm storing the internal object received by readyCallback into _applets array. > > As for communication, I agree, I should strip it down even more > and use > "set callbackName functioName", only for now I can not intercept when > user calls jQuery's bind() method. I'll probably have to work on some > cheat here, like wrapping jQuery itself. > > > ouch. Yep :) > > > > > // Funny thing > about Jmol Java applet :) > > // Hacking is the > way to the victory > > _applets[id] = args[3]; > > > > Agreed. I think that one got missed in the documentation. > Thank god, we cleared up this one, so it's safe to use that 4th > argument > as the real applet's interface. > > > It's just very new. Came with JmolApplet.js and Jmol 12.3. Well then maybe I'll still stick with this, because, as I mentioned previously - I had a lot of problems, event after receiving a message to readyCallback - "HTMLObject does not have a method named script()", but not every time, it was like 2 times it worked, and then some 4 times it didn't (just simply refreshing a page). > > > > > On the ready signal, you need to send all cached scripts. > > > > _appletScript = function(id, command){ > > var applet = _appletFind(id); > > > > _appletFind is obsolete. The idea is to always pass the object > to the > > function so that there is no finding anything. This was a legacy > > default that has caused all sorts of grief and it is good to be done > > with it. > Umm, I'm not using any of Jmol.js methods, it's only my jQuery Jmol > plugin (as I said, it's completely standalone for now), without any > dependencies to Jmol.js or JmolApi.js at all. And _appletFind is my > private method to get an applet's interface from internal cache > (array) > named _applets; > > > RIght. That's what I'm trying to avoid if possible. Can you set up a > simple page with two applets and show us how we can query them in > different ways and get different callbacks? For example, get the state > from one and pass it to the other? OK, I'll try it out tomorrow. > > That's it, but we can turn it into cached script if you say, that it's > the new way of Jmol. > > Most importantly, you need to make sure you never access the applet > > except after its ready callback. no scripts sent; no queries made. > OK. I still need to work on callback setters when needed, and the only > callback that will be left at initialization time is ready callback. > > > It's the ready callback that probably should initialize all the other > callbacks. Otherwise your buttons will be active prior to the applet > being ready, and a press of a button could crash the browser. (really) OK. Even better solution would be, if I could somehow catch this event binding in jQuery, but for now it seems won't be able to do that in a legal manner. :) > > > Overall, I think it has great potential. > Thanks :) > > > > Q: Will changes to jQuery have to be made to ensure the applet never > > experiences CSS style.display = "none"? > I think this is close to impossible, as it can happen any way from a > different script, written by user. > > > It must not happen, and it must not be possible to do this > inadvertently -- specifically because jQuery might happen to do this > in some context the user is not aware of. This is absolutely > necessary. I would say this is a major concern. Unfortunately, for > many browsers it does not matter, so someone not testing on MSIE will > think their page works great, and if they have, say, used jQuery > extensively and built their page around some cool jQuery functionality > such as tabbed divs, they could be in for a huge surprise way late in > the game. So, if nothing else, we need to identify exactly when jQuery > would do that and have very visible information for users to NOT use > that particular functionality. > > Just a quick look at an old jQuery code I have on hand: > > // Go through and make them visible, but in reverse > // (It would be better if we knew the exact display > type that they had) > for ( var i = 0; i < stack.length; i++ ) > if ( color( stack[ i ] ) ) { > swap[ i ] = stack[ i ].style.display; > stack[ i ].style.display = "block"; > } > > // Since we flip the display style, we have to handle that > // one special, otherwise get the value > ret = name == "display" && swap[ stack.length - 1 ] != > null ? > "none" : > ( getComputedStyle && > getComputedStyle.getPropertyValue( name ) ) || ""; > > // Finally, revert the display styles back > for ( var i = 0; i < swap.length; i++ ) > if ( swap[ i ] != null ) > stack[ i ].style.display = swap[ i ]; > > > Death to the applet in MSIE. > > Animation, for example, would probably be in this category. Ouch. I think I already saw what happens next ... I was testing a fast reset of Jmol - like remove it from DOM and put it back in - IE went dead. Yep, now I get it. One more thing on a todo list. I should start to write it down somewhere in github probably. -- Gusts Kaksis |
From: Gusts K. <gus...@gm...> - 2012-07-16 14:35:22
|
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 |
From: Gusts K. <gus...@gm...> - 2012-07-16 16:31:15
|
Bob, I threw together a simple2.html with my approach (Jmol part only): http://dev.gusc.lv/code/jmol/simple2.html - it's on my devevelopment PC, so it might be a wee bit slow. Please take a look at the html source and at simple2.js file. From my point of view it's as simple as that, if you have any questions, I'll be happy to answer them. Few things to remember: 1. jQuery Jmol is still just a thin abstraction layer over Jmol applet, everything else I've done in pure jQuery - like AJAX loaders etc. 2. I haven't implemented the ChemDoodle yet. 3. I quite didn't understand the point of sending a commands from JavaScript to Java, to prompt for the name of a molecule and then Java (if I'm not mistaken) calls JavaScript back to get a structure through AJAX. So I omitted that part and went straight to AJAX requests using browser's prompt dialog. -- Gusts Kaksis |
From: Robert H. <ha...@st...> - 2012-07-16 17:04:02
|
On Mon, Jul 16, 2012 at 9:35 AM, Gusts Kaksis <gus...@gm...>wrote: > > > --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? > > Not exactly. MSIE reloads the applet, and you lose whatever state it is in. > --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. :) > > Branding. :) > > >> 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. > > It's possible that it's no problem any longer. especially if you aren't actually calling JavaScript in an href tag. So, for example, we try to avoid this: <a href="javascript:Jmol.script(jmol, "load \"my file.xyz\"")">my file</a> I guess in this context that would become something like this: <a data-script="load "my file.xyz"">my file</a> so that helps some. But it is a real pain for page developers, and we've tried to avoid it as much as possible. Since it's easy enough to do, it seems to me it should at least be an option to replace that with something like: <a data-scriptid="loadmyfile">my file</a> and then allow definition of that script id as ' load "my file.xyz" ' > >> 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. > Why do you say that? If the body code would just refer to a user-defined name, then that's equivalent to a script. They can then define the script in the head, prior to after attaching the other business to the link. > 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. > > exactly -- JavaScript still creating HTML. Anyway, I agree it is better practice to avoid document.write. > 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. > > I'm not finding support for that on the web. Depends on things like namespaces and, for example, whether data-xxxx is in a dictionary, I think. > > > 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. > yes, thank you. Glad you like the http;//www.pdb.org solution. Anyway, that's what we have going with JmolApplet.js now. Exactly that. Did you try http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htm on your smart phone? > > 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. > > So for that to work, don't you have to hard-code into your page a <noscript> tag? I guess anyone could do that if they cared to now as well, with JmolApplet.js or with Jmol.js. I'm not seeing the difference between jQuery and not jQuery on that one. So we could recommend some sort of boilerplate for that, but that really isn't relevant to this discussion, is it? Bob > -- > 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 > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > > -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Gusts K. <gus...@gm...> - 2012-07-16 17:47:58
|
On 2012.07.16. 20:03, Robert Hanson wrote: > >> >> >> 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. > > > It's possible that it's no problem any longer. especially if you > aren't actually calling JavaScript in an href tag. So, for example, we > try to avoid this: > > > <a href="javascript:Jmol.script(jmol, "load \"my > file.xyz\"")">my file</a> Not on my watch :) > > > I guess in this context that would become something like this: > > <a data-script="load "my file.xyz"">my file</a> Yes it looks more like that, but for loading I've come up with even better solution: <a href="my file.xyz" class="jmol-load">my file</a> And I just use the magic of jQuery's selectors to add this: $('.jmol-load').click(function(e){ e.preventDefault(); $('#jmol').jmol('load "' + $(this).attr('href') + '"'); }); This is the one solution, that gives user an opportunity to download a file directly weather JavaScript is running (right click -> save as...) or if it's disabled (default action of a link click). And you can even insert an image in between <a> tags so that's a beautiful solution to degrade gracefully. > > so that helps some. But it is a real pain for page developers, and > we've tried to avoid it as much as possible. Since it's easy enough to > do, it seems to me it should at least be an option to replace that > with something like: > > <a data-scriptid="loadmyfile">my file</a> > > and then allow definition of that script id as ' load "my file.xyz" ' I see that actually best part of using a small library just for initialization is to allow a developer to choose his own solution, like I did in my examples. And for seasonal developers, of course, there should be fully featured Jmol library, with internal script caches etc. (maybe). > > >> 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. > > > Why do you say that? If the body code would just refer to a > user-defined name, then that's equivalent to a script. They can then > define the script in the head, prior to after attaching the other > business to the link. I'm starting to think, that there should be at least two clear layers in the API. One for the hard core developers, for example, just jQuery.Jmol.js, for the ones that wish to do everything themselves, and the second one should be fully featured library for seasonal developers or complete amateurs. Last ones could use data-scriptid in conjunction with something like Jmol.storeScript('myScript', 'load "some file.xyz"'), while hardcore guys just go with the Jmol.bindLoader('.jmol-load') or just simply use jQuery. By the way, what is Jmol spt file? It's Jmol's script file source, what about the same use case as in my <a href="file.mol" class="jmol-load">Load my file</a>, just with a prepared script file <a href="wireframe.spt" class="jmol-load">Wireframe</a>. It creates a separate request to the server, but it would really separate HTML even from Jmol's scripts. One more option to think about. > >> 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. > > > I'm not finding support for that on the web. Depends on things like > namespaces and, for example, whether data-xxxx is in a dictionary, I > think. Aah, you mean XML namespaces? Well HTML5 came with XHTML5, dropping the attempt to create XHTML 2 as it was going in completely wrong way (I wouldn't say that, but there were people who thought so). So there should be no problems with that (but I have to double check the W3C then). > >> >> 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. > > > yes, thank you. Glad you like the http;//www.pdb.org > <http://www.pdb.org> solution. > Anyway, that's what we have going with JmolApplet.js now. Exactly > that. Did you try > http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htm on your > smart phone? Yes, just right now. But it does only draw a static 3D image, right? Or should it be interactive, like rotation and zoom? And loading buttons don't do anything on my iPhone. > > > 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. > > > So for that to work, don't you have to hard-code into your page a > <noscript> tag? I guess anyone could do that if they cared to now as > well, with JmolApplet.js or with Jmol.js. I'm not seeing the > difference between jQuery and not jQuery on that one. So we could > recommend some sort of boilerplate for that, but that really isn't > relevant to this discussion, is it? Well, except maybe that with placeholder approach there is no need for <noscript> or we can use placeholder to signal problems with Java and <noscript> for disabled JavaScript messages. Like that: <div id="my-jmol"> <p>You do not have a Java installed</p> <noscript><p>And you do not have JavaScript enabled</p></noscript> </div> Anyway it might not be relevant here. > > Bob > -- Gusts Kaksis |
From: Robert H. <ha...@st...> - 2012-07-16 17:49:20
|
On Mon, Jul 16, 2012 at 11:31 AM, Gusts Kaksis <gus...@gm...>wrote: > Bob, > > I threw together a simple2.html with my approach (Jmol part only): > > http://dev.gusc.lv/code/jmol/simple2.html - it's on my devevelopment PC, > so it might be a wee bit slow. > > Please take a look at the html source and at simple2.js file. From my > point of view it's as simple as that, if you have any questions, I'll be > happy to answer them. > Did you try that in MSIE? When I click on Load MOL+MEP I get: LOG: there be error Not sure what to do with that.... > > Few things to remember: > 1. jQuery Jmol is still just a thin abstraction layer over Jmol applet, > everything else I've done in pure jQuery - like AJAX loaders etc. > 2. I haven't implemented the ChemDoodle yet. > Don't worry about ChemDoodle. The main issue on that page is getting it to load just an image and to hide all buttons when it is on a mobile device that has no Java or WebGL. > 3. I quite didn't understand the point of sending a commands from > JavaScript to Java, to prompt for the name of a molecule and then Java > (if I'm not mistaken) calls JavaScript back to get a structure through > AJAX. So I omitted that part and went straight to AJAX requests using > browser's prompt dialog. > I think you are mistaken there. All processing is within the applet, which in this case is signed. Maybe what you are seeing is that without XHR2 capability, the unsigned applet has to do an AJAX call to the server, but that should be trapped initially anyway. You sure that page works in browsers lacking XHR2? I doubt that. Bob -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Gusts K. <gus...@gm...> - 2012-07-16 18:11:13
|
On 2012.07.16. 20:49, Robert Hanson wrote: > > > On Mon, Jul 16, 2012 at 11:31 AM, Gusts Kaksis <gus...@gm... > <mailto:gus...@gm...>> wrote: > > Bob, > > I threw together a simple2.html with my approach (Jmol part only): > > http://dev.gusc.lv/code/jmol/simple2.html - it's on my > devevelopment PC, > so it might be a wee bit slow. > > Please take a look at the html source and at simple2.js file. From my > point of view it's as simple as that, if you have any questions, > I'll be > happy to answer them. > > > Did you try that in MSIE? When I click on Load MOL+MEP I get: > > LOG: there be error > > Not sure what to do with that.... It seems that IE block's prompt windows. And not only does it block them, it seems that IE submits it, after what the AJAX request gets malformed and it results in an error. That error comes from error callback in AJAX request. I'll try to fix it. > > > Few things to remember: > 1. jQuery Jmol is still just a thin abstraction layer over Jmol > applet, > everything else I've done in pure jQuery - like AJAX loaders etc. > 2. I haven't implemented the ChemDoodle yet. > > > Don't worry about ChemDoodle. > > The main issue on that page is getting it to load just an image and to > hide all buttons when it is on a mobile device that has no Java or WebGL. Aah, I see, that's why I got a static image on my iPhone, OK. > > > 3. I quite didn't understand the point of sending a commands from > JavaScript to Java, to prompt for the name of a molecule and then Java > (if I'm not mistaken) calls JavaScript back to get a structure through > AJAX. So I omitted that part and went straight to AJAX requests using > browser's prompt dialog. > > > I think you are mistaken there. All processing is within the applet, > which in this case is signed. Maybe what you are seeing is that > without XHR2 capability, the unsigned applet has to do an AJAX call to > the server, but that should be trapped initially anyway. Yes, my bad. I didn't know about smilesURLformat and loadFormat and what's the parameter for ":" syntax URL? Anyhow, the AJAX approach is also a good solution if for example, the user does not want to use signed applet. I think. Also you can track requests through developer toolbar in Chrome :) > > You sure that page works in browsers lacking XHR2? I doubt that. Yes, jQuery states they support IE 6+ and almost any other browser http://docs.jquery.com/Browser_Compatibility They had some tricky workaround using ActiveX, I think. > > Bob -- Gusts Kaksis |
From: Robert H. <ha...@st...> - 2012-07-16 18:55:26
|
On Mon, Jul 16, 2012 at 12:47 PM, Gusts Kaksis <gus...@gm...>wrote: > On 2012.07.16. 20:03, Robert Hanson wrote: > > >> > It's possible that it's no problem any longer. especially if you aren't > actually calling JavaScript in an href tag. So, for example, we try to > avoid this: > > > <a href="javascript:Jmol.script(jmol, "load \"my > file.xyz\"")">my file</a> > > Not on my watch :) > > i.e., you like that for some reason. More power to you, I guess. > > > I guess in this context that would become something like this: > > <a data-script="load "my file.xyz"">my file</a> > > Yes it looks more like that, but for loading I've come up with even better > solution: > > <a href="my file.xyz" class="jmol-load">my file</a> > And I just use the magic of jQuery's selectors to add this: > $('.jmol-load').click(function(e){ > e.preventDefault(); > $('#jmol').jmol('load "' + $(this).attr('href') + '"'); > }); > > This is the one solution, that gives user an opportunity to download a > file directly weather JavaScript is running (right click -> save as...) or > if it's disabled (default action of a link click). And you can even insert > an image in between <a> tags so that's a beautiful solution to degrade > gracefully. > I'm not seeing that. So when JavaScript is disabled, this reads: <a href="my file.xyz" ...>my file</a> I would still suggest that no one wants to "get the file" -- the value is not in the file, it's in the script. The file is just a bunch of atom positions and bonds (maybe; not in this case). If you have a file reader for xyz files, and you are interested in this app page, then you need the functionality of the page, not the file. Looking at the file itself -- just that -- except in the absolute simplest applications -- is not valuable. There would be absolutely no reason to have an image tag within the anchor. Unless you figure on replacing the innerHTML of that tag immediately with JavaScript. Is that the idea? > > I'm starting to think, that there should be at least two clear layers in > the API. One for the hard core developers, for example, just > jQuery.Jmol.js, for the ones that wish to do everything themselves, and the > second one should be fully featured library for seasonal developers or > complete amateurs. Last ones could use data-scriptid in conjunction with > something like Jmol.storeScript('myScript', 'load "some file.xyz"'), while > hardcore guys just go with the Jmol.bindLoader('.jmol-load') or just simply > use jQuery. > > Interesting point. So there would be a js that would somehow include a bit of jQuery, but nothing too sophisticated -- really no callback interpretation then, for example. [We don't refer to any of our users as amateurs. Very few are professional programmers, actually.] > By the way, what is Jmol spt file? It's Jmol's script file source, what > about the same use case as in my <a href="file.mol" class="jmol-load">Load > my file</a>, just with a prepared script file <a href="wireframe.spt" > class="jmol-load">Wireframe</a>. It creates a separate request to the > server, but it would really separate HTML even from Jmol's scripts. One > more option to think about. > > An spt file is a script file for Jmol. It runs from the SCRIPT command rather than the LOAD command. ".spt" there is not significant; it could have any extension. Jmol does not put any weight on file extensions except in very few circumstances. (If you use LOAD with a .spt, .png, .pngj, or .jmol file, it will switch to SCRIPT and use that instead, but that's about it.) > > >> 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. >> >> > I'm not finding support for that on the web. Depends on things like > namespaces and, for example, whether data-xxxx is in a dictionary, I think. > > Aah, you mean XML namespaces? Well HTML5 came with XHTML5, dropping the > attempt to create XHTML 2 as it was going in completely wrong way (I > wouldn't say that, but there were people who thought so). So there should > be no problems with that (but I have to double check the W3C then). > > If it validates, it validates. > > >> >> >> 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. >> > > yes, thank you. Glad you like the http;//www.pdb.org solution. > Anyway, that's what we have going with JmolApplet.js now. Exactly that. > Did you try http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htmon your smart phone? > > Yes, just right now. But it does only draw a static 3D image, right? Or > should it be interactive, like rotation and zoom? And loading buttons don't > do anything on my iPhone. > my bad. I forgot to implement server-side image generation from databases. Try it now. Bob Bob -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Robert H. <ha...@st...> - 2012-07-16 18:57:33
|
On Mon, Jul 16, 2012 at 1:11 PM, Gusts Kaksis <gus...@gm...>wrote: > On 2012.07.16. 20:49, Robert Hanson wrote: > > > > On Mon, Jul 16, 2012 at 11:31 AM, Gusts Kaksis <gus...@gm...>wrote: > >> Bob, >> >> I threw together a simple2.html with my approach (Jmol part only): >> >> http://dev.gusc.lv/code/jmol/simple2.html - it's on my devevelopment PC, >> so it might be a wee bit slow. >> >> Please take a look at the html source and at simple2.js file. From my >> point of view it's as simple as that, if you have any questions, I'll be >> happy to answer them. >> > > Did you try that in MSIE? When I click on Load MOL+MEP I get: > > LOG: there be error > > Not sure what to do with that.... > > It seems that IE block's prompt windows. And not only does it block them, > it seems that IE submits it, after what the AJAX request gets malformed and > it results in an error. That error comes from error callback in AJAX > request. I'll try to fix it. > > I think it's just that MSIE doesn't support XHR2. Right? (This was to explain why you can't just do that AJAX call.) You sure that page works in browsers lacking XHR2? I doubt that. Yes, jQuery states they support IE 6+ and almost any other browser > http://docs.jquery.com/Browser_Compatibility > They had some tricky workaround using ActiveX, I think. > > > sorry. It won't work in MSIE. > Bob > > > -- > 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 > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > > -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Gusts K. <gus...@gm...> - 2012-07-17 08:38:58
|
I found the problem with IE and XHR. Funny thing about Microsoft. They invent things, then they break them, and then they invent new ones, without fixing the old ones :) Same pattern goes for the XHR, which was invented by MS. Starting from IE 8 they have a new XHR object called XDomainRequest, because XMLHttpRequest had been restricted to same-domain policy. jQuery on the other hand has a great extensibility feature. So I found this plugin on GitHub, that silently replaces XMLHttpRequest with XDomainRequest on IE: https://github.com/dkastner/jquery.iecors Now my example page works with AJAX requests on IE8 too. As for XHR2 - it does not matter weather it's XHR level 1 or XHR level 2 (XHR2, which is still a working draft as I saw on W3C), because XHR2 just introduces file upload and other fancy web2.0 stuff. For simple AJAX requests XHR1 is enough and it works on MSIE3.0-10.0. -- Gusts Kaksis |
From: Gusts K. <gus...@gm...> - 2012-07-17 08:34:12
|
On 2012.07.16. 21:55, Robert Hanson wrote: > On Mon, Jul 16, 2012 at 12:47 PM, Gusts Kaksis <gus...@gm... > <mailto:gus...@gm...>> wrote: > > On 2012.07.16. 20 <tel:2012.07.16.%2020>:03, Robert Hanson wrote: >> >> >> >> It's possible that it's no problem any longer. especially if you >> aren't actually calling JavaScript in an href tag. So, for >> example, we try to avoid this: >> >> >> <a href="javascript:Jmol.script(jmol, "load \"my >> file.xyz\"")">my file</a> > Not on my watch :) > > > i.e., you like that for some reason. More power to you, I guess. I think that's why I like C language - it's a perfect balance between readability and power. :) > >> >> >> I guess in this context that would become something like this: >> >> <a data-script="load "my file.xyz"">my file</a> > Yes it looks more like that, but for loading I've come up with > even better solution: > > <a href="my file.xyz" class="jmol-load">my file</a> > And I just use the magic of jQuery's selectors to add this: > $('.jmol-load').click(function(e){ > e.preventDefault(); > $('#jmol').jmol('load "' + $(this).attr('href') + '"'); > }); > > This is the one solution, that gives user an opportunity to > download a file directly weather JavaScript is running (right > click -> save as...) or if it's disabled (default action of a link > click). And you can even insert an image in between <a> tags so > that's a beautiful solution to degrade gracefully. > > > I'm not seeing that. So when JavaScript is disabled, this reads: > > <a href="my file.xyz" ...>my file</a> > > I would still suggest that no one wants to "get the file" -- the value > is not in the file, it's in the script. The file is just a bunch of > atom positions and bonds (maybe; not in this case). If you have a file > reader for xyz files, and you are interested in this app page, then > you need the functionality of the page, not the file. Looking at the > file itself -- just that -- except in the absolute simplest > applications -- is not valuable. There would be absolutely no reason > to have an image tag within the anchor. Unless you figure on replacing > the innerHTML of that tag immediately with JavaScript. Is that the idea? No no, the idea is that internet is for sharing, and "bunch of atom positions and bonds" might be of value to somebody. So this is why I never restrict a default functionality to anybody. Same method is used for all those Lightbox image viewers, where you have a thumbnail which is wrapped within a link that points to original image - simple left click opens up a lightbox, but right click allows you to save the image on your computer. It's this thing of sharing and freedom of information I'm more into. Anyhow, I think it's one of those things that a developer should decide on his own site. > > > > > I'm starting to think, that there should be at least two clear > layers in the API. One for the hard core developers, for example, > just jQuery.Jmol.js, for the ones that wish to do everything > themselves, and the second one should be fully featured library > for seasonal developers or complete amateurs. Last ones could use > data-scriptid in conjunction with something like > Jmol.storeScript('myScript', 'load "some file.xyz"'), while > hardcore guys just go with the Jmol.bindLoader('.jmol-load') or > just simply use jQuery. > > > Interesting point. So there would be a js that would somehow include a > bit of jQuery, but nothing too sophisticated -- really no callback > interpretation then, for example. Yes, then I'd have to turn of my parser. And you didn't answer my question about output formatting. So I'll repeat it here: I'm more intereseted weather the syntax of hover's 1st parameter will allways be "atom atom_num x y z"? And what about those parameters of measurement? "Angle H #2 - C #1 - H #3 : 109.477165", 3, "measurePicked", 109.47716522216797 1st - a string representation of a mesurement 2nd - ? 3rd - action name? 4th - the angle as a float, right? I think it would be easier for a developer if thease values would be presented in a nice and documented structure, so that they can create whatever output they wish from it. > > [We don't refer to any of our users as amateurs. Very few are > professional programmers, actually.] Sorry, didn't mean to sound rude. :( > > > By the way, what is Jmol spt file? It's Jmol's script file source, > what about the same use case as in my <a href="file.mol" > class="jmol-load">Load my file</a>, just with a prepared script > file <a href="wireframe.spt" class="jmol-load">Wireframe</a>. It > creates a separate request to the server, but it would really > separate HTML even from Jmol's scripts. One more option to think > about. > > > An spt file is a script file for Jmol. It runs from the SCRIPT command > rather than the LOAD command. ".spt" there is not significant; it > could have any extension. Jmol does not put any weight on file > extensions except in very few circumstances. (If you use LOAD with a > .spt, .png, .pngj, or .jmol file, it will switch to SCRIPT and use > that instead, but that's about it.) Well, then for very complicated script I see a solution, right in that spt file. And why not? It's the same as a js file for the browser. > >>> 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. >> >> >> yes, thank you. Glad you like the http;//www.pdb.org >> <http://www.pdb.org> solution. >> Anyway, that's what we have going with JmolApplet.js now. Exactly >> that. Did you try >> http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htm on >> your smart phone? > Yes, just right now. But it does only draw a static 3D image, > right? Or should it be interactive, like rotation and zoom? And > loading buttons don't do anything on my iPhone. > > > my bad. I forgot to implement server-side image generation from > databases. Try it now. > Bob Now it works. > > Bob > -- Gusts Kaksis |
From: Robert H. <ha...@st...> - 2012-07-18 03:52:12
|
Comments below... > Yes, then I'd have to turn of my parser. And you didn't answer my question > about output formatting. So I'll repeat it here: > > I'm more intereseted weather the syntax of hover's 1st parameter will > allways be "atom atom_num x y z"? > > Sorry, thought I had answered that. It's totally up to the page designer. They can set the hover to just about anything, and there is a callback that lets them set it from JavaScript on the fly. > > And what about those parameters of measurement? > "Angle H #2 - C #1 - H #3 : 109.477165", 3, "measurePicked", > 109.47716522216797 > 1st - a string representation of a mesurement > 2nd - ? > 3rd - action name? > 4th - the angle as a float, right? > > Same deal. That's just the default. Honestly, I wouldn't touch it. It's in the category of "let the page developer decide what they want." > I think it would be easier for a developer if thease values would be > presented in a nice and documented structure, so that they can create > whatever output they wish from it. > > Pretty sure that's all discussed on the Jmol JsLibrary page referred to earlier. If not, that's an omission. Take a look at http://chemapps.stolaf.edu/jmol/docs/#setcallback and http://jmol.sourceforge.net/jslibrary/#jmolSetCallback > > Well, then for very complicated script I see a solution, right in that spt > file. And why not? It's the same as a js file for the browser. > Yes, that's what people do, provided it's a static script that is needed. But it's not always static. Sometimes the script itself is created dynamically depending upon events on the page. That's why we have the option for direct JavaScript function calls instead of actual scripts with all the controls: Jmol.jmolButton(jmol, [funcName, param1, params2, ....], "press me") for example. It think that's basically what you are implementing with your click events. In menus, how does jQuery handle use of the up/down arrows? One thing I can see useful with jQuery is that we often have use for form resets. Very annoying when a page is reloaded and the controls are not reset. Bob -- Robert M. Hanson Larson-Anderson Professor of Chemistry Chair, Chemistry Department St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |