Making A Project Out Of The Blog and Ruby

Tue Apr 10 19:47:00 EDT 2012

Tags: xpages

Now that I have the blog in Domino and acting as an accelerating incubator for Ruby-in-XPages (man, I need a better name for that), I decided I may as well put 8.5.3's filesystem synching to good use and put the whole thing up on GitHub with everything else:

https://github.com/jesse-gallagher/frostillic.us-Blog

I've also started keeping a todo list in the README file there with my notes and future plans for the blog, the Ruby runtime, and a tentative "Misc" section.

As for the interpreter itself, it's been coming along nicely. I've got it so it only needs to create a ScriptingContainer once per request. It's not perfect, and ideally it'd only be one per Application or server - the LocalScriptingContext.CONCURRENT mode seems tailor made for this. As it is, I'm pleased that Domino can serve the HTML for the blog's home page in under 300ms, considering most scripting computation is done in an "alien" language. It's a simple app and it's not Basecamp 2 speed, but it's a start.

I have script libraries (of a sort) working. If you drop Ruby files into /WebContent/WEB-INF/ruby, you can reference them with familiar syntax:

<xp:script clientSide="false" src="/testlib.rb" type="text/x-ruby" />

Unfortunately, it doesn't yet pull in script libraries from themes (I think) and I don't know if it's available on beforePageLoad, but, again, it's a step in the right direction. Once I can get a hold of the AD103 slides from LS2012 or find similar information elsewhere, I'll look at surfacing them as a design element.

Commenter Photo

Nathan T. Freeman - Tue Apr 10 20:47:16 EDT 2012

First off, Jesse, congratulations on all this rapid success. I am REALLY DAMNED EXCITED that this is coming alone so quickly.

"I've got it so it only needs to create aScriptingContainer once per request. It's not perfect, and ideally it'd only be one per Application or server "

Is the ScriptingContainer serializable? If so, you might want to think about wrapping it in a component and attaching it to the XPages View root. That way, you'll just reuse the one between partial refresh calls

If you do this, then you have the chance to accomplish something that SSJS itself can't do: Retain closures between AJAX calls. I don't know Ruby well enough as a language to know whether that would be useful, but it's a sore spot for a number of XPages developers today.

By the way, I don't see a license on your Github projects. If they're Apache, I'd like to see if I can contribute!

Thanks.

Commenter Photo

Jesse Gallagher - Tue Apr 10 23:12:02 EDT 2012

Hmm, that's a good line of investigation. I don't think the runtime itself is Serializable (I think I ran into some trouble with it or a ScriptingContainer in a serialized scope), but there may still be options. I'll look into that when I sort out how I should be handling threaded-ness in the ScriptingContainers generally.

As for the license, that's a good point - I'll pick out one of the non-GPL free licenses and attach it to the project.

Commenter Photo

Tommy Valand - Wed Apr 11 02:45:57 EDT 2012

I agree with Nathan. This is some really exciting stuff!

A question: Since (it looks like) you're using the scripting language interpreter in Java. Is it easy for you to enable all the scripting languages that Java supports(Python/Jython, JavaScript/Rhino, etc), or would you have to write a wrapper for each language?

Commenter Photo

Jesse Gallagher - Wed Apr 11 08:53:53 EDT 2012

There'd have to be some language-specific implementation code (namely, instantiating the runtime and figuring out how to give it access to the surrounding variables), but the main "hook" should be a fairly reusable concept. One of my plans for this is to at least smooth the process for adding other languages, if not add them myself.

Commenter Photo

Jerry Glover - Thu Apr 12 13:50:49 EDT 2012

In terms of your project name, a simple acronym isn't bad:  RIX (Ruby in Xpages)

Though you might want to retain more of an allusion to Ruby and go with something like:  RuX

Which is also not bad, but once you're open to corrupted(extended?) acronyms you can get to something which, despite possibly leading to confusion as included in a family of operating systems, gets really fun:

RubiX (not to be confused with RubyX, a name already hijacked)

If for no other reason than once you rev a couple of versions you can dub it:  RubiX^3  - i.e.  RubiX Cubed

Smile

 

 

New Comment