views:

525

answers:

6

Hi all

We got a project where we're supposed to let 3rd party developers create their own GUI / CodeBehind drivers. Our GUI is running on WPF.

Now, we got a number of possibilities for doing so, but one of the things we're considering is to create some sort of sub-Xaml XSD to let the create their GUI using markup (dunno if it'll be XAML or our own XML-"language", and then let them do their code-behind through a scripting language.

I thought about it, and this model seems to have many similarities to the way World of Warcraft let's people create their own GUI. The way WoW does it, is by implementing the LUA scripting language and then expose some of their own API calls. We want similar behaviour.

However, we're on a sort-of strict deadline, and this implementation ain't the highest of our priorities. Therefore I'm looking for a .Net compliant script parser / "compiler", to use in our project. Which scripting language we're using is not a major concern, we just want to be able to implement it rather fast, without too much fuzz.

Does anyone know of this sort of library? Or do you guys have a smarter solution for these requirements?

Obviously, we're dreaming of creating our own WYSIWYG editor and our own domain specific language, but this seems like overkill for us. We just want a scripting language which can do nothing but to do calls though our API while letting the 3rd party developer use conditionals, loops, maybe OO, etc..

Thanks in advance :)

+3  A: 

have you looked at CSScript?

Brandon
Looks interesting, but we don't want people to be able to do stuff that aren't exposed by our API. Just looking at the frontpage they do a MessageBox.Show(), which is the kind of thing we want to avoid. We want to define which methods can be called (that they havent created on their own obviously), for example "OurApi.ShowMessageBox("Hello world");"
cwap
+11  A: 

You can use IronPython as your scripting language. Here's an article that gives a basic idea how you can do it.

Vadim
Seconded; no need to re-invent the wheel.
Marc Gravell
I've successfully used IronPython to embed Python scripting in an educational game I was involved with. It integrates well with c# and with a bit of coding you can restrain the api that is available to Python.
zarzych
Sounds like the best solution out of my head. I'll give it a bit more time before I accept it as the answer :) Can you use the DLR without .Net 4.0? I guess I have to use some "betaish" library?
cwap
You don't need .Net 4.0. The latest version of IronPython works fine with .NET 2.0.
Vadim
Oh, great. - but aren't the ScriptEngine, ScriptScope and the likes .Net 4.0 classes?
cwap
ScriptEngine and ScriptScope are part of Microsoft.Scripting.dll that comes with IronPython.
Vadim
Awesome. Thanks :)
cwap
+1  A: 

Have you considered creating a DSL in Boo?.

It doesn't have to be very hard and complex to get started, but you get excellent options for expanding the DSL if you get more time on your hands later on.

Mark Seemann
+3  A: 

Lua plus LuaInterface is the choice for our current project - just register methods from your API with LuaInterfcae and they can be called from script code. Our user interface uses Scintilla and ScintillaNET for script editors.

This is probably not the best solution for building complex user interfaces, but it is possible.

Daniel Brückner
+1  A: 

Antlr is a lexer/parser generator. It is a little more involved than just using Iron Python, however, you are able to create your own DSL fairly easily, allowing only the types of operations you want.

With the generated parser/lexer you can use it as a real time interpreted language, or a traditional statically compiled, or use it to generate C# code, which then gets compiled.

The options are quite endless.

Darien Ford
+1  A: 

I strongly agree. Inventing new general-purpose "script a bunch of control flow and object model invocations" language is "minus one thousand points" on my team; that is, the cost of doing so is so high, and the cost to our customers of having to learn a new language is so high, that the benefit has to be at least "a thousand points" just to get out of negative territory. There are plenty of scripty languages that you don't have to design, specify, develop, test, debug, document, ship, maintain and teach your customers how to use; you can avoid all those costs.

If I were in your shoes I would only be developing a new language if its value was that it was very different from every other language out there, due to its special-purpose applicability to a specific domain. It sounds like you are well on your way to developing a static markup DSL, which is a great idea. By making it a subset of an existing tag-structured language you don't have to take on the burdens of building parsers and lexical verifiers and whatnot.

Eric Lippert