We ASP.NET Geeks Have Lost Nothing

Rob Conery—the creator of the very, very slick SubSonic persistence framework—writes that he has forgotten a lot of HTML and javascript. He ain’t lying. I took his little challenge and failed miserably. Then again, I realized how glad I was that I had not had to struggle with, nor implement, manual form handling in quite some time. While I might have lost something by becoming an ASP.NET junkie, at the same time I gained a lot of very, very powerful tools to make complex, interactive web applications without having to worry too much about how to wire up HTML forms.

Here is a more realistic version of Rob’s Challenge:*

Create a form to collect registration information for an event. We require you capture:

  • Full contact information (Name, address, email, etc)
  • Full demographic information (Industry, employer size, buying powers, subject matter focuses)
  • Session registration selections
  • Hotel reservation information.
  • User should not be presented with a massive gargantuan form. It should be broken down into bite sized chunks.
  • User should be able to proceed forwards and backwards through the series of forms and edit information at their whim.
  • Present the user with a confirmation screen showing all of their choices before persisting the information to a database, and into a separate CRM system via web services.

This application must be ready to go live by tomorrow morning.

*This is really, really realistic. I wrote two of these wizards last week.

How would you tackle this problem using ‘classic’ techniques? And how long would it take you to make all that manual handling of POST data bulletproof?

