W3C home > Mailing lists > Public > spec-prod@w3.org > April to June 2010

Re: ReSpec 2 repository is up

From: Robin Berjon <robin@berjon.com>
Date: Wed, 5 May 2010 17:41:11 +0200
Cc: Spec Prod <spec-prod@w3.org>
Message-Id: <6CDAE8D7-34D5-4BBE-BFD4-90D0A788B5A2@berjon.com>
To: Gregg Kellogg <gregg@kellogg-assoc.com>
On May 5, 2010, at 17:06 , Gregg Kellogg wrote:
> On May 5, 2010, at 3:39 AM, Robin Berjon wrote:
>> I'm glad to hear that you could use it easily. Note though that I wouldn't recommend using it right now, even though the syntax of the content will be 100% compatible with v1, the code is still in flux and may break randomly!
> I do expect to have to re-sync to keep up-to-date, but that's the beauty of this system, that the document contains a single reference to the ReSpec library. I haven't tested the ability to have my own plugins be remote; right now, it  just works off of a copy of the library directory layout. It's certainly in good enough shape for us to begin work creating docs with.

Remote plugins are on the feature list (or at least, in my brain) but I haven't tested whether it works or done anything about it.

It's built atop RequireJS so if you list a module that ends with ".js" it shouldn't go through the locator mechanism but rather load it directly from that source. I haven't tried but putting a URI in there /should/ just work.

I have been thinking about adding a configuration option that would look like this:

  pathsMatch: [
      { match: "^dahut-", uri: "http://unicorns.org/js/%s.js" }

But I'm as yet undecided as to whether it's the right syntax, and whether I should bake that into ReSpec2 or go to the trouble of adding it to RequireJS. Thoughts welcome.

>> If it's stuff you can show, I'd be curious to see what you did. Also, note that I don't know when you took your snapshot, but I changed the templating engine from Simplate to the JS version of Template Toolkit.
> It was still the Simplate version.

Tell me how it goes but I think you'll like the TT version better. The syntax is more readable, there's good tooling support including syntax highlighters and code completion for editors (well, at least for TextMate but I suspect others), good online documentation, etc. Bonus plus: you can use the double-quote (") character in your templates without risking blowing up :)

That being said, Simplate is still there if you want to use it; just not loaded (and don't complain about bugs!).

> Don't have them online to view right now, but I added the to the bottom of this email. Note that cme-headers.html and headers.js just a minimal change from W3C right now; our document process is pretty different. For example, we haven't yet defined when the equivalent of FPWD happens.

Thanks! It's cool to see that you could reuse it. Note that one of the things that I think it useful in v2 is that configuration options are defined by the plugins. So essentially, you don't at all have to map your process somehow to W3C's to match the specStatus configuration defined by w3c-headers. If for instance your process is based on levels of unicorn-ness ("pony", "shepazu", "unicorn", "flying unicorn", "dahunicorn") you can just make it up in your own cme-headers and not worry about the other one. I would just recommend that you prefix it (e.g. "cmeSpecStatus") so as to be sure a core or w3c plugin doesn't take it over later.

Robin Berjon - http://berjon.com/
Received on Wednesday, 5 May 2010 15:41:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:15 UTC