Comments on: RPoint - Why Ruby? What about XML?

By: glenc

glenc — Tue, 12 Aug 2008 18:57:39 +0000

Honestly, I never really considered powershell as an option. I’ve done some powershell scripting and frankly I really don’t like the syntax. So I’ve decided against it partially for aesthetic reasons. This may turn out to be a bad decision, but we’ll see. I agree that using IronRuby is going to limit the audience and that powershell might make for quicker user adoption. IronRuby will probably take a while to be an accepted component installed on production sharepoint servers - so that may be an issue as well.

Before IronRuby I did some work with IronPython. Python’s a great language as well and IronPython is a lot farther along than IronRuby is. I would not install IronRuby on a production sharepoint server today, but I would consider installing IronPython.

In the end I’ve been really inspired by Ruby on Rails as a DSL for creating web applications, and RSpec as a DSL for unit testing. I think this is possible for SharePoint as well and I think ruby has the best chance of making this a reality.

By: Clint Simon

Clint Simon — Tue, 12 Aug 2008 18:45:47 +0000

I’m down. I have written lots of stsadm commands to do these things and it would be nice to have a simple script language to get this done.

In particular simple content patching from scripting would be great. Adding fields, content types, page layouts, etc.

Have thought of using PowerShell for this? IronRuby may be more elegant but powershell would be more accessible for people on windows.

Rock on.

By: glenc

glenc — Tue, 12 Aug 2008 17:59:46 +0000

Good input. I think I’m still working out exactly where RPoint fits. I wouldn’t say it’s generating test content although most of my examples might indicate that. I think in the short term I would say RPoint enables easy “SharePoint Scripting”. For example, adding a new list to all sites in my site structure, drop a web part on a page, apply a theme, etc.

My long term goal is that RPoint becomes the language that you use to describe your sharepoint solution. I describe my lists, sites, templates, etc. And from that I can either generate the site directly or output a feature or wsp or something like that.

By: Clint Simon

Clint Simon — Tue, 12 Aug 2008 17:46:29 +0000

Hey Glen, good points. I think maybe XML provisioning solves a different problem that you are not as interested in.

One of the best things about provisioning XML definition is that it can be a netural format for content transport. What I mean is that you could have an XML set of test data in your project and provision sites based on that definition for development. As the application matures, you will no doubt have content being produced in production and your test data will be out of date and stale. At this point you could then export a all or a subset of the production content to the provision XML. This XML is fed back into the project such that you now have a more relavent set of test data.

I think this is a different situation than you are solving. It seems that you are more interested in generating generic test content. For me, this is usually important at the start of a project and not necessarily in the middle or at the end.

I do not and would not use XML as a replacement for writing code. Programming constructs are for programming not XML. (except for NANT, but that’s a different story)

For me the answer is use the right tool. To solve automated test content, that tool is script or compiled code. For netural content transport it’s XML.