We like to keep our dxl scripts under our configuration management system which means creating and editing them in the software development tree. The only way I have been able to get the script from the software development tree into DOORS as a dxl attribute is a clunky copy and paste. In other words, I bring the script up in my editing tool, select all the text, copy it, go into DOORS, edit the dxl attribute (edit attribute, Browse, Current), and paste. I know there has got to be a better way to do this.
mtmccor - Wed Oct 28 16:29:50 EDT 2009 |
|
Re: management/editing of scripts for dxl attributes
SystemAdmin - Wed Oct 28 18:31:33 EDT 2009
Hi,
An option is to set up a share area that all users can access - copy the DXL file with the code into that location, enter a one line #include statement in your DXL Attribute that points to the target DXL file on the share. This is equally applicable to DXL Layout code.
Whenever a new version of the DXL file is released, just replace the old version on the share with the new one - this is handy if there are many instances of the same DXL Attribute\View spread across many modules, you only have to update the code in one place.
The share access permissions should be configured so that DOORS users only have Read-Only access.
The down side is that DOORS modules that have DXL layout\Attribute code using this technique are not transportable outside of the organisation - so if you send an archive copy to a customer or vendor, the views and attributes that use this code will fail when restored on their DOORS DB. Another down side is the share location - it must be readily accessible by all users including performance speed, so don't put it on a workstation\server that is not on a major LAN backbone.
I have heard of the possibility of using the "Conf" directory within the DOORS DB data area as an alternative common location to store commonly used DXL code - I'm very sketchy about this alternative, others reading this with more experience about this might respond.
Paul Miller
|
|
Re: management/editing of scripts for dxl attributes
mtmccor - Thu Oct 29 07:06:02 EDT 2009
Two questions related to using the #include:
1. How do you run a check on the dxl code before executing it or do you just let the execution of it provide the error messages? (Though I would like to think I write perfect code, I don't. So I do like the Check button in the dxl attribute editor.)
2. When I made a change to the dxl script, I couldn't use the refresh in the module to get the updated script executed. I had to close and reopen the module. Is closing and reopening the module the only way to refresh the dxl attribute if the #include is used or am I missing something?
Thanks,
Marjorie
|
|
Re: management/editing of scripts for dxl attributes
doors36677 - Thu Oct 29 09:15:58 EDT 2009 mtmccor - Thu Oct 29 07:06:02 EDT 2009
Two questions related to using the #include:
1. How do you run a check on the dxl code before executing it or do you just let the execution of it provide the error messages? (Though I would like to think I write perfect code, I don't. So I do like the Check button in the dxl attribute editor.)
2. When I made a change to the dxl script, I couldn't use the refresh in the module to get the updated script executed. I had to close and reopen the module. Is closing and reopening the module the only way to refresh the dxl attribute if the #include is used or am I missing something?
Thanks,
Marjorie
View->Reload
|
|
Re: management/editing of scripts for dxl attributes
llandale - Thu Oct 29 16:24:13 EDT 2009
There is no 'load' button, but you can right-click in the window and File >>Load .. a DXL file, instead of copying and pasting it.
Best way to debug the layout/attrDxl is to use the #include, but you still need to 'edit' and 'check' it again to get the new code. However, larger companies don't have a central spot to put such scripts, so deploying an $include doesn't work; neither will it work when you archive the module and send it elsewhere.
Better to put a copy in each attr or column, but then you must update each one when the code changes.
Am playing with the idea of storing the code itself in config files in the database and having the code read the config file, but you won't have access to the 'obj' variable and will need to send the Identifier to the code and have it look for the object, before doing anything.
|
|
Re: management/editing of scripts for dxl attributes
mtmccor - Fri Oct 30 10:12:27 EDT 2009 llandale - Thu Oct 29 16:24:13 EDT 2009
There is no 'load' button, but you can right-click in the window and File >>Load .. a DXL file, instead of copying and pasting it.
Best way to debug the layout/attrDxl is to use the #include, but you still need to 'edit' and 'check' it again to get the new code. However, larger companies don't have a central spot to put such scripts, so deploying an $include doesn't work; neither will it work when you archive the module and send it elsewhere.
Better to put a copy in each attr or column, but then you must update each one when the code changes.
Am playing with the idea of storing the code itself in config files in the database and having the code read the config file, but you won't have access to the 'obj' variable and will need to send the Identifier to the code and have it look for the object, before doing anything.
I'm not sure that I understand what you mean when you say "Best way to debug the layout/attrDxl is to use the #include, but you still need to 'edit' and 'check' it again to get the new code." If all I have in the attribute DXL is a #include statement, then the check only checks that statement. So is the recommended process to edit the DXL attribute the following:
1. open the dxl attribute for edit (edit attribute, Browse, Current)
2. load the dxl script (which overwrites the #include)
3. run Check
4. fix problems in script
5. iterate through 2-4 as necessary until the check is clean
6. once the check passes, cancel out of the dxl attribute edit so that it is left with the original #include statement
Or am I once again overly complicating a process?
Also, the View->Reload that was suggested by one response did not work to get the module to use the updated included dxl script. I still have to exit the module and reopen it if I want it to use the updated included dxl script. Any other suggestions?
Finally, what you are trying with the config files in the database is beyond my DOORS dxl level at this point, but if this proves fruitful, I would be interested in more details later.
|
|
Re: management/editing of scripts for dxl attributes
PDU - Fri Oct 30 11:38:33 EDT 2009 mtmccor - Fri Oct 30 10:12:27 EDT 2009
First of all, your answer that I can right click in the DXL attribute edit window and then do a File->Load answered my original question. However, the input from Paul about using the #include has opened up other possibilities that I had not thought about, and I still have questions related to the use of #include.
I'm not sure that I understand what you mean when you say "Best way to debug the layout/attrDxl is to use the #include, but you still need to 'edit' and 'check' it again to get the new code." If all I have in the attribute DXL is a #include statement, then the check only checks that statement. So is the recommended process to edit the DXL attribute the following:
1. open the dxl attribute for edit (edit attribute, Browse, Current)
2. load the dxl script (which overwrites the #include)
3. run Check
4. fix problems in script
5. iterate through 2-4 as necessary until the check is clean
6. once the check passes, cancel out of the dxl attribute edit so that it is left with the original #include statement
Or am I once again overly complicating a process?
Also, the View->Reload that was suggested by one response did not work to get the module to use the updated included dxl script. I still have to exit the module and reopen it if I want it to use the updated included dxl script. Any other suggestions?
Finally, what you are trying with the config files in the database is beyond my DOORS dxl level at this point, but if this proves fruitful, I would be interested in more details later.
if you use "DXL Editor" (http://www.dxleditor.com),
you have an automatic check of your code when you write it.
It is free.
I have no problem with View->Reload F5 (DOORS 9.1)
Pierre
|
|
Re: management/editing of scripts for dxl attributes
llandale - Fri Oct 30 13:31:00 EDT 2009 mtmccor - Fri Oct 30 10:12:27 EDT 2009
First of all, your answer that I can right click in the DXL attribute edit window and then do a File->Load answered my original question. However, the input from Paul about using the #include has opened up other possibilities that I had not thought about, and I still have questions related to the use of #include.
I'm not sure that I understand what you mean when you say "Best way to debug the layout/attrDxl is to use the #include, but you still need to 'edit' and 'check' it again to get the new code." If all I have in the attribute DXL is a #include statement, then the check only checks that statement. So is the recommended process to edit the DXL attribute the following:
1. open the dxl attribute for edit (edit attribute, Browse, Current)
2. load the dxl script (which overwrites the #include)
3. run Check
4. fix problems in script
5. iterate through 2-4 as necessary until the check is clean
6. once the check passes, cancel out of the dxl attribute edit so that it is left with the original #include statement
Or am I once again overly complicating a process?
Also, the View->Reload that was suggested by one response did not work to get the module to use the updated included dxl script. I still have to exit the module and reopen it if I want it to use the updated included dxl script. Any other suggestions?
Finally, what you are trying with the config files in the database is beyond my DOORS dxl level at this point, but if this proves fruitful, I would be interested in more details later.
But you must re-check in order to see your changes. If you insert an "X" into the file and then simply re-calculate attr-DXL, you get the old results because the attrDXL code hasn't been updated yet, it still contains the valid code that has no extraneous X in it.
This lets you edit the code in some external editor, which except for Notepad are all pretty much better for editing code than the DXL editor.
|
|
Re: management/editing of scripts for dxl attributes
mtmccor - Tue Nov 03 07:38:42 EST 2009 llandale - Fri Oct 30 13:31:00 EDT 2009
If you attrDXL contains just an #include statment, then the file is in fact included when you 'check' the DXL. Insert an "X" in the file itself and re-check will result in an error.
But you must re-check in order to see your changes. If you insert an "X" into the file and then simply re-calculate attr-DXL, you get the old results because the attrDXL code hasn't been updated yet, it still contains the valid code that has no extraneous X in it.
This lets you edit the code in some external editor, which except for Notepad are all pretty much better for editing code than the DXL editor.
I am still unable to get the uploaded DXL in the include file to be used unless I close and reopen the module. The View->Reload (F5) did not work for me. We are running version 8.1. Maybe it is a bug in that version. It is just a minor annoyance anyway.
|
|
Re: management/editing of scripts for dxl attributes
mtmccor - Tue Nov 03 07:39:39 EST 2009
My original question has been answered, plus a few more. Thanks.
|
|
Re: management/editing of scripts for dxl attributes
Illo_993 - Tue Nov 03 08:24:36 EST 2009 mtmccor - Tue Nov 03 07:39:39 EST 2009
My original question has been answered, plus a few more. Thanks.
the approach of separating the code from DOORS itself referenced by Paul is useful for any DOORS scripts which are deployed to users:
Normally DOORS extension scripts will be provided via extra menus, e.g. "DOORS Extensions" and menu items, e.g. "Script for xyz".
These menu items will be generated by special menu files which in turn could contain the whole application code.
But it is useful to place a single code line, beginning with #include or eval_, which refereces the application code on a global file share (deployment directory). This deployment directory should be filled by a bundle of code files which have passed a quality gate (e.g. baseline in a CM tool).
Cheers
Illo
|
|