In my last post I mentioned C3D Toolkit, our JavaScript-based demo application, and said I’d discuss it more in another post. Well, here it is :)
Those of you who are ACIS customers are probably familiar with acis3dt.exe – our Scheme-based demo application (which I’ll call A3DT). For those of you who aren’t, it’s an interactive application, written in the mid-90s, that lets you view and manipulate ACIS models by typing script commands (Scheme expressions). The view window provides mouse-driven picking and view manipulation, but anything you can do with the mouse can also be done through a Scheme expression. There is also a helper application which can be used to edit scripts and send them to A3DT (either entirely or line-by-line) for execution, or scripts can be run from the command line in “batch” mode (for testing).
A3DT has been VERY useful over the years for ACIS, in many ways:
And now, let’s fast-forward to when we began working on componentizing CGM. In CGM we didn’t have such a scripting engine – instead we had an in-house unit testing engine that could run unit test executables. If you think about it, this made perfect sense. CGM was not developed as a stand-alone product; instead it was part of a GUI-based feature modeling application. In other words, CATIA filled most of the roles for CGM that A3DT fills for ACIS.
For CGM component, however, this was not sufficient. We first noticed this when writing tests – we found ourselves trying to write unit test executables for tests that were really acceptance tests. This was extremely expensive in developer time – being able to see the models you’re creating and do graphical picks on them is extremely important when writing tests of even mildly complicated workflows (e.g. create a block then fillet one of the edges). A more technical way to think of this is that the overhead due to violations of Once and Only Once involved in setting up the input scenarios (which I’ve discussed in the context of design-by-contract) is prohibitively expensive.
A more important problem is that unit tests don’t use the code the way that our customers do: in an application. This is the heart of App Driven Development: you should try to use your own product in the way your customers will.
At the same time, our TAMs were used to having a demo application available for use in presenting our products to customers.
To address these problems, we developed the C3D Toolkit application. We chose JavaScript rather than Scheme as the scripting language, and we used a more modern application architecture and GUI, but at its heart C3D fills the same role as A3DT – an interactive GUI application that lets you play around with the modeler, while at the same time being able to capture complex workflows or demos in an executable script.
One of the things that surprised me (but probably shouldn’t have) in all this is how rarely people think about scripting interfaces in terms of supplying a command-line interface to applications. In our experience with A3DT (and now C3D), the primary utility is in the ability to sit in front of the application and interactively figure out, line-by-line, what you want to do, while capturing what you’ve figured out in a script. In contrast, it seems like most people think of the utility of scripting in terms of being able to write scripts that will be processed in “batch” mode; in other words it’s very similar to programming, except you don’t have to recompile the executable when you change (or extend) the program. I imagine that a lot of this is driven by the browser-based application market; in such applications the scripting language isn’t the actual interface that’s presented to the user; it’s simply an intermediate programming language that can be run on the browser. I think ignoring the potential of scripting as an interactive interface is a mistake – there are a lot of benefits to having a scripting “hook” into your application.
ACIS, 3DScript and SAT are registered trademarks of Spatial Corp.
No Comments Yet
Let us know what you think