In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
object). Some menu items are more complex, but usually range from one to two lines. Again, very easy to define a menu item definition capability. But an expert is often happier to use the command language.
Ah yes, there's another gotcha. Command language, data expression, GUI generation language, macro language. We've seen that the GUI generation language is very high level. So is the data expression language. And the macro language is quite capable. There are over 100 commands - some configure options, some bring up displays, graphs and tables. Some do basic CM operations. Others do basic database operations.
In CM+ you can do a lot of customization without learning the "languages". But there's a lot more you can do if you learn them, and you can generally do it faster. So what CM+ does is to allow you to interactively use these languages so that you see instant results. Type in: note ?<Stream>Stream. You'll see a panel pop up with a stream selector. Add a ?/products/Product, and a Product selector appears as well. Put a comma after the second ? (called a prompt character) and it appears on the same line. This is definitely a fun way to learn. And you can gradually build up your repertoire. Now when you see a command, you specify a prompt in place of each parameter, and all of a sudden the command has a full GUI. Use macros to combine commands or to help you specify default values for your prompts. Then use the prompts which require data expressions: a graph, a table, a display panel, a reference list selection, etc.
The point is not to extoll the virtues of CM+. It's to point out that when you define languages that can work together, you get a lot more than the sum of the languages. A prompt can query the current stream context and use it as a default value. In fact, it will automatically do this for you unless you override. It will also remember what you previously selected and use that as a default. The data expression language can be used with the macro language to extract data from the repository to use as a default. Or a data expression can be used to specify what you want in a pick list. This ramps up the power of customization dramatically. Add in the capability to save often used prompt snippets and you've got a great, concise dashboard specification language.
Customization capabilities must be a key part of a next generation ALM tool. And although nice GUI panels might be an easy way to perform common customizations, it will not take you nearly as far as you can go as by having a nice set of orthogonal language components that can interwork. Yes, GUI panels don't require a lot of training (so anyone can do the basic customizations in CM+, such as inserting a field, adding a state or transition, or even creating a menu item. But a simple and very high level language capability for defining/using macros, GUI prompts, and data expressions will give you full flexibility. Why not use Perl and TCL? Because they are not integrated. You have to do programming to get the integration. Take one of the dashboard examples above. How long do you think it would take to convert that to a Perl/TCL combination? A few minutes or a few hours to days? Now write a dozen dashboards. A day or a month? Now pass the scripting on to someone else to maintain. Which would they prefer?
Process means a lot of things.