Today I’ll talk a bit about a redesign I did, for my forms generation library. Even though my first design worked, I wasn’t happy with the overall outcome. I felt like the library wasn’t nearly extensible enough. So, I sat down and redesigned everything.
The good news is, users of the library will see very few changes. Mostly, I just changed where the code lives, and how it interacts with the rest of the library, internally.
For instance, the old design had most of the logic for rendering controls inside an internal form generator class. That meant I needed a new form generator anytime I added a new control, or whatever, to the library. For example, if I added support for generating HTML elements, that meant writing a new form generator class. If I added support for a third-party library, that meant writing a new form generator class. Starting to see a pattern?
Instead, I took the logic for rendering a control, from the form generator, and moved it out into the attribute class. So, for instance, the logic that renders a MudTextField component, that used to live inside the FormGenerator class (and some helper classes), now lives completely inside the RenderMudTextFieldAttribute class. Even the code that walks through an object and recursively steps into child properties, was also moved into the RenderObjectAttribute class.
The result of pulling all that custom code out of the form generator was, the form generator itself suddenly became simpler and more generic. In fact, now, the form generator really just visits each property that’s decorated with an attribute, then gives each attribute an opportunity to render itself, on the form. That’s pretty simple.
Along the way, I took all the MudBlazor specific code and moved it into a library called CG.Blazor.Forms._MudBlazor. That way, you only need pull in MudBlazor assemblies if you decide you want to render MudBlazor components in your form.
I then went back and wrote RenderXXX attributes, to render a handful of standard HTML elements, for forms. That means all the standard HTML elements like checkboxes, sliders, selects, etc., all are now suported – in addition to the existing MudBlazor components that the library originally supported.
I also added support for the fluent-style validation, from the Blazored.FluentValidation NUGET package. That means, if you want your generated form to used a fluent-style validator, simply decorate your model with the RenderFluentStyleValidator attribute, from my CG.Blazor.Forms._FluentValidations NUGET package.
I’ve also just finished adding support for Syncfusion controls. I only tackled the basic controls that might typically get added to a form. The rest are up to you. :o)
Finally, I’m considering adding support for other commercial packages, such as Infragistics, or Telerik. That may take some time though, since I don’t have a license for those packages. I’ll have to figure something out for most of those packages.
- The code for my forms generator is published HERE.
- The NUGET package for my forms generator is published HERE.
- The code for my validations adapter is published HERE.
- The NUGET package for my validations adapter is published HERE.
- The code for my MudBlazor adapter is published HERE.
- The NUGET package for my MudBlazor adapter is published HERE.
- The code for the Syncfusion adapter is published HERE.
- The NUGET package for my Syncfusion adapter is published HERE.
Photo by Anthony Tran on Unsplash
