goldsim/website

Source code for the GoldSim.com website

website's Issues

Update all NuGet dependencies to latest versions

Update the DotNetStandard branch to use the latest version of all NuGet dependencies.

Updates

• Braintree 4.14.0
• EPPlus 4.5.3.2
• Ignia.Topics[.*] 3.8.0-alpha.257
• Microsoft.ApplicationInsights[.*] 2.10.0
• Microsoft.AspNet[.*] 3.2.7
• Microsoft.Net.Compilers 3.2.1
• Microsoft.CodeDom.Providers.DotNetCompilerPlatform 2.0.1
• Netonsoft.Json 12.0.2
• NuGet.CommandLine 5.1.0
• System.Data.SqlClient 4.6.1
• System.Diagnostics.DiagnosticSource 4.5.1
• System.Runtime 4.3.1
• System.Security.Cryptography.* 4.3.*

Resolve homepage video issues

Some of the dash segments for the 1000k homepage video appear to have been corrupted. As a temporary fix, I've removed the 1000k video from the MPD manifest. In the longer term, however, we should:

• Transcode the video again to ensure we have a clean copy
• Upgrade dash.js to the latest version in case there are bug fixes
• Reencorporate the 1000k version back into the MPD manifest
• Test each version of the video in context of the homepage

Create Form Views

Establish new ASP.NET Core views to provide the user interface for the forms.

Current Approach

The current forms use ASP.NET WebForm Web Controls wrapped up in User Controls to expose the user interface, centralize reusable components, and provide both client- and server-side form validation.

New Approach

With ASP.NET Core, the forms will now use standard MVC views. Reusable components can be handled via either partial views or—if they need to be parameterized—Razor components or view components. Form validation can now be handled using a combination of POCO attribute annotations as well as Microsoft’s jQuery-Validation-Unobtrustive library for client-side validation. With ASP.NET Core 3.0 specifically, the input controls can now use the built-in Razor components.

Research

• Determine functional differences between <partial for />, <partial model /> and @Html.EditorFor()
• How to validate a required checkbox (for terms of use); the [Range()] approach isn't working
• How can the navigation menu be configured to use the Web navigation? Perhaps with a TopicLookup of root namespaces?
• Determine how to client- and server-side validation on complex properties with required types if the property itself is optional (e.g., conditional contacts).
• What's the best approach for data binding dropdown lists? Enums? OnTopic metadata?

Steps (Application)

• Create a partial view for each model type (e.g., CoreContract, Profile)
• Create a view for each form to composite the above EditorTemplates
• Add markup and styles from existing forms to the above views
• (?) Create an Email.cshtml for representing the general email template

Partial views

• OptionalContact
• CoreContact
• Contact
• ExtendedContact
• Address
• Profile
• ExtendedProfile
• ModuleSelection

Forms

• AcademicInstructor
• AcademicStudent
• Demo
• Evaluation
• Newsletter
• Quote
• Training
• UserConference

Issues

• Custom Validation: Add support for detecting free/public domains (e.g., gmail.com).
• Required Fields: Create CSS to mark and prefix required fields.
• Error Styles: Update error rules to recognize JQuery-Validate-Unobtrusive classes.
• Email Instructions: Move email instructions to individual form pages, not _CoreContact.
• Follow-up Pages: Implement follow-up pages, ideally via OnTopic integration.
• Button Styles: Implement special CSS handling for check boxes, radio buttons.
• Conditional Logic: Wireup conditionally enabled form elements and messaging.

This will likely represent the largest effort in the forms migration, since much of the legacy code won’t translate to the new format.

Create Form Binding Models

The current forms rely on ASP.NET WebForms to loop through the Request.Form collection to process form values. In ASP.NET Core (as well as ASP.NET MVC Framework) the preferred approach is to instead map this input to binding models.

ASP.NET Core 3.0 Support

In ASP.NET Core 3.0 this also allows easy configuration of form validation and error messaging through the use of attributes.

Approach

There is a lot of overlap between the various GoldSim forms. Given this, a layered approach to creating binding models based on reusable POCOs is preferred. This allows new forms to be easily composed, without limiting extensibility.

Models

• CoreContact
  • Contact
    • ExtendedContact
      • ExtendedContact
    • Profile
      • ExtendedProfile
