Oqtane Blog

Strategically timed with Microsoft BUILD 2020 and the release of .NET Core 3.2... we are pleased to announce the official 1.0 release of Oqtane, an open source Modular Application Framework for Blazor.

In previous blog posts I have said that Oqtane was "heavily influenced and inspired" by DNN. I realize this statement is rather vague so I thought it may be helpful to provide a bit more detail in order to help clarify the similarities and differences.

Most frameworks are created with a core philosophy in mind. A core philosophy provides a central theme for all major product decisions. The core philisophy behind DNN was extensibility, and as a result almost every core feature was developed in a manner which could be enhanced, extended or overridden. The core philosophy for Oqtane also includes extensibility but places a much greater emphasis on performance, which is highlighted by the Oqtane brand name whose root word octane is a standard measure of the performance of engine fuel. Performance is a very general attribute and for a framework like Oqtane it needs to encompass a wide variety of characteristics such as the speed of installation, familiarization, development, deployment, and interaction with the product.

The question of Oqtane vs DNN has come up numerous times in recent months. In general it seems that people are trying to understand the rationale behind creating a completely new open source project as opposed to evolving the existing DNN project. In order to answer this question it is helpful to step back in time and review the events which got us to where we are today.

Uploading files is a very common requirement in most web applications however Blazor does not currently have a native file upload component. Steve Sanderson blogged about this a few weeks ago and even posted a sample project on Github. Oqtane has a need to upload module and theme packages for installation at run-time so we had also implemented our own solution some time ago - which I was happy to discover closely aligned with the approach suggested above.

Regardless of the deployment approach, Blazor leverages a common component model for developing applications. In theory this offers a high level of flexibility and reusability as it allows you to develop a single codebase which can then be deployed in multiple ways. The ability to write once and run anywhere is a very desirable capability if you want your application to be available in as many forms as possible ( ie. web, mobile, desktop ). This capability is also especially helpful at the present time to workaround some of the limitations in the client-side development model. Specifically it allows you to develop a client-side application using the more productive server-side development approach ( which offers full debugging support in Visual Studio 2019 or VS Code ) and focus your efforts solely on testing your application in the client-side model.

It was an honor being a guest on the show again after an 8 year hiatus... Richard Campbell and Carl Franklin continue to provide the creative insight and passion which makes .NET Rocks! the premiere podcast for Microsoft .NET developers worldwide. This episode focused on Blazor and Oqtane.

Based on the hierarchical model in Blazor, it is trivial to call a method in a parent component from within a child component. But what if you want to do the opposite? A use case for this type of scenario might be a data entry form where a variety of different sections are rendered as child components; however, there might only be a single Submit button for the form which is inside the parent component. So when a user clicks Submit the application may want to call a method in each child component to perform validation or even save the information to a database. Let's explore a few different options to accomplish our goal.

Those of us who have been closely following the evolution of Blazor over the past year have been eagerly awaiting some official guidance from Microsoft in regards to application security. This was finally delivered in the .NET Core 3 Preview 6 release in June where they included some new components, examples, and docmentation related to implementing authentication and authorization in Blazor applications.

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.