...
During the early stages of an upgrade project, you have the option to have gmStudio generate a stubbed-out version of the support library and integrate it with your project(s). This is similar to the stub classes that can be generated for COM APIs used by your code. Depending on the rules in your upgrade solution, the generated stub codes may be replaced by our sample implementation, or replaced by something else altogether.
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Historically, the RTL namespace conventions employed by gmStudio were simple: almost all the support functions were implemented in a MigrationSupport.Utils static class. The idea was to keep it simple and easy to describe. References to these functions were expected to be temporary placeholders until alternative, custom translations were designed and implemented by the Upgrade Team as part of their Upgrade Solution. However, we have found that some customers are not able to complete the analysis and design work needed for a full custom upgrade; they only have time and funding to do produce more direct results and they are comfortable with using the RTL we provide out of the box. However, as the RTL has grown, the MigrationSupport.Utils class has become bloated. We find that a more structured RTL model is needed to better organize a comprehensive set of RTL services. To better meet this need, we are enhancing our RTL specification to allow for stubbing and using a more structured set of namespaces and classes. The intent is to provide an RTL framework that is that more descriptive and maintainable. We are calling these new conventions gmRTL. The gmRTL namespace and class structure conventions will replace the legacy conventions before the end of 2021. The legacy conventions (i.e. MigrationSupport, MigrationSupportUI, etc) will be deprecated. Stay tuned for more information on the transition. |
...