Fix docs

Author: crazy-max

.github/workflows/docs.yml

@@ -4,7 +4,7 @@ on:
   push:
     branches:
       - 'main'
-      - 'mkdocs' # To remove after merge
+      - 'mkdocs' # Remove after merge
       - 'v*'
     tags:
       - 'v*'
@@ -59,7 +59,8 @@ jobs:
           pages_threshold: major_outage
       -
         name: Deploy
-        if: success() && github.event_name != 'pull_request' && (endsWith(github.ref, github.event.repository.default_branch) || steps.prepare.outputs.release == 'true')
+        #if: success() && github.event_name != 'pull_request' && (endsWith(github.ref, github.event.repository.default_branch) || steps.prepare.outputs.release == 'true')
+        if: success() && github.event_name != 'pull_request' # Remove after merge and use the previous condition
         uses: crazy-max/[email protected]
         with:
           target_branch: gh-pages

docs/Migration/Custom-Controls.md

@@ -1 +1 @@
->> Content to come!
+_TODO_

docs/Migration/MasterPages.md

@@ -1 +1 @@
->> Content to come!
+_TODO_

docs/Migration/NET-Standard.md

@@ -1,5 +1,3 @@
-# .NET Standard to the Rescue
-
 .NET Standard is the definition of a contract, a series of APIs, that all .NET frameworks must implement to be considered a .NET framework.  .NET Framework, .NET Core, Xamarin, and Mono all implement various .NET Standard versions (or specifications) and this now becomes a vehicle for you to build your class libraries to be re-usable across various version of .NET.
 
 >> Needs links to the .NET Standard specifications and repository on GitHub
@@ -19,8 +17,16 @@ For your existing Web Forms applications, unless you are executing unsafe code o
 
 ## Sample 1: Update an existing class library
 
-The first sample demonstrates updating a simple class library to .NET Standard.  In this model, we're assuming that you already have your business logic code properly separated from your user-interface and managed inside a class-library project that targets .NET Framework 4.5.  You can find the source and directions for this sample in the [samples/netstandard-1](samples/netstandard-1) folder.
+The first sample demonstrates updating a simple class library to .NET Standard.  In this model, we're assuming that you already have your business logic code properly separated from your user-interface and managed inside a class-library project that targets .NET Framework 4.5.
+
+### Sample
+
+This is a simple migration sample, demonstrating migrating a class-library from .NET Framework 4.5 to .NET Standard 2.0
 
 ## Sample 2: Refactoring Business Logic
 
-The second sample shows how to take an existing ASP<span></span>.NET application and refactor our some business logic as a .NET Standard project.  You can find the source and directions for this sample in the [samples/netstandard-2](samples/netstandard-2) folder.
+The second sample shows how to take an existing ASP<span></span>.NET application and refactor our some business logic as a .NET Standard project.
+
+### Sample
+
+This sample shows how to refactor some business logic from our Web Forms application into a .NET Standard library that can eventually be re-used in the .NET Core / ASP<span></span>.NET Core / Server-side Blazor application.

docs/Migration/Strategies.md

@@ -1,12 +1,10 @@
-# Migration Strategies
-
 Migration from ASP<span></span>.NET Web Forms to Blazor is not simple and this repository attempts to make it easier for developers to reuse as much of their Web Forms application as possible.  The two technologies are 'concept compatible', but run on different implementations of the .NET runtime (.NET Framework vs. .NET Core / .NET 5+)
 
 We, the maintainers of this project, believe that with a little ingenuity the markup from a Web Forms application can be copied over with minimal changes and function similarly to its original purpose.  We believe that well formatted and maintained code in Web Forms should be easily migrated.  Applications that are a significant mix of C# and markup will have a more difficult time going through this process.
 
 ## Readiness Planning
 
-Migrating an application to Blazor is not a trivial process and it would be great to have some indication ahead of time how much work is needed and what steps you need to take to prepare to migrate.  Check our migration [readiness document](../migration_readiness.md) to help determine how much work will be needed for your application to begin the process.
+Migrating an application to Blazor is not a trivial process and it would be great to have some indication ahead of time how much work is needed and what steps you need to take to prepare to migrate.  Check our migration [readiness document](migration_readiness.md) to help determine how much work will be needed for your application to begin the process.
 
 ## Known Required Changes
 
@@ -34,7 +32,7 @@ The concept of a MasterPage does not exist in Blazor.  Instead, your ASPX pages
 
 ### Page Directive Changes
 
-### No <%#: DataBinding expressions 
+### No <%#: DataBinding expressions
 
 Databinding expressions in Web Forms let you evaluate the content of the elements and format them appropriately for presentation.  For editor controls, it also allows you to setup a 2-way binding so that you can receive values entered into the same variable bound to the control.
 
@@ -50,25 +48,25 @@ For editor components, simply `@bind` the variable to the component.  This will
 <input type="text" name="foo" @bind="bar" />
 ```
 
-### No Namespaces, No Tag-Prefixes 
+### No Namespaces, No Tag-Prefixes
 
 Namespaces and tag-prefixes are gone.  You can do a Find and Replace on `asp:` and remove those from your markup.
 
 ### Redirect Color to WebColor
 
-This change should **NOT** require any coding modifications.  In Web Forms, you could refer to `System.Drawing.Color` objects when setting `BackColor`, `BorderColor`, and `ForeColor` to name a few properties.  You could _ALSO_ freely use HTML hex-color notation freely in these fields.  
+This change should **NOT** require any coding modifications.  In Web Forms, you could refer to `System.Drawing.Color` objects when setting `BackColor`, `BorderColor`, and `ForeColor` to name a few properties.  You could _ALSO_ freely use HTML hex-color notation freely in these fields.
 The `System.Drawing.Color` object does not have a converter that allows you to convert between these two formats, so we wrapped the object and made `BlazorWebFormsComponents.WebColor` that performs the same task and allows the interchange of `System.Drawing.Color` object with HTML hex notation.
 
 ## Strategies
 
 - A simple initial site migration
 - Intertwined code
-- [DataBinder](Databinder.md)
+- [DataBinder](../UtilityFeatures/Databinder.md)
 - Model-Binding
 - [.NET Standard to the rescue!](NET-Standard.md)
 - Other considerations
   - [MasterPage](MasterPages.md)
     - Rearchitecting Web Application Layout
   - UserControls
     - The simple conversion
-  - [Custom Controls](Custom-Controls.md)
+  - [Custom Controls](Custom-Controls.md)

docs/Migration/User-Controls.md

@@ -1,3 +1 @@
-# User Controls
-
->> Content to come
+_TODO_

docs/Migration/migration_readiness.md

@@ -1,5 +1,3 @@
-# Web Forms Application Migration Readiness
-
 This document is intended as a primer for prospective teams to review in preparation for migrating their Web Forms applications to Server-Side Blazor.  We believe the migration is a multi-step process and this application review and preparation is the first step in migrating / rewriting an application using Blazor.
 
 ## Definitions

docs/Migration/samples/netstandard-1/README.md

@@ -90,3 +90,9 @@ nav:
     - ViewState: UtilityFeatures/ViewState.md
   - Migration:
       - Getting started: Migration/readme.md
+      - Migration Strategies: Migration/Strategies.md
+      - Custom Controls: Migration/Custom-Controls.md
+      - Master Pages: Migration/MasterPages.md
+      - .NET Standard to the Rescue: Migration/NET-Standard.md
+      - User Controls: Migration/User-Controls.md
+      - Web Forms Application Migration Readiness: Migration/migration_readiness.md