Personally, and unlike Rob, I don’t feel disconnected from my “cooler” brethren. I feel like I have a superior toolset to make complex, interactive web applications than folks still handling html forms by hand. It is OK to be a .NET guy.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Rob Conery

    See, I don’t think this is complex. HTML and Javascript are pretty dang easy. If you ask me the framework is complex :). We’re the only ones who think in terms of this “classic” versus “new”. I totally agree that abstraction through reusable controls is a great thing, but you don’t get works of art from WalMart :).

    Not disagreeing – I like ASP.NET. To me, however, HTML and javascript are fundamental and we really should know it more.

  • madr

    To me, which works “by hand” in eclipse, this task isn’t really a challenge (even if it surely would take a whole day to create the form).

    The HTML is really easy in this case. It’s just about some input elements and some structural block elements in the bottom, some presentation with CSS and some javascript interaction.

    The input validation is the tricky part (as always when it comes to forms), but it’s all about checking the obvious patterns (strings, integers, floats, email-addresses and so on) and this is done best with regular expressions. There are quite many web resources collecting regular expressions, so anyone with normal google skills would be able to find the right expressions for the task.

    It’s all about habits, I guess.

  • Joe Brinkman

    @madr – the form is not the hard part, the navigation and state-handling logic is the tricky part. Although, quite honestly many of the MVC frameworks already handle navigation quite well. So well in fact that I find them much more robust and flexible at handling this task than the ASP.Net wizard.

    Personally I don’t care for the approach that MS used for the wizard since it requires the entire presentation logic for the whole wizard to be captured in a single page, which ultimately results in most of the navigation logic being handled in the code-behind. You really have to work very hard to separate navigation logic (which is really business logic) out of the page. Check any reasonably complex page built using the wizard control and you will find a ton of code in the code-behind.

  • Dr Livingston

    Umm…

    I would say that you do lose out on something, and that is the skill of developing with a technology, that being HTML it’s self. I would rather get my hands dirty with HTML – and CSS for that matter – and whilst the time frame may be greater, I still maintain a hold on my skills, and also given the opportunity to continue to grow those skills.

    That is what you lose out on, when you are using predefined, preset automated frameworks.

  • http://ian.sundermedia.com TheLunchBox

    I personally think that understanding HTML and JavaScript are critical to being a web developer whether you’re working in ASP.NET or not.

    How do you write CSS without knowing what markup your generating?
    How do you write custom web controls without understanding HTML?
    How do you write custom AJAX controls without understanding Javascript?

    I personally take a lot of pride in the fact that I know what kind of markup my ASP.NET code is generating. Understanding all of the tools you work with is part of what makes you a professional. Publishing archaic, non-compliant markup makes you look like you don’t care about understanding your craft.

  • wwb_99

    @Rob: Yes, HTML and Javascript are pretty dang easy. I think the challenge is more making a pseudo-stateless medium behave in a stateful way across multiple platforms without driving yourself to drink. MS has already fought that battle so I don’t have to on a daily basis. And I did spend a few quality years building PHP applications so I have the drinking habit already.

    @madr: As Joe points out, you missed the point. If anything it takes longer to type in (yes, I do not drag-n-drop) the asp.net web controls onto the page. But I am not also typing out the state handling logic. Nor am I worrying about testing the underlying state handling logic in multiple browsers and network scenarios.

    @Dr. Livingston: Not sure about you, but nowhere in my current job description does it say “sharpen your html skills regularly.” It does say “make really cool applications really well and really fast.”

    @TheLunchBox: I don’t disagree. Especially when it comes to debugging things that crazy, huge automated frameworks do, you need an unerring knowledge of how all those things you note interact. But that does not mean you need to spend hours and days reinventing the form-handling wheel. I would also note I never said anything about producing archaic, non-compliant markup in the post–it was all about the mechanics of form handling.

  • http://www.brothercake.com/ brothercake

    Maybe you’re in the wrong job then – staying at the forefront of best practise is part of my job – because *how* is just as important as *what*

    The real question in this is what is the quality of .NET’s generated HTML like? Is it valid, semantic and accessible code? Does it work without JavaScript? Can I access all widgets with the keyboard or using a screenreader? Those are the questions I would be asking.

  • wwb_99

    @brothercake:

    Maybe so, but then again I have worked with alot of very high-end interactive design studios in my days and their code would make you cringe. Insofar as staying on top of current best practices, I tend to stay far deeper on the server-side of those as that is what is needed these days. Concentrating on the client is a comparative black hole.

    As for your 2nd paragraph, stay tuned for the next post.

  • honeymonster

    Yes, the quality of ASP.NET generated HTML (actually XHTML) is excellent. You need to use the control adapters for the navigational controls, though; otherwise they will generate ugly table-based layouts. In general you can override and micro-manage the html if you so choose, thanks to the unique ASP.NET templating.

    Yes, the XHTML is accessible. Better still, because you design your page with components, the accessibility can to a large extent be implemented by the components. E.g. the Menu control will by default (overridable) generate a “skip” link to skip over the links of the menu. All relevant controls has an accesskey property which let you assign keyboard shortcuts. And no, if you want to assign access keys to individual menu items you should not use the Menu control; or have code modify the links a posterori.

    The validation controls works with or without javascript. They generate javescript which will work in all common browsers. Even if javascript is turned off, the controls will still validate server-side. You just don’t get the immediate validation.

    The AJAX UpdatePanel allows partial page rendering. You set it up declaratively in the template. It does not interfere with your code, it just updates a part of the page using AJAX. It *also* degrades gracefully when javascript is turned off; falling back to POSTs.

    I like to know my HTML/XHTML/CSS and JavaScript. But I don’t like to be forced to write it every time. When I come to trust my components – whether built-in, developed by me or aquired from 3rd parties – they offer me tremendous productivity. Of course for that to work the framework must offer excellent composability. ASP.NET is not quite there, but it is by far the most composable framework out there.

  • http://www.dotcomwebdev.com chris ward

    Everyone still needs to know the basics incase a client throws in an odd requirement!

    The ‘project’ doesn’t reflect the real world.

    For example…

    Implement a .net calendar control inside a .net AJAX update panel, then reload the panel a couple of times and you will discover that the styles are dropped.

    The markup the .net engine outputs is sloppy as hell, and totally inaccessible (disable js and have fun?).

    You can plug these things up if you understand some basic concepts, so no… fan of the blog Wyatt, but I don’t agree with this post, sorry!

  • stikkybubble

    Not having ever used ASP.NET, this just sounds normal to me. Mind you, it would probably take me the rest of the day, but I don’t claim to be an expert.