Miguel,
Vertical bars are great. No problem there.... In fact, that's precisely what I use in many web-based applications because | is a natural separator. Beginning of the line, end of the line--makes no matter to me. Probably looks nicer at the beginning of the line anyway.
I would much prefer it all be part of the parameters. You will run into exactly the same issue with line feeds if it is HTML, and that really (in my mind, anyway) runs contrary to the data/delivery separation idea. Also, it associates the data with the parameters in a clear fashion. If these two are separated, you will also need tags and some sort of parameter that points to the data block by name, as there could easily be a dozen instances of the applet and a dozen data sets on a page (in principle). From a reader's point of view, it will make far more sense to have all the information together, and from a programmatic point of view, scanning HTML text for data seems to me to be inelegant and possibly error-prone.
Bob
Miguel wrote:
Bob wrote:
Line endings are not an issue. In JavaScript I can produce the <embed> tag based on any convention you like. Certainly semicolons look good to me for line endings.
One would think that it would work to put semicolons at the end of the lines ... but it turns out that there are problems :-(
The HTML 4.01 spec says the following:
-------- http://www.w3.org/TR/html4/types.html#type-cdata
CDATA is a sequence of characters from the document character set and may include character entities. User agents should interpret attribute values as follows:
* Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space. --------
The fact that carriage returns get replace with spaces, and line feeds get *ignored* means that the final value one gets depends upon whether the file was edited with a Win32 editor.
Win32 systems use carriage return + linefeed. This means that if one puts a semicolon at the end of the line, it will get turned into a semicolon + a space.
Unix systems use only a linefeed. So a semicolon + linefeed will turn into a semicolon.
Therefore, we cannot put the semicolon at the end of the line.
I think it would work if we put it at the beginning of the line. The effect on Win32 files would be that there was an extra space added at the end of the previous line. I do not think that would generally be a problem with molecular model files.
So, I was thinking of the vertical bar character '|' at the *beginning* of a line to separate lines.
Q: Would it work for you to put '|' characters at the beginning of each line?
Personally, I don't like it. So I have tried to come up with another solution. I am thinking of this as an alternate mechanism for 'inline' molecular models.
Here is what I am thinking ... we do not store the molecular model in the parameter string value. Rather, we store the moleculare model inside the HTML file itself ... with some tag that identifies it as the molecular model. The applet reads its own HTML file and pulls out the molecular model.
The rough idea would be something like this:
[applet code='JmolApplet' ...] [param name='inline' value='my_molecular_model' /] [/applet]
<!-- [my_molecular_model] records go here [end] -->
I still need to think through the details of how this would be done.
It would probably work fine for .html files and pull the .html file from the local cache.
It would probably have problems on pages that are generated by cgi's because the applet would probably fetch the page again from the web server.
After writing this down ... I don't like the idea as much as I used to :-(
Q: thoughts/comments?
Yes, I'm certainly volunteering.
[snip]
I would be delighted to at least work out a simple sample page that would at least demonstrate some of these capabilities.
Get a rough draft of a page ready.
[snip]
I've also played around a bit with Java and applets, but that's not my forte at all.
It will be very helpful for me to have a JavaScript user.
Also extremely useful would be the capability for JavaScript to read the data for a currently displayed file using scripting. For example,
A=new Array() A=jmolapplet.getAtomCoordinates()
or
XYZ=new Array() XYZ=jmolapplet.getAtomCoordinates(3)
or setting them:
jmolapplet.setAtomCoordinates(3,XYZ)
or all at once:
jmolapplet.setAtomCoordinates(A)
Is there information somewhere regarding the interactions possible between jmol and JavaScript commands?
Your suggestions are good.
Currently, you should assume that the only thing you can do is run the document.jmol.script('some RasMol/Chime script')
In addition, the Chime callback functions are available.
The whole area of LiveConnect communciations between JavaScript and Java applets is a swamp that is murky, ugly, and buggy.
That is why I need people to work on it from the JavaScript side.
My hope/plan is to define a relatively clean interface that will allow JavaScript to query the status of the display. This would be a JavaBean API that would also be available to JavaScript ... that would allow one to inquire about the state of Jmol, including properties of the atoms.
Miguel
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
