I wanted to do a quick post on why I chose Ruby for RPoint. I talked about this a little in the first post but just looking at the examples I’ve given so far, one could make the argument that rather than creating these scripts in ruby, you could just create a simple XML document that defines your structure, templates, etc.
This is very true - and in fact I have written tools like this in the past. But here’s the problem I’ve encountered with XML. You end up trying to build a programming language out of XML. That’s basically where CAML has ended up. And I don’t know a single person who actually enjoys looking at, much less creating, CAML.
Here’s what I like about the ruby approach. It let’s you write something like this:
site_names = ["Site One", "Site Two", "Site Three"]
at "http://localhost" do
site_names.each do |name|
create_web name, TeamSite
end
end
Just the simple addition of an array of site names is something that would be hard to do in XML. What if you wanted to pull your information from a database? Or a file system? Or an Excel spreadsheet? For any of those you would have to write more logic into your XML mini-language - constructs like looping, conditionals, some mechanism to handle plug-ins for additional logic, etc. By leveraging an actual programming language, we get all of that for free.
Want to create 50 test sites? Here you go.
at "http://localhost" do
50.times do |i|
create_web "Site #{i}", BlankSite
end
end
’nuff said.
Clint Simon | 12-Aug-08 at 9:46 am | Permalink
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.
glenc | 12-Aug-08 at 9:59 am | Permalink
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.
Clint Simon | 12-Aug-08 at 10:45 am | Permalink
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.
glenc | 12-Aug-08 at 10:57 am | Permalink
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.