I want to send all possible attributes of a DOORS module, which is quite large. How can I easily send my colleague all attributes of the DOORS module, so that he can tell which attributes he wants to be exported to him?
I'm looking for an out-of-the-box solution, which does not require an DXL script or something complex. I just don't want to send a bunch of screenshots to my colleague, as there are really plenty of attributes.
I think the simplest solution would indeed be a DXL script that prints all attributes. It's not even complicated, it only depends on which information you want to give to your colleague. If you only need the name of the attributes, open the module, start Tools->Edit DXL (from the Module explorer, not the database explorer!) and paste the following.
AttrDef ad
print "object specific attributes:\n"
for ad in current Module do { if (ad.object) {print ad.name ","}}
print "\n\n"
print "module specific attributes: \n"
for ad in current Module do { if (ad.module) {print ad.name ","}}
print "\n\n"
Depending on your needs you might want to change the condition to if (ad.object and !ad.system), which will filter out all variables that DOORS provides per default, like Created By, TableCellWidth etc. Also, you might want to print out additional information like ad.typeName (the type of the attribute) or ad.description.
Related
my question is quite the same as this one :
How to Iterate over target objects of outgoing links in DXL, in Modules not previously loaded
but regarding incoming links.
I would like to use the source objects of incoming links but there are located in module that are not previsously loaded.
I don't want to open and close module each time because it would cost too much time. I would like to open them once and close them at the end.
Two solution for this :
be able to know if the module is already open or not so that I don't open it again (is there a "is_open" function in DXL + store the list of open module in a table and close them all at the end.
or better :
before start of loop, use a loop using the link module and the target module to find all module in the database that could be linked to the target module. And I load them all (even if there is no links between them. But my script would be simpler this way). How can I do this ? I tried something like :
ModName_ src_mod_linkset
for src_mod_linkset in "target_module"<-"linkmodulename" do
{
print "test"
}
but in this kind of loop, it doesn't work because "target_module" should be an object and not the complete module.
https://www.ibm.com/mysupport/s/forumshome has a lot of information on this. A query "Engineering Requirements Management DOORS" incoming links brings you some example scripts. I prefer this approach (load the ModuleVersion if its data is null): https://www.ibm.com/mysupport/s/forumsquestion?language=de&id=0D50z00006HIDztCAH
About "is_open": there is a loop for module in database, which gives you a list of all open modules. You might want to store all open modules at the star of your script in a Skip list and when iterating over the incoming modules check to see whether you have to close the module at the end of your script.
I would not use your second approach if you plan to run your script on baselines, it might happen that the link set in the link module has been deleted in the meantime, so you will not get all possible in links. Anyway, the link modules could be anywhere in your database, not necessarily near your incoming module.
Background
I am trying to search for specific a specific string of text that I know exists in multiple modules. However, I forget all the modules that contain this text.
Question
Does DOORS have a global search function? That is, can it search for text that exists in multiple modules as opposed to the current selected module?
Tools->Find.
Though this only looks in Object Text and Object Heading of each module.
Also, there is a "global search utility tool" available at https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014289994
Note that the last lines of the script have been garbled. The script must end like this:
if (fillModsList(GSUModList) == 0) {
insert(GSUModList, 0, "(No modules)")
}
show GSUBox, "(No modules)"
I have been given the task of creating a DXL script. First problem is that I have never used DXL before, even though I have many years experience with DOORS itself. I have been surfing the Net to seek guidance on my particular problem. I also have a few specimen DXL scripts for reference.
My new client requires that for each View of a given Module, of which there are many Views, new "reduced" Modules are to be produced reflecting each View.
By "reduced", I mean that these new Modules are to contain nothing that isn't actually needed for that View., i.e. Columns, Attributes etc. These new Modules will only have the single View.
So, the way forward as I see it, is to take copies of the single master Module, one for each View, rename those copies to reflect a given Master Module/Required View, select that required View in the given copy Module and then delete everything that is not needed by that View, i.e. available Columns, Attributes etc.
This would be simple if I had the required DXL knowledge, which I am endeavouring to pick up as fast as I can.
If at all possible, this script has to be generic and be able to work upon any of the master Module copies to produce the associated "reduced" Module reflecting a particular View.
The client aims to use the script periodically for View archiving (I know, that's the way they want it).
Clarification
Some clarification of what I believe is required, given the following text from my original question:
If at all possible, this script has to be generic and be able to work upon any of the master Module copies to produce the associated "reduced" Module reflecting a particular View.
So, say there are ten views of the master Module, outside of the DXL script, I would copy the master Module ten times, renaming each copy to reflect each of the ten views. Unless you know different, each of those ten copies will reflect the same “Absolute Number”s as are in the master Module, so no problem there?
So, starting with the first of the copied Modules, each named to reflect the View it will eventually represent, its View would be set from the ten Views available to it, that which matches its title.
The single generic DXL script would then be run against that first copy Module, the aim being to delete everything not actually needed for that view, i.e. Attributes, Columns etc. Would some kind of purging command be required in the script for any aforementioned deleted items?
The single generic DXL script would then delete ALL views from that copy Module. The log that is produced when running the script also needs capturing, but I’m not sure whether this should be done from within the script, if possible or as a separate manual task outside of the script.
The aforementioned (indented) process would then be repeated, using the same generic script, against the remaining nine copied Modules. The intension is to leave us with ten copy Modules, each one reflecting one of the ten possible Views, with each one containing only the Attributes, Columns etc. required for that View.
Creating a mirror of a module with this approach is not so easy IMO. Think e.g. about "Absolute Number". If the original module contains the numbers 15 (level 1), 2000 (level 2), 1 (level 1), you will have to create 2000 objects, purge 1997 of them and move them to the correct place.
There is a "duplicate" tool at https://www.ibm.com/developerworks/community/forums/html/topic?id=43862118-113d-4eac-b3f1-21d3b73959d1 which tries to do this, but as stated there, this script is said not to work correctly in all situations.
So, I would rather use the approach "string clipCopy (Item i); string clipPaste(Folder folderRef)". Should be faster and less error prone. But: all Out-Links will also be copied with this method, you will probably have to delete these after the copy or else the link target module(s) will have lots of In-Links.
The problem is still not so easy to solve, as every view might have DXL columns that rely on some or other attribute, and it might contain DXL attributes which again might rely on sth else. I doubt that there is a way to analyze DXL code "on the fly" and find out which columns may be deleted.
Perhaps a totally different approach would be feasible: open each view and create an export to Excel, this way you will get rid of any dynamic dependencies. Then re-import the excel sheet to a new DOORS module. You will still have the "Absolute Number" problem, but perhaps you can make a deal that you will have a pseudo attribute "Original Absolute Number" and disregard the "new" "Absolute Number"'
Quite a big task for a DXL beginner....
Update: On second thought, perhaps you might want to combine these approaches
agree with your employer that you will use an alternative attribute for Absolute Number
use a loop like Russel suggested, when creating objects remember that objects might have to be created "below" or "after" its predecessor or sibling
for DXL attributes do not copy the DXL code but the actual current value of the object
for DXL columns create pseudo attributes _ and create a new view that uses these pseudo attributes instead of the original value
Copying the entire module, then deleting everything not in that view, seems worse than just copying the things you need from each particular view.
I would take the following as the outline of your program:
for view in main module do {
for column in view do {
Find attribute for each column and store (possibly in a skip list?)
Store name of column
}
create new module
create needed types / attributes in new module
create new view in new module
for object in main module {
create object in new module
for attribute in main module {
check if attribute is in new module {
copy info from old object to new
}
}
}
}
Each of these for X in y loops should be in the DXL reference manual in some for or another.
If you need more help, let me know!
I have a script which saves some files at a given location. It works fine but when I send this code to someone else, he has to change the paths in the code. It's not comfortable for someone who does not know what is in that code and for me to explain every time where and how the code should be changed.
I want to get this path in a variable which will be taken from the configuration file. So it will be easier for everyone to change just this config file and nothing in my code. But I have never done this before and could not find any information on how I can do this in the internet.
PS: I do not have any code and I ask about an ultimate solution but it is really difficult to find something good in the internet about dxl, especially since I'm new with that. Maybe someone of you already does that or has an idea how it could be done?
DXL has a perm to read the complete context of a file into a variable: string readFile (string) (or Buffer readFile (string))
you can split the output by \n and then use regular expressions to find all lines that match the pattern
^\s*([^;#].*)\s*=\s*(.*)\s*$
(i.e. key = value - where comment lines start with ; or #)
But in DOORS I prefer using DOORS modules as configuration modules. Object Heading can be the key, Object Text can be the value.
Hardcode the full name of the configuration module into your DXL file and the user can modify the behaviour of the application.
The advantage over a file is that you need not make assumptions on where the config file is to be stored on the file system.
It really depends on your situation. You are going to need to be a little more specific about what you mean by "they need to change the paths in the code". What are these paths to? Are they DOORS module paths, are they paths to local/network files, or are the something else entirely?
Like user3329561 said, you COULD use a DOORS module as a configuration file. I wouldn't recommend it though, simply because that is not what DOORS modules were designed for. DOORS is fully capable of reading system files in one line at a time as well as all at once, but I can't recommend that option either until I know what types of paths you want to load and why.
I suspect that there is a better solution for your problem that will present itself once more information is provided.
I had the same problem, I needed to specify the path of my configuration file used in my dxl script.
I solved this issue passing the directory path as a parameter to DOORS.exe as follow:
"...\DOORS\9.3\bin\doors.exe" -dxl "string myVar = \"Hello Word\"
then in my dxl script, the variable myVar is a global variable.
I need to use DXL to loop through all modules in our database and find out which Rational Change Template each module is using, and possibly switch it to a different one. Can't find any documentation on Change API for DOORS.
I had to contact IBM directly to get this information. But here it is if anyone else needs to do it.
Skip cfgData = createString
string current_template = ""
getModuleConfigurationData(m, cfgData)
find(cfgData, CSINT_CONFIG_USE_TEMPLATE, current_template)
delete cfgData
At this point current_template has the file name of the template that it is configured for. This can be used to compare to existing templates and verify it is set correctly.
Also, if an update is necessary the following function will save the skip list back to the configuration.
put(cfgData, CSINT_CONFIG_USE_TEMPLATE, new_template)
cmSaveModuleConfigurationData(m, cfgData)