Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: DXL Script Library
Topic Summary: Create own script organization library
Created On: 15-Jun-2007 20:38
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 15-Jun-2007 20:38
User is offline View Users Profile Print this message


Mike Gehringer

Posts: 2
Joined: 31-Aug-2006

To all,

Curious is anyone has built or developed an organizational structure for their DXL scripts.  Or perhaps a listing of groups into which scripts can be placed so as to organize them.

For example, User Management, Attribute Management, Module Management...etc.

Or maybe a module to collect scripts and provide a means to further describe what the script does or can do.

Any help or thoughts would be appreciated.

Mike G>
Report this to a Moderator Report this to a Moderator
 18-Jun-2007 16:54
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

You may recall that in order for a DXL script to appear in a Menu, it has to have a single comment line and also a comment block. Once in the menu ..err.. once in the module addins menu, these scripts' comment line and comment block appear in the 'dxl library' viewable from modules. Thus, putting useful info in these allows the DOORS user to see a summary of the script.

// HistReport.dxl v2.3 - Make report of History in the Module
/* (Deploy: All; Projects: All; Context: Current Module; Modifications: None; Users: All)
HistReport.dxl searches for and reports History in the current Module. The report must be have standard formatting applied as per [Format Help]. Each qualifying History takes up one row in the report. The
date, user, context, etc is reports.

Only History in the current module is searched, History in baselines is ignored.

The user can restrict which History is reported, such as ignoring all non-Main column history.

See sibling script HistObjReport.dxl to get detailed history of the current object; which does reach
back through Baselines.
*/

By convention, I use the comment block to announce the DXL name and a phrase stating what it does. I use the comment block to specify more details about what it does and when a user may want to run the script. Almost all of my scripts have a dialog with a help menu, which I use to explain how to run the script, which usually means what the dialog options do.

My 'Project' scripts originally had the current project as context, but almost all my new ones have the current folder as context. I should change my references to 'Project' to 'Folder'.

My basic DXL scripts are either 'Module' (require a current module) or 'Project' (don't require a current mdoule) scripts. Scripts that are written for a particular program are grouped into their own menu and folks can add or ignore them as they see fit.

I put both Module and Project scripts in the module menu, but only the Project scripts in the explorer. My Project scripts have these sub-menus:
>> DB Admin - Make changes to DB level things (like triggers)
>> DB Reports - Reports of DB level things (like users)
>> Proj Actions - Save or Close open modules
>> Proj Admin - make changes to project or folder things (like adding attrs to many modules)
>> Proj Reports - Reports
>> Non-DOORS Chores - Misc tools that don't have anything to do with DOORS, like File Compare.
I'm too lazy to learn Visual Basic so write these things in DXL.

My Module scripts have these sub-menues:
>> Mod Admin - Make admin changes to module, like setting up shared sections
>> Mod Display - change display state of module
>> Mod Filters - Veriety of filters
>> Mod Import - scripts intended to tweak module after importing
>> Mod Misc - Misc, like changing open mode
>> Mod Modify - make non-Admin changes to module.
>> Mod Reports - Make reports of the module

I wonder if my 'module' scripts should have two more sub-menus, Obj-Modifications and Obj-Reports.

- Louie
Report this to a Moderator Report this to a Moderator
 28-Jun-2007 02:19
User is offline View Users Profile Print this message


Mike Gehringer

Posts: 2
Joined: 31-Aug-2006

Thanks Louie....I know about the way the comments feed the DXL Library but content within those comments is free form...your methods in implementing it were what I was interested in...so thanks for the detail...some further questions...

have you ever had the need to document this library organization process that you follow...so that others could follow it or use it in their script writing?

what about specifying the attributes that might be used by the script either as a source of data or as a destination?  have you ever thought to add that information?

have you ever needed to have different libraries for different types of users, for example, admins versus standard users?  have you ever seen a best practice for managing scripts?

  Thanks for the help and looking forward to more...

Mike G>
Report this to a Moderator Report this to a Moderator
 28-Jun-2007 22:38
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

If the script modifies an attribute that's routinely mentioned in the initial comments. If the script primarily uses a particular attribute in its processing then that's mentioned. No, I don't bother mentioning all attribute values used.

I separate out the 'database admin' scripts from the other scripts and protect them from casual execution, but anybody with double-digit IQ could edit the DXL and strip out the protection. I've toyed with the notion of contolling which users have the rights to even Read an addins sub-folder on the network, such that normal users cannot see the admin folder and cannot see nor run the scripts. I've toyed with the notion of having mutiple deployment schemes, perhaps 'Standard Addins', 'Project Addins', and 'Database Addins' and allow folks to decide which they want to see.

I've reached the limit of my ability to manage my scripts. I've got 2.3mb if deployed scripts and another 10mb or so of temporary, undeployable, or in-progress scripts. I figure I've written 2.5mb is scripts in the last 12 months. I need to step back and punt, gettting this stuff into some config management tool.

- Louie
Report this to a Moderator Report this to a Moderator
 4-Jul-2007 14:45
User is offline View Users Profile Print this message


Graham Stradling

Posts: 67
Joined: 19-Sep-2002

We have a pretty extensive menu of tools, arranged into items such as admin, power, edit, link and trace, etc etc. These are deployed in two menus, one is general and one is organisation specific for a small group of users. Some of the scripts, such as the admin ones have a little wrapper that checks current user is in a specific user group before allowing execution.

Code in stored in Visual Source Safe - not the best code app, but ok.

We deploy DOORS via Citrix so code is on our Citrix servers. before Citrix we had code deployed in a doors module that is opened via a trigger and a menu constructed...

-------------------------
Graham Stradling,

Alcatel-Lucent.

Edited: 4-Jul-2007 at 14:46 by Graham Stradling
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 2 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 2 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.