Topic
  • 13 replies
  • Latest Post - ‏2014-04-14T13:33:28Z by GerhardS
GerhardS
GerhardS
55 Posts

Pinned topic Library concept?

‏2014-04-03T08:47:37Z |

Hello,

I'm currently facing the problem to manage common libraries across addins/projects/attribs/layouts. The requirements in detail:

  1. There are complex tools which are spread across all parts of DOORS (i.e., addins, project-addins, layout dxl, attrib dxl, even triggers).
  2. There are libraries which these tools shall use in common.
  3. These libraries shall be located in exactly one place.
  4. Tools and libraries shall be outside of the DOORS program files structure, e.g., they are located in projects spaces.

To fulfill these requirements, things are easy as long as we talk about the non-library parts, i.e. those parts can be handled by applying multiple parts to the registry entries or command line parameters.

But: it seems to me that the libraries themselves cannot be placed in the required way, as the only path where DOORS is looking for code beside the addins, projects etc. is the DOORSHOME, and this is conflicting with requirement #4. And, the -H parameter obviously allows only one argument, not a list, like the other parameters.

The only solution I see is to replicate the DOORSHOME/* structure to the project space, and to put the libraries in there, and to redirect the DOORSHOME path by the relating registry entry/command line parameter.

Is this correct, or do you have any other idea?

Best regards,

Gerhard

Updated on 2014-04-03T10:41:38Z at 2014-04-03T10:41:38Z by GerhardS
  • llandale
    llandale
    3035 Posts
    ACCEPTED ANSWER

    Re: Library concept?

    ‏2014-04-04T15:53:40Z  
    • GerhardS
    • ‏2014-04-04T12:16:52Z

    Thanks, Louie - but what about relative #include references from a DOORSHOME/lib/dxl/config/formalPopupMenus/something.dxl to a library.inc which shall also be used by the SOMEWHEREELSE/addins/PROJECT/somewhat.dxl? Where to locate the library.inc so that it will be found by both?

    - Gerhard

    Once you get any DXL to "find" your library, all will find it.  That is, the following behaves exactly the same regardless of the type of DXL (attr-DXL, Trigger, on-demand) or where it is located:

    • #include <Includes\Library.inc>

    -Louie

  • adevicq
    adevicq
    154 Posts

    Re: Library concept?

    ‏2014-04-03T12:26:57Z  

    Hi,

    You have to be conform to the registry entries that DOORS works with:

    • addins
    • layoutadins
    • projectaddins
    • attributeaddins

    See this page to understand how to use them:

    http://pic.dhe.ibm.com/infocenter/doorshlp/v9r5/index.jsp?topic=%2Fcom.ibm.doors.configuring.doc%2Ftopics%2Fc_registrysettings.html

    What I do is:

    • I have my dedicated structure on a shared folder (you can name the directories as you want)
    • I have created a .reg file with the appropriate values
    • I ask anyone who needs to install DOORS to run the reg file
    • Everyone use the same version if my dxl library.

    I also have the same structure locally and a .reg that points to my hard disk to make changes prior to send them to production. I use WinMerge to syng folders.

    You can have different versions of the reg file if you need to give access to different options to different people.

    Hope this helps...

    Alain

     

     

  • GerhardS
    GerhardS
    55 Posts

    Re: Library concept?

    ‏2014-04-03T12:54:26Z  
    • adevicq
    • ‏2014-04-03T12:26:57Z

    Hi,

    You have to be conform to the registry entries that DOORS works with:

    • addins
    • layoutadins
    • projectaddins
    • attributeaddins

    See this page to understand how to use them:

    http://pic.dhe.ibm.com/infocenter/doorshlp/v9r5/index.jsp?topic=%2Fcom.ibm.doors.configuring.doc%2Ftopics%2Fc_registrysettings.html

    What I do is:

    • I have my dedicated structure on a shared folder (you can name the directories as you want)
    • I have created a .reg file with the appropriate values
    • I ask anyone who needs to install DOORS to run the reg file
    • Everyone use the same version if my dxl library.

    I also have the same structure locally and a .reg that points to my hard disk to make changes prior to send them to production. I use WinMerge to syng folders.

    You can have different versions of the reg file if you need to give access to different options to different people.

    Hope this helps...

    Alain

     

     

    Thanks, Alain, for your suggestion. Let me try to put more focus on the critical point: It is _not_ the problem to have multiple folders for addins etc.; but it is the problem to have common libraries across all these, being provided _outside_ the DOORSHOME.

    This is, what I suppose not to be possible, as DOORS first searches the DOORSHOME/bin, then the DOORSHOME/lib/dxl, then the addins etc. for #include code.

    If you now want to have a library, which shall provide code for addins, projects, etc., you either have to duplicate the code to everywhere, or you have to put it into the DOORSHOME, so change the DOORS installation (which is, for many customers, not allowed by their IT departments).

    The consequence seems to me to duplicate the whole DOORSHOME to a shared location, and put the library code in there.

    But this is also not too nice; so perhaps there is any other idea about that problem...

    Hope that clarifies my problem.

    - Gerhard

  • adevicq
    adevicq
    154 Posts

    Re: Library concept?

    ‏2014-04-03T13:48:50Z  
    • GerhardS
    • ‏2014-04-03T12:54:26Z

    Thanks, Alain, for your suggestion. Let me try to put more focus on the critical point: It is _not_ the problem to have multiple folders for addins etc.; but it is the problem to have common libraries across all these, being provided _outside_ the DOORSHOME.

    This is, what I suppose not to be possible, as DOORS first searches the DOORSHOME/bin, then the DOORSHOME/lib/dxl, then the addins etc. for #include code.

    If you now want to have a library, which shall provide code for addins, projects, etc., you either have to duplicate the code to everywhere, or you have to put it into the DOORSHOME, so change the DOORS installation (which is, for many customers, not allowed by their IT departments).

    The consequence seems to me to duplicate the whole DOORSHOME to a shared location, and put the library code in there.

    But this is also not too nice; so perhaps there is any other idea about that problem...

    Hope that clarifies my problem.

    - Gerhard

    Hi again,

    No, there is no problem to share libraries.

    You just have to add the right include path. For example, we use includes for Layout and Addins and we share the file. We never had to make copies of dxl files.

    My "addins" folder is organized in the following way:

    • addins/Cegedim/Export
    • addins/Cegedim/Import
    • addins/Cegedim/include
    • ...

    Same for others

    • admin/Cegedim (for specifi admin tools)
    • Layout/Cegedim
    • ...

    (to be honest, I could have avoided the "Cegedim" intermediate level to make it simpler...)

    in each dxl file (whatever its location) I add the includes like this:

    #include <include/Cegedim/myincfile.inc>

    DOORS finds the file in the "addins/include/Cegedim" folder.

    Does it answer your question?

    Alain

     

     

     

    Updated on 2014-04-03T13:49:51Z at 2014-04-03T13:49:51Z by adevicq
  • GerhardS
    GerhardS
    55 Posts

    Re: Library concept?

    ‏2014-04-03T15:01:56Z  
    • adevicq
    • ‏2014-04-03T13:48:50Z

    Hi again,

    No, there is no problem to share libraries.

    You just have to add the right include path. For example, we use includes for Layout and Addins and we share the file. We never had to make copies of dxl files.

    My "addins" folder is organized in the following way:

    • addins/Cegedim/Export
    • addins/Cegedim/Import
    • addins/Cegedim/include
    • ...

    Same for others

    • admin/Cegedim (for specifi admin tools)
    • Layout/Cegedim
    • ...

    (to be honest, I could have avoided the "Cegedim" intermediate level to make it simpler...)

    in each dxl file (whatever its location) I add the includes like this:

    #include <include/Cegedim/myincfile.inc>

    DOORS finds the file in the "addins/include/Cegedim" folder.

    Does it answer your question?

    Alain

     

     

     

    So it seems that even if the context is somewhere else (e.g. in project/...), DOORS finds files that are located in other contextes (e.g., in addins/...).

    However, there remains the question how to enhance the DOORSHOME (e.g., context menus) without duplicating that one as a whole, to be able to redirect the -home setting - any solution for that?

     

    - Gerhard

  • adevicq
    adevicq
    154 Posts

    Re: Library concept?

    ‏2014-04-03T15:16:13Z  
    • GerhardS
    • ‏2014-04-03T15:01:56Z

    So it seems that even if the context is somewhere else (e.g. in project/...), DOORS finds files that are located in other contextes (e.g., in addins/...).

    However, there remains the question how to enhance the DOORSHOME (e.g., context menus) without duplicating that one as a whole, to be able to redirect the -home setting - any solution for that?

     

    - Gerhard

    If what you call "context menus" corresponds to menus and menu items in the explorer or module windows, it works as DOORS gets the DXL for these menus from the addins and projectaddins registry entries. Therefore you can create as many menus / submenus as needed.

    If this is about menus tha open when right lcicking on an obect I don't know as I don't use this feature...

    Alain

     

  • llandale
    llandale
    3035 Posts

    Re: Library concept?

    ‏2014-04-03T18:22:57Z  

    The key here is that #include file references are resolved vis-a-vis the "addins" variable, which controlls the formal-module menus.

    I have a "DXL-v9" folder, that has these sub-folders; but does NOT have any "DXL-v9.hlp" nor "DXL-v9.idx"

    • Includes   ....... contains the include files
    • Menu-Attr-DXL
    • Menu-Explorer
    • Menu-Formal  .. contains module menu
    • Menu-Layout

    The "addins" variable will look like this:

    • //MyServer/DXL-v9;//MyServer/DXL-v9/Menu-Formal"

    The DXL scripts include as follows:

    • #include <Includes/MyIncludeFile.inc>

    -Louie

    Note that since the DXL-v9 folder does not have any hlp nor idx file, that folder is effectivly ignored when DOORS attempts to build the module menu.  Now you could skip that reference and put the "Includes" folder under the "Menu-Formal" folder but I found CM was easier with the way stated above.

  • GerhardS
    GerhardS
    55 Posts

    Re: Library concept?

    ‏2014-04-04T05:45:06Z  
    • adevicq
    • ‏2014-04-03T15:16:13Z

    If what you call "context menus" corresponds to menus and menu items in the explorer or module windows, it works as DOORS gets the DXL for these menus from the addins and projectaddins registry entries. Therefore you can create as many menus / submenus as needed.

    If this is about menus tha open when right lcicking on an obect I don't know as I don't use this feature...

    Alain

     

    Your understanding is right, Alain: I do _not_ mean the top-level menues (those at the upper window border), but the context menus that you get by right-clicking on something (so: lib/dxl/config/formalPopupMenu and similar ones).

    Sharing the code under addins/project/... _only_ is not my problem. My problem is to have code shared among _all_ of that stuff, this means: libraries, that those context menus can use as well as the tools under addins/project/...

    To give a simple example: Imagine an administrative module where the objects hold references to other modules. If there shall be an "addins" menu providing a function "open selected module", as well as a context menu providing the same function for a specific object, both functions shall obviously use the same library code which executes the "open module".

    So: While the "addins" call is located somewhere in the addin's .idx file, the context menu call is located in the DOORSHOME area, in the formalPopupMenu environment.

    When deploying that, this raises the need to modify the DOORSHOME area, what is a problem. It may be acceptable to have the call there, but not a bunge of other code; that code shall be in the "addins" environment.

    Currently (after a bunge of experiments) it seems to me that there is no way around duplicating the whole DOORSHOME stuff to somewhere else, put all the code in there, and redirect the path via the -H command line switch.

  • adevicq
    adevicq
    154 Posts

    Re: Library concept?

    ‏2014-04-04T07:07:28Z  
    • GerhardS
    • ‏2014-04-04T05:45:06Z

    Your understanding is right, Alain: I do _not_ mean the top-level menues (those at the upper window border), but the context menus that you get by right-clicking on something (so: lib/dxl/config/formalPopupMenu and similar ones).

    Sharing the code under addins/project/... _only_ is not my problem. My problem is to have code shared among _all_ of that stuff, this means: libraries, that those context menus can use as well as the tools under addins/project/...

    To give a simple example: Imagine an administrative module where the objects hold references to other modules. If there shall be an "addins" menu providing a function "open selected module", as well as a context menu providing the same function for a specific object, both functions shall obviously use the same library code which executes the "open module".

    So: While the "addins" call is located somewhere in the addin's .idx file, the context menu call is located in the DOORSHOME area, in the formalPopupMenu environment.

    When deploying that, this raises the need to modify the DOORSHOME area, what is a problem. It may be acceptable to have the call there, but not a bunge of other code; that code shall be in the "addins" environment.

    Currently (after a bunge of experiments) it seems to me that there is no way around duplicating the whole DOORSHOME stuff to somewhere else, put all the code in there, and redirect the path via the -H command line switch.

    Well, you can us the "#include" directive in any dxl file including those located in the "formalPopupFiles" folder. I never tried but I am sure that this works. Have you?

  • GerhardS
    GerhardS
    55 Posts

    Re: Library concept?

    ‏2014-04-04T12:13:41Z  
    • adevicq
    • ‏2014-04-04T07:07:28Z

    Well, you can us the "#include" directive in any dxl file including those located in the "formalPopupFiles" folder. I never tried but I am sure that this works. Have you?

    Sure; the problem is a bit less problematic, when you're using absolute paths in those #includes. However, this is not very nice, so I'd like to use relative paths there. This is part of where my questions are about...

  • GerhardS
    GerhardS
    55 Posts

    Re: Library concept?

    ‏2014-04-04T12:16:52Z  
    • llandale
    • ‏2014-04-03T18:22:57Z

    The key here is that #include file references are resolved vis-a-vis the "addins" variable, which controlls the formal-module menus.

    I have a "DXL-v9" folder, that has these sub-folders; but does NOT have any "DXL-v9.hlp" nor "DXL-v9.idx"

    • Includes   ....... contains the include files
    • Menu-Attr-DXL
    • Menu-Explorer
    • Menu-Formal  .. contains module menu
    • Menu-Layout

    The "addins" variable will look like this:

    • //MyServer/DXL-v9;//MyServer/DXL-v9/Menu-Formal"

    The DXL scripts include as follows:

    • #include <Includes/MyIncludeFile.inc>

    -Louie

    Note that since the DXL-v9 folder does not have any hlp nor idx file, that folder is effectivly ignored when DOORS attempts to build the module menu.  Now you could skip that reference and put the "Includes" folder under the "Menu-Formal" folder but I found CM was easier with the way stated above.

    Thanks, Louie - but what about relative #include references from a DOORSHOME/lib/dxl/config/formalPopupMenus/something.dxl to a library.inc which shall also be used by the SOMEWHEREELSE/addins/PROJECT/somewhat.dxl? Where to locate the library.inc so that it will be found by both?

    - Gerhard

  • llandale
    llandale
    3035 Posts

    Re: Library concept?

    ‏2014-04-04T15:53:40Z  
    • GerhardS
    • ‏2014-04-04T12:16:52Z

    Thanks, Louie - but what about relative #include references from a DOORSHOME/lib/dxl/config/formalPopupMenus/something.dxl to a library.inc which shall also be used by the SOMEWHEREELSE/addins/PROJECT/somewhat.dxl? Where to locate the library.inc so that it will be found by both?

    - Gerhard

    Once you get any DXL to "find" your library, all will find it.  That is, the following behaves exactly the same regardless of the type of DXL (attr-DXL, Trigger, on-demand) or where it is located:

    • #include <Includes\Library.inc>

    -Louie

  • Mathias Mamsch
    Mathias Mamsch
    2147 Posts

    Re: Library concept?

    ‏2014-04-04T23:39:37Z  
    • GerhardS
    • ‏2014-04-04T12:16:52Z

    Thanks, Louie - but what about relative #include references from a DOORSHOME/lib/dxl/config/formalPopupMenus/something.dxl to a library.inc which shall also be used by the SOMEWHEREELSE/addins/PROJECT/somewhat.dxl? Where to locate the library.inc so that it will be found by both?

    - Gerhard

    ... and if you worry about the separation of Addins vs. a General Library all you need to do is have to entries in your ADDINS path:

    ADDINS = \\Somewhere\GeneralLibrary; \\SomewhereElse\Addins1; \\SomeWhereEvenDifferent\Addin2

    and your Directory Structure would look like:

    \\Somewhere\GeneralLibrary
             \Library.inc
    
    \\SomewhereElse\Addin1
             \Main Menu 1
    
    \\SomeWhereEvenDifferent\Addin2
             \Main Menu 2
    

    Since the general library is on the ADDINS Path all relative includes  will find it. Of course if you reference the general library in formalPopupMenus then you might get the problem, that DOORS will not startup correctly if the General Library is not on the addins path. Maybe this clarifies it a bit more...

    Regards, Mathias

  • GerhardS
    GerhardS
    55 Posts

    Re: Library concept?

    ‏2014-04-14T13:33:28Z  
    • llandale
    • ‏2014-04-04T15:53:40Z

    Once you get any DXL to "find" your library, all will find it.  That is, the following behaves exactly the same regardless of the type of DXL (attr-DXL, Trigger, on-demand) or where it is located:

    • #include <Includes\Library.inc>

    -Louie

    Thanks, Louie, that was the information I needed. Actually, I already tried that, but for any reason it didn't work that way on my machine. I now had the chance to try that on a clean machine, and voilà, it worked fine.