E.L. Willighagen wrote:
I would like to do it, but could use some help...
If I, then I'll need some guidance. If YOU, what all do you need?
I understood that the website was created from a database? Is that correct?
If so, I 'need' access to that database, because it would be easier to format it to DocBook than to parse HTML
It is not a "database" in the sense that you think of it. It is an Excel file
that I use to create a set of .js files. These then form the "database" that
is loaded by the URL. It's all client side. I know this is NOT what people
generally think of when they think "database." But there is no "HTML" to parse here. If you do this right, all we would have are a few very small HTML files
to adapt. And one JS file, code.js, perhaps. (But that could also just be included in the html file.
2. What the heck is "DocBook XML"?
The file format we use, which easily can be converted into HTML and PDF. See: http://www.docbook.org/
I hope you're not suggesting taking all this content and recreating it in some completely other format. We're talking about something WAY different here.
3. How do you test this sort of thing before going live? (with all the [codebase] and such in there)
Would be easiest if we could convert the DB to the format in the script.docbook.xml file... then the build.xml will use it directly...
Please consider just having it be treated like a standard HTML file -- the way
you might treat Jmol-web/doc/source/index.html. You will save yourself an immense amount of time.
I'm not sure what [codebase] is... is that source level, or 'as is' on the webpage? or is that codebase as in applet?
I THINK [xxx] refers to placeholders that build.xml uses to adapt a page to the
actual final directory context. So, for example, we have in Jmol-web/doc/source/applet/index.xml:
<appletExample>
<![CDATA[<applet name="jmol" code="JmolApplet" archive="JmolApplet.jar"
codebase="[codebase]"
width="200" height="200" mayscript="true">
<param name="load" value="caffeine.xyz"/>
</applet>]]>
</appletExample>Then build.xml apparently directs whatever the build engine is to replace [codebase] with "../jmol":
<replace dir="${build.html}" includes="*/*.html">
<replacefilter token="[images]" value="../images" />
<replacefilter token="[root]" value=".." />
<replacefilter token="[codebase]" value="../jmol" />
</replace>Are we talking about the same process for "building" here? Or is the "docbook" business completely different. If different, I'll give you the Excel file, but you're on your own after that, because I really don't see this as a flat static
HTML content document. I'm probably misunderstanding what docbook is all about. Have a URL to an example?
6. Do we want the /examples subdirectory, or would it be better to have it all in one flat directory?
I think it would be best to exclude the example with the applets. Just the content of the front page would be fine... excellent, actually...
Oh, now I think that hurts. You saying you want to drop the examples completely? That's the whole key to it's usefulness in my mind. People really need to see examples.
Also, we can still point in the help to your page for 'more info'...
Might as well point to a section of the jmol site, not mine, right?
7. Anything besides [codebase] I need in there? (Some sort of header?)
Not sure what you mean here...
That's because I think we are seeing this from totally different angles -- I from the idea that it's basically a glorified index.xml page, you from the idea that it is a dumbed-down database. Sure you can't live with it being a glorified
index.xml page (as in jslibrary?)
I guess what I would say is that if you are really adamant about turning this
into an xml database (which I think is what docbook is), then just tell me what
format you want. I'll use the current stucture to write XML, and then you can
use that. I don't recommend playing with the Excel, and I don't recommend starting from scratch using the HTML output by the javascript as a guide either.
But it wouldn't be impossible for me to adapt the current JS to output XML instead of HTML. We would do this "preprocessing" once each time the documentation was updated. I had hoped we could avoid this and just have the basic format that is there now, but I'll understand if that isn't an option.
Let's talk maintenance. Right now, when the documentation changes, what I do is:
1) Enter new information in the Excel file. (copy at http://www.stolaf.edu/people/hansonr/jmol/docs/scripts.xls)
2) Copy out one or more of toks.js, defs.js, cmds.js, or exam.js (by hand -- I know, a macro could do this. I'm just lazy.)
3) upload the *.js files to the site.
What's your vision of maintenance?
Bob
-- 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
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
