In his reply to my long message Bob Hanson wrote:
I would recommend in all examples being explicit as to the name of
the Jmol applet referenced --- in other words, NOT ignoring optional
parameters. If more experienced users want to ignore the parameters,
all the power to them, but by having those applets explicitly
parameterized and user-named, the user (and reader) has more direct,
usable information, and the example will more likely work when on a
page with more than one applet present. (And learns more about the
flexibilities available.)
I'm not sure what you mean here. I thought that the Jmol.js handled
the applet tag parameters - I don't see the possibility of user
control here. What I do see - and perhaps this is what you meant -
that I omitted two of the arguments from the jmolCheckbox function
(actually three - I'd just written script instead of
'scriptWhenChecked' and 'scriptWhenUnchecked'). As an amateur Java
programmer with a dislike of scripting languages that allow this I
agree this was bad.Each instance of jmolCheckbox("script", "") should
read:
jmolCheckbox("scriptWhenChecked", "scriptWhenChecked", "", false, "cb0 etc")
Similarly, all forms should be named, and all divs should have "id"
tags. I know this is not necessary, but I believe that (a) well
thought-out names and ids provide handles for understanding the code
and (b) the presence of named elements makes for simpler integration
into larger projects.
Users should only have to rely on referencing "document.applets[0]"
or "document.forms[0]" when absolutely necessary.
I would only partly go along here. It is not required for validation,
but certainly good practice always to name forms. However you only
need to give ids to divs if you are going to manipulate them yourself
with Javascript, which is not what we the jmol javascript page is
about. It is certainly not normal practice in W3C-valid page layout
(unless a div has a unique css style associated with it - and
therefore it would be better as id="right" rather than class="right"
in my example) and would make the page more complex. I would argue
against making a big thing about this in the rewrite, but any rewrite
would presumably be kicked back and forth for this sort of thing to
be resolved.
David
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
