Customization with scripting for DNG

Client side scripting is coming to DOORS Next Generation.  If you go to the jazz.net downloads you can get an early release candidate of version 4.0.5 which has a technology preview of client side scripting.  This is not a fully comprehensive feature yet, but this is a good start.

The API documentation is here and some technical details of how to set things up here.  Bear in mind that this is a developer preview, so the API might change, support is limited and this shouldn’t be used on production environments.  Still, no reason not to get excited about the potential…

The basics:

• What is provided allows you to create an OpenSocial gadget in the MiniDashboard.  You can also manipulate data.
• You can’t just create code like you did in DXL, you have to store it somewhere where it has a web server to dish it up to DNG, but anywhere will do so long as it is accessible by a URL.  This gives options of reusable gadget repositories.
• You need JavaScript skills
• You can re-use chunks of JavaScript from the bottomless source that is the internet and just stitch it together with a few lines of bespoke code
• You can use your browser as a half-decent debugger

Mini Dashboard pops out of the left hand side of the browser when you touch those four colored squares

Potential uses:

• Visualization – graph the data from the module you are viewing
• Attribute checking – for example where several attributes combine to give a level of risk or cost that is calculable by formula, check and report errors.
• Attribute setting – for the above example, use the code to set the values
• Process management – manage transitions of a status attribute by only setting it through the gadget – not an ideal mechanism because it can be defeated by anyone who doesn’t install the gadget on their mini dashboard, but it might work for agile teams.
• Create or delete links – although I don’t have a situation in mind where that wouldn’t be better done in the standard user interface.

Dangers:

• I have the same issue with this as I had with DXL, it is great but there is potential for it to be overused.
• Any code that hits a production environment should be properly tested, written to coding standards and configuration controlled
• Any code in place when there is an upgrade needs to be regression tested to ensure that it is still working properly.  Too often I have seen DXL code find its way into a DOORS Classic environment and then cause problems because it was ill thought out, or improperly tested.
• There will be some grumpy DXL experts because they will have to learn JavaScript if they choose to migrate their projects.  I have yet to learn any JavaScript so I can be counted in there, not really grumpy, but certainly in need of more learning.
• ‘Everyone’ under a certain age can write JavaScript, regardless of their level of understanding of the underlying database or of requirements management practice. So maybe that is a bit extreme, but there is a danger of people leaping in without a proper understanding.

I don’t have any javascript skills, so that is a project for me before I can start making use of this.  Today I specified a script that I wanted for a customer demo and a tame expert turned it around in a couple of hours.  It implemented a state machine on an attribute with a pretty UI.  As with DXL, I don’t want to be the go-to person for scripting, I just want to be able to get by, to be able to put together something relatively simple but very useful.