From: Bob H. <ha...@st...> - 2005-09-23 14:18:57
|
Well, that demo shows several somewhat unrelated ideas. None of them are complicated, but all together they probably look complicated. The jist of it, though, is that if you add one line to any file you already have that has an applet in it and already uses Jmol.js -- the NEW version of Jmol.js, as at http://www.stolaf.edu/people/hansonr/jmol/docs/Jmol.js -- just this one line: <script type="text/javascript" src="http://fusion.stolaf.edu/chemistry/jmol/loaddata.js"> </script> Then you now have a) automatic access to any PDB file in the Protein Data Bank b) automatic local caching of PDB files. c) automatic local access to the data in JavaScript array format. So, then, if you on some button on your page indicate: retrieveModel("1crn") Pop -- in goes that model to your applet. or getModel() Pop -- up comes an input box asking the user to indicate what model they want. And it's all automatically cached, so if they load a different model and then come back to the first, it just instantly shows up. Try it on some page you already have and tell us how it works. For those who are JavaScript-savvy, (c) has HUGE potential. With it you could EASILY: a) combine two or more PDB or XYZ files into a larger multi-model set and display all together or alone for comparison purposes. b) parse header information and display pieces such as author, xtal structure, etc. in whatever format you like. c) do as Jeff suggested and display the sequence of amino acids and work with them in an interactive fashion. d) take a basic PDB file, change certain fields in certain ways (such as adding displayable "temperature" data, and then sending that modified version to the applet. This is basically "XML for anyone" without the XML overhead or current connectivity problems. What I mean by that is the delivery of data to a browser in a format that can be manipulated depending upon the designer's whim. PDB files, particularly, are so well structured that they can be parsed absolutely trivially into every subcomponent -- chains, groups, atoms, coordinates, charges, B-factors, etc. In fact, with a little adaptation of a poor-man's XML parser I just wrote, http://www.stolaf.edu/people/hansonr/jmol/docs/html2dom.js you could even read actual CML data this way and create whole molecular DATA structures in any standard browser -- bonding connectivity and all. (Or, for that matter, ANY XML data.) So, yes, if you want to get into it, it could be complicated. But actually, for general purposes, it couldn't be easier. Bob Philip Bays wrote: > Bob -- this is terrific!! I like the ability to move back and forth > between loaded molecules and manipulate them independently. > > However, at this point, as a novice, it all sounds complicated to do. > Even you note is beyond me :-( > > Phil > > On Sep 22, 2005, at 12:40 PM, Bob Hanson wrote: > >> I've written a demo page that demonstrates: >> >> * delivery of data dynamically from a server via a SCRIPT node >> * loading an applet with any file from any public server on the web >> * automatic local caching of entire molecules on the browser >> * use of the Jmol .loadInline() function >> * capture of messages to a div using .innerHTML >> * writing the applet only upon page loading >> >> see http://fusion.stolaf.edu/chemistry/jmol/loaddata.htm >> >> * delivery of data dynamically from a server via a SCRIPT node >> >> The radical(?) philosopy, consistent with the broad goals of >> distributed computing, is to use a server to deliver model files in >> the form of JavaScript arrays, so that client-side JavaScript can >> manipulate that data as necessary -- sending it to the applet, parsing >> it for information, displaying text, doing additional calculations, >> etc. This works because SCRIPT nodes, unlike FORM nodes, are not >> restricted to the "server sandbox" of the web page host. >> >> * loading an applet with any file from any public server on the web >> >> The ColdFusion server uses the cfhttp function to retrieve any model >> that might be on the web. The client-side JavaScript defines the >> default sources for the data, be they the PDB itself or some other >> website. >> >> * automatic local caching of entire molecules on the browser >> >> In addition, this page demonstrates the idea of caching model files on >> the browser, so that later requests to reload a model acts >> instantaneously, with zero server load. The server returns a >> JavaScript array, and that array is available anytime later for >> reloading without any interaction with the server. >> >> * use of the Jmol .loadInline() function >> >> This takes me back to my VERY first interaction with Miguel, when I >> requested that data might be introduced to the applet "in line" -- >> that is, as a string, rather than using the "load [filename]" script >> command. Here we see the power of that function, allowing us to get >> the data from a different source (the local cache or this special >> server) and then send it to the applet. >> >> * capture of messages to a div using .innerHTML >> >> Message callback is not implemented in Jmol.js. This page shows how, >> with a one-line function, you can add a message callback and still use >> "boilerplate" Jmol.js. These message callbacks go to a DIV instead of >> a TEXTAREA, giving them a nicer style and removing the problem of >> diminished performance with long scripts. >> >> * writing the applet only upon page loading >> >> Rather than employing script commands within the body of the page, >> loaddata.htm simply has <span> tags that identify the places where the >> applet, controls, and messages are to go. Then, upon page loading >> (using window.onload=function_name), a function is called that >> (a) initializes Jmol, (b) gets the applet HTML code, (c) adds the >> message callback, (d) gets the controls, and (e) adds them to the page >> using the .innerHTML function. >> >> In the end, what we have is a new way to organize a web page that >> utilizes the Jmol applet, and a new efficient way to load models into >> it from anywhere on the web. >> >> This file utilizes >> >> http://fusion.stolaf.edu/chemistry/jmol/loaddata.js >> >> --------- >> >> user functions include: >> >> getModel() starts the process with user input >> >> retrieveModel() starts the process without user input >> >> loadModel() called BY the server ON the client >> >> showModelText() opens new window with model text >> >> openWindowText() writes text to a new window >> >> --------- >> >> to use: >> >> >> just add a script with >> src="http://fusion.stolaf.edu/chemistry/jmol/loaddata.js" >> (or the equivalent) to your web page. Include an applet on your page >> along with links such as the following: >> >> <a href="javascript:getModel()">load a molecule</a> >> <a href="javascript:retrieveModel('1crn')">1crn</a> >> <a href="javascript:loadModel()">(reload)</a> >> <a href="javascript:showModelText()">(text)</a> >> >> In addition, you will need site copies of Jmol jar files and Jmol.js. >> >> --------- >> >> how it works: >> >> a) getModel() requests user input and then calls retrieveModel(), >> which adds a SCRIPT "node" to the DOM (Document Object Model) tree at >> the end of the HEAD section. (The DOM tree is the internal >> representation of the web page within the browser.) This action sends >> a message to the fusion.stolaf.edu server, passing to a ColdFusion >> file the URL of the model. The server gets the model from wherever it >> might be on the web and returns it AS A JAVASCRIPT ARRAY along with >> the command "loadModel()". The loadModel() function runs IN THE >> BROWSER, combines the array back into a string, and fires the applet's >> loadInline() function with the model data as a parameter. >> >> As a bonus, the model is cached in the browser as a JavaScript array. >> So additional calls to load this particular model never need to go to >> the server. >> >> >> -Bob Hanson >> -- >> >> Robert M. Hanson, ha...@st... <mailto:ha...@st...>, >> 507-646-3107 >> Professor of Chemistry, St. Olaf College >> 1520 St. Olaf Ave., Northfield, MN 55057 >> mailto:ha...@st... >> http://www.stolaf.edu/people/hansonr >> >> "Imagination is more important than knowledge." - Albert Einstein >> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: >> Tame your development challenges with Apache's Geronimo App Server. >> Download >> it for free - -and be entered to win a 42" plasma tv or your very own >> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >> _______________________________________________ >> Jmol-users mailing list >> Jmo...@li... <mailto:Jmo...@li...> >> https://lists.sourceforge.net/lists/listinfo/jmol-users >> > > J. Philip Bays > > Professor of Chemistry > > Science Hall 158 > > Saint Mary's College > > Notre Dame IN 46556 > > (574) 284-4663 > > -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |