Oqtane Blog

Blazor components can accept parameters that are used to pass information from a parent component to a child component. This is a powerful feature however in a real-world application such as Oqtane where you may have many layers of nested components, it can be quite cumbersome and verbose if you need to pass a parameter value explicitly through all of the hierarchical layers. Cascading parameters solve this problem by providing a convenient way for an ancestor component to provide a value that is then available to all descendent components.

This past week I had the opportunity to do presentations about Blazor and Oqtane at a number of community events both locally and internationally. This required me to update my slide deck from the DNN Summit to include the latest information from Microsoft about Blazor, including clarification of the client vs. server hosting models, release schedule, and more technical details about how the technology works under the covers. And now that Oqtane has been officially released as an open source project, it also allowed me to include some information about why I created the project, the technical goals of the original proof of concept, and the reception by the .NET community.

In the vast majority of cases when you are using Blazor you will never need to worry about assembly loading. However in a modular framework like Oqtane, where you need to be able to create independent components which are loaded dynamically at run-time, assembly loading becomes a critical requirement. And although this blog is primarily focused on Blazor, there are some fundamental aspects of assembly management in .NET Core which needs to be explained as there are obviously some dependencies in common.

Blazor applications are based on components. A component is an element of UI that handles user events and defines flexible UI rendering logic. One the most significant benefits of components is that they promote a high level of code reusability. Under the covers, components are .NET classes written in the form of a Razor markup page with a .razor file extension. Razor is a syntax for combining HTML markup with C# code designed for developer productivity. Razor components are compiled into .NET assemblies that can be shared and distributed as Nuget packages. At run-time components render into an in-memory representation of the browser DOM called a "render tree" that is used to update the UI in a flexible and efficient way.

Routing is essentially the "brain" of a web application. In a traditional ASP.NET MVC application, routing is the process of directing an HTTP request to a controller which is running on the server so that it can serve up content to a client browser. In contrast, in a single-page application (SPA), the router responds to navigation actions directly in the client browser without making a request to the server to fetch new content. In both cases, routers utilize route templates which are basically patterns that describe the locations to match in order to trigger a specific rendering.

Oqtane was originally conceived as a proof of concept to determine if Blazor would be capable of supporting a modular application framework. Taking inspiration from DotNetNuke, it utilizes many concepts from this pionering open source .NET CMS. Specifically it supports multi-tenancy, a fully dynamic page compositing model, designer friendly skins, extensibility via third party modules, and a familiar data model. That being said this was not a migration project; Oqtane was built from the ground up using modern .NET Core patterns and technology.