• Address
• ModuleSelection

Binding Models

• TrialFormBindingModel (ExtendedProfile)
• DemoFormBindingModel (ExtendedProfile)
• AcademicFormBindingModel (ExtendedProfile)
  • InstructorAcademicFormBindingModel
  • StudentAcademicFormBindingModel
• PurchaseBindingModel
  • QuoteFormBindingModel
  • PurchaseFormBindingModel

For more information, see the GoldSim.DotNetCore.Forms.DataModel.txt file.

Outstanding Form Issues

The forms have a number of small issues that should be resolved.

General

• Country not getting selected by default
• Modules not lined up correctly
• Emails not being sent on staging
• Hide CTAs on e.g. /Forms, /Licenses
• Treat CT, RT options as radio buttons

Trial

• Trial generating exception on staging

Purchase, Quote

• Licenses should default to 1
• Quote not rendering on staging

Academic

• Organization should be Name of Institution

User Conference

• Paper Invoice instructions in single column
• Missing dynamic logic on payment methods
• Poster Session in single column
• Indentation incorrect on radio buttons, text

Newsletter

• Needs an Unsubscribe button
• Unsubscribe button needs to add "Removal" to email subject

Implement authentication

Previously, authentication was handled via ASP.NET WebForms's Membership APIs. Those are overkill for how few users we have, and are very dated on top of it. We need to find an alternative solution that's simpler.

Open Questions

• What are the best practices for implementing authentication on ASP.NET Core?

Tasks

• Implement Azure OpenID Connect
• Expand to both Ignia and GoldSim directories
• Apply authentication to Editor, Licenses

Migrate `ConnectionStrings.config` to `secrets.json` file

Currently, the ConnectionStrings.config is .gitignore’d in order to ensure that the database password is not exposed publicly. Since we’re hosting on Azure Web Apps, however, a more elegant approach is to use the new(er) secrets format—which reads from the secrets.json in the /Users directory in development, and from Azure’s Connection Strings configuration on the server.

Steps

• Configure the GoldSim connection strings with the Azure Web App
• Register a secrets.json file on Visual Studio
• Configure the GoldSim configuration strings in the secrete.json file
• Delete the ConnectionStrings.config

This is associated with the .NET Core 3.x Migration project—but, technically, it can be done at any time.

Create Form Controller with Feature Actions

Establish an ASP.NET Core 3.0 controller to handle the routing and processing of form requests.

Current Approach

In the current ASP.NET WebForms version of the GoldSim forms, there are a number of helper functions in the master template that are called by each form. These serialize the Request.Form data into a Dictionary<> and then use that to perform a series of actions, such as sending an email.

New Approach

In the ASP.NET Core version, these helper functions will become actions on a new FormsController class. These can continue to rely on raw HttpRequest.Form content—or they can use Reflection to loop over the properties of the binding model. Regardless, the content of the actions should remain largely the same, with some minor adjustments to accommodate changes to the .NET Core API.

Research

• How does {*path} routing work if the FormsController implements TopicController and MapTopicRoute()?
• Can a FollowUpPage nested under a FormPage be routed to the TopicController.Index() action?
• Update the IReverseTopicMappingService to support complex properties. E.g., [MapToParent(true)], with property name being relayed as the (optional) prefix via private MapAsync(ITopicBindingModel source, Topic target, string prefix).
• Emails will likely need to be sent via HTTP call. While rendering a view is possible, it’s likely not practical in a reusable format since we use a custom ViewResult.

Feature Actions

Feature actions support the basic functionality of the form processing. New feature actions can be added in the future, as necessary, to extend the form behavior.

• Save form content as a new Topic via IReverseTopicMappingService
• Send form content as email via HttpContext.Request.Form
• Send “mail merged” email receipt to customer

Routing Actions

Routing actions map to individual forms. The [get] action maps a route to a view; the [post] action composes a series of feature actions to process the customer request. These include:

• AcademicInstructor
• AcademicStudent
• Demo
• Evaluation
• Newsletter
• Quote
• Training
• UserConference

