This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Where are all the best practices?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Dec 20, 2005
06:42 PM
Where are all the best practices?
(2) Replies
‎Jan 05, 2006
02:55 PM
Hi,
I would suggest starting with this product introduction, then read through these tutorials, and finally watch these webinars.
Rich
I would suggest starting with this product introduction, then read through these tutorials, and finally watch these webinars.
Rich
‎Jan 05, 2006
05:21 PM
Hey,
Personally, I'd start with the webinar that Rich mentioned above, since it gives a good example of what collaboration is and how to use it in a visual representation. With the individuals I have spoken to so far, the webinar seems to hit home fairly quickly and the rest of the information fills in the details from there.
For a broad sense of a "best practice", I tend to take the architectural approach and design the DIMs and their relationships first. I like to think of the DIM as a box of functionality. For example, in the webinar example, my "product" was a string generator tool with a utility backend. With that in mind, I first looked at the functional pieces involved: (1) the common utility code and (2) the UI front-end. Each of those functional pieces would then be represented as a DIM, with the "front-end" DIM having a dependency on the "utility" DIM. Starting from scratch and acting as a DIM "architect", I would have created the two DIMs first, defining their general information (i.e. UUID, name, dependencies, etc), but left the contents out. Those DIM skeletons would be passed to the developers in charge of filling in the "functional boxes" represented by the DIM. Once the DIMs (and the code behind them) were filled in by the developers, they would be passed on to the install developer for consumption. As an example of in-house usage, we keep a location with the different versions of the collaboration automation architecture (since it is a "functional box" in itself) alongside the DIM which would be used to consume it. This makes it simple to switch between the different versions for consumption purposes for our other products which leverage the collaboration automation APIs.
In general, that's the type of procedure I tend to suggest when starting from scratch:
1: Determine functional pieces.
2: Design DIMs for each functional piece.
3: Developer fills in each DIM with code/resources.
4: Install developer consumes necessary DIMs with installer.
This process involves thoughts of distribution from the very beginning when you are just thinking about functionality, rather than late in the process when you have functionality, but no manner by which to distribute it.
NOTE: For wrapping DIMs around existing code, it's essentially the same thing, except for the fact that the code is available before the DIM is designed. In that case, you'd still determine what the available functional blocks are and add the appropriate items to each box from the existing code\resources.
Let me know if this clears anything up and\or you have further questions.
Bill
Personally, I'd start with the webinar that Rich mentioned above, since it gives a good example of what collaboration is and how to use it in a visual representation. With the individuals I have spoken to so far, the webinar seems to hit home fairly quickly and the rest of the information fills in the details from there.
For a broad sense of a "best practice", I tend to take the architectural approach and design the DIMs and their relationships first. I like to think of the DIM as a box of functionality. For example, in the webinar example, my "product" was a string generator tool with a utility backend. With that in mind, I first looked at the functional pieces involved: (1) the common utility code and (2) the UI front-end. Each of those functional pieces would then be represented as a DIM, with the "front-end" DIM having a dependency on the "utility" DIM. Starting from scratch and acting as a DIM "architect", I would have created the two DIMs first, defining their general information (i.e. UUID, name, dependencies, etc), but left the contents out. Those DIM skeletons would be passed to the developers in charge of filling in the "functional boxes" represented by the DIM. Once the DIMs (and the code behind them) were filled in by the developers, they would be passed on to the install developer for consumption. As an example of in-house usage, we keep a location with the different versions of the collaboration automation architecture (since it is a "functional box" in itself) alongside the DIM which would be used to consume it. This makes it simple to switch between the different versions for consumption purposes for our other products which leverage the collaboration automation APIs.
In general, that's the type of procedure I tend to suggest when starting from scratch:
1: Determine functional pieces.
2: Design DIMs for each functional piece.
3: Developer fills in each DIM with code/resources.
4: Install developer consumes necessary DIMs with installer.
This process involves thoughts of distribution from the very beginning when you are just thinking about functionality, rather than late in the process when you have functionality, but no manner by which to distribute it.
NOTE: For wrapping DIMs around existing code, it's essentially the same thing, except for the fact that the code is available before the DIM is designed. In that case, you'd still determine what the available functional blocks are and add the appropriate items to each box from the existing code\resources.
Let me know if this clears anything up and\or you have further questions.
Bill
