Shape scripts have been around for a while now. It is time for a major update
Probably Roy has more urgent things to see to, but I think before they update the shape scripting engine, they should bring the shape script documentation up to date and add some none-trivial samples.
Anyway, it's no major concern of mine. I'm using it as rarely as possible cause I don't like these Neanderthal macro languages. Gimme an OnPaint event in the API, and maybe I'll use it.
Just my personal opinion of course. Or not even opinion really, just my personal preference. I just won't use shape scripts, MDA transformation templates or code generation templates if it can be avoided at all. I even try to avoid the automation interface, cause moving lots of data from there isn't much fun either.
The only Neanderthal language I frequently use is XSL 1. It's an awful language too, but it's one language for almost everything. And the main advantage is that all the information is there when you transform the xmi file. Whereas all the inbuilt EA languages have gaps when it comes to retrieving information. The API won't give you tagged values for parameters, shape scripting will allow no loops, and god knows what is missing in the code generation and MDA transformation template languages.
So I'm generating code from XMI as well as data (like some simple state machine stuff, e.g. screen transitions in an SDI application). Next thing I'm planning is to create DB scripts, so I can overcome the limitations of what EA offers there. And if the powers that be ever want to have reports transcending the standard templates, I'll transform XMI to HTML. Or hire someone who does.
As for MDA transformations, if the need ever arises I'll write a template to simply call an AddIn method. And an AddIn method to export to xmi, transform by xsl and import back.
So my top priority for EA bug fixing is on XMI 2.1 exports (I don't want to waste my time analysing the structure of obsolete stuff like XMI 1.3 or whatever they use for version control due to lack of reliable XMI 2 serialization). However there's been something in almost every build recently, so I'm hoping for the best.
And one more reason for using XSL: if the worst happens and Sparx goes busted, I can use some other tool (like Poseidon or Visual Paradigm, which aren't so bad either) and do my transformations with just some minor changes (like accessing stereotypes or navigability of associations, where I had to use the extensions section). Once burnt, twice shy. It happened to us years ago when we built an application around an OLAP control which turned out to be full of subtle bugs. After a year of answering bug reports the vendor eventually announced that the control was not supported (let alone developed further) anymore because the developer who had written the code had left the company and was out of reach.
All in all my philosophy is keeping vendor dependency to a minimum and using common standards where ever possible. No offense meant to Sparx of course, and I wish them a long life, but I like to be on the safe side. EA has helped a lot to improve our productivity (much more than Rose, which we had in times of Visual Basic 6), and it sort of has become our daily bread and butter. But I wouldn't be comfortable if we were relying too heavily on EA alone.
Ok, I've been digressing. Just some thoughts I wanted to get off my chest.