Most of the logic for the forms will be defined in the form binding models (#10) and their corresponding views (#12).

Create Navigation View Components

In ASP.NET MVC Framework, the navigation elements were handled by their own controller—LayoutController—which is embedded using the @Html.Action() helper, thus allowing the logic and model of the layout to be separated from the TopicController and its models, views.

ASP.NET Core Approach

This approach is formalized in ASP.NET Core with the introduction of View Components, which achieves a similar approach by establishing a component format with their own controller-like backend code. And, unlike the @Html.Action() approach, this avoids issues with e.g. the ITopicRoutingService not being able to resolve a Topic for the request.

OnTopic Support

To support this, the updated version of OnTopic 5.8.0 includes the following out-of-the-box ViewComponents in the Ignia.Topics.AspNetCore.Mvc project:

• MenuViewComponentBase<T>
• NavigationTopicViewComponentBase<T>
• PageLevelNavigationViewComponentBase<T>

These base classes provide much of the logic needed for implementation, thus simply requiring that implementors override them to specify GoldSim’s version of the INavigationTopicViewModel<T> class, and moving the views to the appropriate folder.

Implementation

Implementation requires the following steps:

• Override the Menu and PageLevelNavigation components to specify the GoldSim version of the INavigationTopicViewModel<T>
• Implement the CallsToActionViewComponent based on the NavigationTopicViewComponentBase<T>
• Implement the FooterViewComponent based on the NavigationTopicViewComponentBase<T>
• Move the views from /Views/Layout To /Views/Shared/Components/

Migrate to ASP.NET Core

Migrate the primary website—including the OnTopic components—to ASP.NET Core 3.0.

Basic Approach

While much of ASP.NET Core remains compatible with ASP.NET MVC Framework 5.x, there are some differences, especially in terms of how the application is declared, bootstrapped, and configured. There are also some (minor) differences in the Razor syntax.

Open Questions

• Find URL Rewrite approach
• Find configuration for Application Insights

Core Elements

• Migrate csproj file to Visual Studio 2017 format
• Establish Program.cs class for bootstrapping app
• Migrate Startup.cs to ASP.NET Core format
• Introduce OnTopic configuration extension methods
• Migrate from DefaultControllerFactory to IControllerActivator
• Remove dependency on legacy TopicRepository ambient context

View Elements

• Move static files to wwwroot
• Change @Html.Partial to <partial /> tag helper
• Migrate format for @helpers to HTML @functions

Most of these changes have all been demonstrated on the Topics-AspNetCore-Sample site—though that is still based on ASP.NET Core 2.0 and still needs to be upgraded to take advantage of e.g. new support for Razor outputting functions.

Update to use new `IHierarchicalTopicMappingService<>`

OnTopic 3.8.0 makes a breaking change to the LayoutController by replacing the ITopicMappingService dependency with a new IHierarchicalTopicMappingService<> dependency. This centralizes a lot of the reusable logic for various LayoutController implementations while, importantly, also handing over control over caching to the composition root, thus allowing a single LayoutController to be used independent of whether or not the results need to be cached.

Tasks

• Update LayoutController to use IHierarchicalTopicMappingService<>
• Update GoldSimControllerFactory to construct proper dependency graph
• Update TopicViewModel to auto-initialize Children so it can't be assigned to

Update Style Sheets to Accommodate Forms

There are a handful of style sheet issues exposed by the migration of the forms to ASP.NET Core 3 which need to be fixed prior to launch.

Issues

• Radio Buttons
• Required Labels
• Form Validation Errors
• grid-container grid-x

Radio Buttons

The _forms.scss file has a selector for radio buttons that assumes that the <label /> will come after the <input />. This is fine for checkboxs, which are also included in the selector. But it isn't the preferred pattern for radio buttons since it doesn't provide a convenient way of connecting the label with an individual radio button. Instead, with the new forms, we're using the following:

<label><input name="…" value="…" type="radio" />…</label>

Given this, the radio button selectors need to be updated to use .radio label+[type=radio] instead of .radio [type=radio]+label.

Required Labels

Currently, required labels are prefixed with an asterisk in the markup. We could continue to do this, but ideally we'd instead implement a simple CSS selector that prepends an asterisk to any labels associated with a required field. Worst case, we can annotate these as class="Required", but preferably we'll instead select against jQuery-Validation-Unobtrusive's data- attributes so that this requires minimal markup.

Form Validation Errors

The new forms no longer use Ignia's client-side validation library for ASP.NET WebForms, instead using the out-of-the-box jQuery-Validation-Unobtrustive library. This means that fields that fail form validation have different classes associated with them and, thus, are no longer being picked up by the appropriate styles in _forms.scss. Styles should account for form fields, (new) inline errors, and validation summaries.

grid-container grid-x

If the PageBodySection is overwritten, and the form is wrapped in a <section class="panel body">, then everything renders and works properly. If, however, the form content is placed directly in the body, and is rendered in _Layout.cshtml using @RenderBody(), then the checkboxes (and their labels) stop working. The main difference here is that the <section /> is wrapped in:

<div class="grid-container">
  <div class="grid-x">
    @RenderBody()
  </div>
</div>

It is unexpected that adding grid-container and/or grid-x would interfere with the checkboxes and their labels. This could suggest a problem in the selectors.

Create Form structure in OnTopic

Prepare the OnTopic data structure for the inclusion of forms by introducing the following features.

Explanation

The approach described below allows a /Forms root to be created which will be populated by FormPage topics. This will keep the forms in their current location, and allow them to be associated with their own Controller instance (the FormController). Each topic will map to an action on the FormController—e.g., a Trial topic will map to a Trial() action—thus allowing individualized composition of actions. Each FormPage should be configured with, at minimum, the Title, SubTitle, and Body of the form page so that GoldSim staff can edit them directly via OnTopic.

Content Type Descriptors

• FormContainer (Container) for housing form pages
  • Only allow FormPage types to be created under FormContainer
• FormPage (Page) for representing form pages
  • Only allow FollowUpPage and Email to be created under FormPage
• FollowUpPage (Page) for representing follow-up pages
• (?) Email (Page) for representing (tokenized) email markup

Topics

• /Forms (FormContainer)
• /Forms/{Form} (FormPage)
• /Forms/{Form}/{FollowUp} (FollowUpPage)
• (?) /Forms/{Form}/{Email} (Email)

FormPage Configuration

Ideally, the FormPage content type would allow the following to be specified:

• Follow-up page URL or topic
• Email receipt URL or topic
• Store results in OnTopic
• Send email receipt to GoldSim

Note: If the above are completed, then we may be able to do away with having a unique action for each form on the FormsController. At minimum, we'd be able to centralize the logic for all of them into a child action.

Evaluate alternatives for ASP.NET Core

In getting the DotNetCore branch to an initial compiling state, a number of quick fixes were taken, especially in cases where legacy APIs were no longer available, and there was no (apparent) out of the box replacement.

These should be reevaluated to make certain a) that they indeed work as expected (and especially when the previous approach was intended to resolve an issue with the ASP.NET Framework), and b) there isn’t a more elegant approach in ASP.NET Core.

