• Intro and Part 1:

• Part 2: Fixing the fundamental mistake in web form processing (this article)

There is a problem in the foundation of today’s most popular web frameworks. It’s been there all along, but maybe wasn’t apparent in the early days. It still doesn’t seem to be apparent to most developers. At least not directly, because what these frameworks’ maintainers have done is address the symptoms of this problem without ever acknowledging the cause.

In this article and the entire series, I’m referring to traditional, server-side web frameworks. I’ve known for a long time that they’re the simplest choice for building forms. Here’s how most of these frameworks route a form’s HTTP requests1:

The problem with routing form submissions directly to action methods is lack of context. The action method receives a raw list of form data in the request body and needs to make sense of it. And making sense of it requires duplicating knowledge that is already in the view, namely which data entities and fields exist on the form and what modifications are permitted. Frameworks have partially addressed this with features like structured naming of form controls, which enables automatic mapping to trees of model objects.

But there are essential problems with this architecture that cannot be overcome. Developers must restate the list of form fields in the action to defend against mass assignment attacks. For any drop-down widget, they must reestablish the list of options that was shown to the user, to ensure that a malicious, handcrafted POST request cannot succeed in selecting a choice meant to be unavailable. Data types and formats must match those used by the rendered form. The list goes on, and complexity multiplies when the form expands with new features. It’s all an unnecessary maintenance burden.

Why did we do this? Why did we throw Don’t Repeat Yourself under the bus? Because of the popular belief that spending the time to fully rebuild the view before even beginning to process the submission can’t possibly be a good idea. That would mean…building two views (or the same view twice) on a single request! How could such a flow ever perform well enough for production use?

Try to set this concern aside for a minute. Think about a humbler design. What if we simplify things, reduce our maintenance costs, and, yes, admit that we don’t need absolute maximum performance?

ASP.NET Web Forms: The Good Part

I began my career building apps with the ASP.NET Web Forms framework from Microsoft. The critics are right: it got a lot wrong. But one thing it got right was routing form POST requests back to the page that created the form, and enabling the page to “rebuild itself” before receiving the field values.

The Enterprise Web Framework (EWF) in EWL borrows this concept; you can see how it translates to code in the previous article. And back to performance: while it might seem expensive to rebuild the page on POST, in my experience it’s never been a problem. I’ve also learned that a framework can use deferred execution (as EWF does) to avoid fully rebuilding the page all the way through to a finished HTML document. It can merely create enough of a skeleton to know what and where the form fields are.

Zooming in on fields

Take the expression for the movie price control from the previous article:

movieInsert.GetPriceFormItem( minValue: 0, maxValue: 100 )

As I mentioned there, this is all you need for an HTML input type=number control that is bound to the movie price field. It handles the control, the label, the validation rules, the display of error messages. Mass assignment attacks are not possible, so there’s no other place where you need to whitelist the price field, or blacklist other movie fields. And again, as I stated in that article, there is no model class anywhere that supports this page. There is only the database, and automatically generated code.

The formatting of the decimal number as a string, for HTML, and the parsing of a submitted string back into a number, are both encapsulated within this expression. It is not possible to have any type of a formatting mismatch. If you needed to use some type of custom widget with its own formatting requirements, you would likewise have both translations (number → string and string → number) defined in the same place.

And take the drop-down list with movie ratings:

movieInsert.GetRatingDropDownFormItem(
  DropDownSetup.Create(
    getRatings().Select( r => SelectListItem.Create( r, r ) )
  )
)

IReadOnlyCollection<string> getRatings() => [ "G", "PG", "PG-13" ];

The same list of ratings is used for rendering and for validation. It’s impossible for a value that is not listed to make it into the database via this form, even if such a value were valid according to database integrity constraints. This is not just a maintenance time saver; it’s also the complete elimination of a security risk.

Imagine having a drop-down list for setting a user’s role, where the two choices are “editor” and “normal user.” What if there were a third role, “admin,” defined in the database but not accessible on this particular page? Do you see the value of knowing, for sure, that the “admin” value cannot be set maliciously through your page? The value of never having to open up Postman or another HTTP manipulation tool to test for such an attack vector?

Do you see the power, and superiority, of integrating validation/POST logic into the form-rendering code?

I build and maintain web applications. Specifically, enterprise web applications, according to Martin Fowler’s definition. And I’d still be building and maintaining them right now too, if it weren’t for the white-hot ball of fire inside me that won’t let me rest until I trap myself in this Substack editor, kicking and screaming, and tell you what I’ve learned.

My development experience lies wholly in the Microsoft universe, beginning with Visual Basic and Active Server Pages, continuing into .NET, C#, and Web Forms, and finally moving to .NET 6/7/8/9. But that’s not the interesting part. The interesting part is that along that journey, in my foolish youth, I decided to bushwhack off the Microsoft-recommended trail and ended up in the wilderness of custom web frameworks. I worked with a few others to build what we call the Enterprise Web Framework (EWF), which is a part of the larger EWL.

After two decades of iteration and improvement, this is likely a good place to be. Our small group has shepherded several applications from their Web Forms inception to their modern life with .NET 9. We have protected their essential business logic from the destructive “total rewrites” that are common in the industry. But what’s certain is that this web framework is unique, and as the only steward of it at the moment, I feel obligated to get the word out.

With that said

This article is part one of the forms series:

• Part 1: Forms in web apps: a new approach (this article)

• Part 2:

Let’s start with the framework’s approach to forms, which are a key part of these applications. Consider some questions:

• What if you could build forms in an entirely programmatic way, with no separation of logic between HTML and code?

• What if your validation/post logic was inline with the rendering of the form?

• What if your forms could talk directly to an automatically-generated data access layer, at least in the simpler parts of your application where separate domain modeling isn’t necessary?

Here’s what that looks like, in the context of a movie database app that is intentionally similar to the one in the Blazor tutorial. Take a page that lets users add new movies:

This is the C# code for that page:

Aside from database schema (a Movie table with a few columns), what you see above is all there is. No model class, no scaffolded code, no HTML. Just a small amount of application-level configuration (commensurate with what you’d see in Blazor or other frameworks), some generated code, and a URL pattern defined at the parent level:

See this built in a 1-minute video

But why?

Why abstract away the HTML?1 Fully-programmatic UI is certainly not a good choice for every page in every application. It’s not good particularly if some of the people making changes are web designers, who may feel quite comfortable editing HTML-based templates but would never touch C# code.

But it can be an amazing time saver for full-stack developers. Notice that all of the logic for each form control is located together. The control itself, the label, the validation rules. You aren’t forced to jump around to different files, or scroll to different parts of a file, to add a new control to the form.

You may wonder how the validation logic on this form even executes, or more generally how a POST request is processed. Answer: the page UI is built again, just as it was on the initial render. And during this process, the validation methods for each control are registered with the PostBack object. After the framework finishes building the UI, it executes the validations in the PostBack followed by its modificationMethod, which in this case performs the SQL insert of the new movie. Finally, it executes the post-modification action, which returns the user to the Movies list page.

It would be fair to consider this rebuilding-on-post a slight performance compromise. In practice it’s not a problem due to other optimizations in the framework. On the flip side, it elegantly prevents overposting (i.e. mass assignment) attacks, because the full context of the form is available during validation. In other words, the framework knows which fields the user has available to edit, and will only accept submitted values for those same fields.

For next time

This is the first part in a series about forms, and I’d love to expand on these brief explanations and also cover the more advanced features of the framework. Please let me know if you have questions or if there are specific topics you’d like me to write about.

Leave a comment