-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 26 October 2004 16:44, Bob Hanson wrote: > 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.
IC... /me should get used to looking at HTML source again :) What does the Excel file look at? Also split into tokens, defs, and commands? > 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. Well, that's what I am suggesting... converting the JavaScript into DocBook... but *not* by hand! If I understood correctly, we should create an alternative code.js which does not create HTML but DocBook instead... I'll have a look at it next week... > >>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. Maybe... it's a good alternative, but I don't think adapting the code.js should be very difficult... > > 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: > > <DEFANGED_appletExample> > <![CDATA[<DEFANGED_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? No worries... I can do with the javascript files, I think... I'm away this weekend and have birthday tomorrow, so will 'do' it next week... > >>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? Well... from the Help in Jmol. Because we cannot run an applet inside the Jmol application anyway... And in that Help we refer to your website... The examples are great, and having them run from your site would give you some more credits than if in the Help only... BTW, what we can do later, is convert your examples into a 'in-Jmol-application' tutorial... or so, or run the examples directly in the application... mmm, I'll think about it how that could be best done. BTW2, just to make sure we are talking about the same thing. The examples I'm refering too are the files in jmol/docs/examples, not the examples on docs/index.html itself... > That's the whole key to it's usefulness in my mind. People > really need to see examples. Absolutely! The Help in Jmol is not supposed to *replace* your website! If you run the application, and do Help -> User Guide, there should be help on the scripting language... which you can also reach with the Help button in the script window... > > 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? Yes, the help could be migrated to the Jmol site... is that what you suggest? > >>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?) Oh yes I can... > 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. That would be great... then convering that to DocBook XML is peanuts for me... > 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. It's a very good option for webpages... but the HTML renderer that comes with the Java VM's don't do JavaScript... > 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? That would be just excellent! If you code make a code.js that would spit out XML, then that would be more than I could ask for! I'll make a XML 2 DocBook script (in XSLT) then, that will create the source we can use for the Jmol application... Egon - -- [EMAIL PROTECTED] GPG: 1024D/D6336BA6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBfplTd9R8I9Yza6YRAiKSAKCv7IygIxAx40k1qLg1OJS4/2WTdwCeMxuI VRbD76U6zpiESKG6H7ZmXLg= =pJhL -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