Test

• Use of <partial /> in place of @RenderPage (IndexedList)

Announcement View Component

Create an ASP.NET View Component that optionally displays an announcement.

• /Components/AnnouncementViewComponent.cs
• /Models/AnnouncementViewModel.cs
• /Views/Shared/Components/Announcement/Default.cshtml

Benefits

This approach will allow @rkossik to create announcements via the editor without developer intervention. This will also automate error-prone details due to layout shifts needed when the attaching the announcement to the footer.

Placement

The Announcement view component will be called from the following views:

• /Views/Home/Home.csthtml (for the homepage)
• /Views/Layout/_Layout.cshtml (for the footer)

Data

The source data will be placed within Web:Home Topic in the following (new) attributes:

• AnnouncementText (Text type)
• AnnouncementUrl (Text type)

Note: While there are multiple places where we could logically store this data, the homepage makes sense given that a) the announcement is displayed at the top of the homepage, and b) the homepage is already a custom Home content type descriptor, which can easily be extended. That said, this can be migrated without much impact in the future, if appropriate.

Challenges

In addition to the above, we need to account for the layout shift in the Calls to Action view component. By default, this is anchored to the footer. When the announcement is in place, it should anchor to the announcement instead. An open challenge is how to relay this data to the Calls to Action view component, which uses the centralized NavigationViewModel, making it difficult to extend.