Versions Compared

Version Old Version 1 New Version Current
Changes made by

Mark Juras

Mark Juras

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

One of the challenges with ASP classic is that the ASP classic processor is not a true compiler.  The only code that is ever formally checked by the ASP processor is the code that is actually executed by real world page requests.  You can have functions that are completely invalid and if they are not called, you would never know about it.  When we are translating a site, all the code on all the pages and their includes is compiled.  It is not uncommon for problems in the code to show up.  The tool does its best to interpret what it seesEven production tested VB6/ASP code may contain bugs or ambiguities that go unreported on the legacy platform. These "bad source code" problems can cause explicit translation errors or produce undesirable translation results.  gmBasic does its best to interpret whatever code you give it, but if there are problems in the source they often produce problems with the may lead to problems in .NET. 

Sometimes there are things we can do with the translator to accept bad or unconventional code, other time we have to use the pre-editor, and in the worst cases we have to hand fix files. 

It is also very common for an ASP site to contain files that were never finished, or have not been maintained and are no longer consistent with the rest of the site also have problems generating a clean correct translation and they should be brought to the attention of the customer to ask if they are still an active part of the site.  In active pages should be omitted from the translation project.  IN this way, the upgrade project is a good opportunity to clean up the site by removing the inactive content. This article describes how to address this in the context of gmStudio upgrade work.

Of course one can always directly modify your source code to correct or improve "bad code", however doing this may cause the source code to diverge from the production code in undocumented or unintentional ways.   If the source codes are also being updated for other maintenance, the "bad code fixes" may be lost when you merged changes.  The preferred way to make "bad code fixes" to improve translation results is to use the gmBasic Pre-editor.

Tip
titleUse the gmBasic pre-processor

gmBasic has a programmable pre-editor that is fast and precise. It allows migration teams to modify the source code in memory before it is processed for translation. Conceptually speaking, this is a search-and-replace facility. The original source code on disk is not modified.

If you are changing your source solely to prepare it for migration, it is a best practice to make changes "by tool" rather than doing them directly "by hand". Using the preprocessor documents the changes, applies them systematically, and makes them repeatable and trackable. This is particularly important if the source code is under active maintenance outside of the migration effort.

In its simplest form, the preprocessor may be invoked by the Compile/Fix or Refactor/EditFile commands.

1) Compile/Fix/Replace commands may placed in your translation script template or in a ScriptRules file:

Code Block
<Compile ...>
<Fix host="AppUtilities" name="PreEdits">
   <Replace status="active" name="vbDouble used twice in same Select">
   <OldBlock><![CDATA[
   Case vbDecimal, vbCurrency, vbDouble, vbSingle
   ]]></OldBlock>
   <NewBlock><![CDATA[ 
   Case vbDecimal, vbCurrency, vbSingle 
   ]]></NewBlock>
   </Replace> 
</Fix>
...
</Compile>


2) Registry-EditFile commands may be placed in a GlobalSettings file. This is particularly useful for shared files – like #include files with web sites or shared modules in VB6 systems.

Code Block
<GlobalImports>
<Storage Action="Create" Identifier="%UserFolder%\GlobalSettings" />
...
<Registry type="EditFile" Source="%VirtualRoot%\Accounts\Litbuildings\lookup_addr.asp">
<Fix name="Pre-Edits">
  <Replace status="active" name="remove malformed javascript">
  <OldBlock><![CDATA[//cal.setHolidays]]></OldBlock>
</Replace>
</Fix>
</Registry>
...
</GlobalSettings>

Notes:

  • Adding <Select Progress="1"> will provide a summary log of the fixes applied (or not)
  • Adding <Select Progress="2"> will provide a detailed log of the fixes applied (or not)
  • gmStudio can help you audit and report the fixes using the Translation Log report.

See Also