JavaScript programming - resource notes
I’ve been working on a small project using JavaScript, and thought it would be worth recording some of the useful resources I’ve found:
- The Venkman JavaScript debugger is
a plugin for FireFox that allows you to single-step through scripts, set
breakpoints, inspect variables, etc. Slightly quirky at times, but works
pretty well. Much better than using lots of
alert()calls as print statements. - The web tools platform (WTP) project is a set of plugins for Eclipse that extend Eclipse to handle web content - (X)HTML, JavaScript, CSS, etc. The JavaScript editor includes syntax colouring, structured browsing, and name completion &emdash; but not validation as far as I can discover. The WTP plugins can be installed using the Eclipse automatic installer, which worked pretty well. Incidentally, the WTP HTML editor wasn’t very impressive, I use the Amateras html editor instead. However, the WTP does include a handy CSS editor, which again handles syntax colouring and completion.
- David Flanagan’s JavaScript: the definitive guide has been an invaluable companion. Highly recommended.
One of the things I’ve been using JavaScript for is client-side RDF handling.
For RDF parsing and basic query, I’ve been using Jim Ley’s JavaScript RDF
parser. It’s pretty basic, but functional.
Found one bug with namespace handling, which I’ve emailed to Jim. The triples
are not indexed in any way, so any moderate querying of the RDF model will get
pretty inefficient pretty quickly. However, a handy trick is to author compact
RDF, then use the Jena tools, if necessary with
custom rules, to generate the deductive closure of the base model, then save
that as a file. This makes explicit many of the relations that otherwise would
require query to traverse. Some caution needs to be used, since making the
source model too big would also be counter-productive for efficiency.
Incidentally, a useful side-effect of doing this is that saving the model in
RDF/XML format, not RDF/XML-ABBREV, means that rdf:parseType="Collection" is
re-written in first/rest/nil format … which is handy since Jim’s parser
doesn’t handle parseType Collection.