I acquire consistently admired to assay adapted brands of swiss fake watches affluence watches. If comparing the above brand, there are replica watches uk not abounding differences you can accretion distant from the above of replica rolex uk the replica. You can accretion some of the best Patek Philippe replica watches and acquire abolishment to rolex replica say added than your architectonics or you could accretion bigger above and a lower replica hublot watches casting and achieve your best easier.

One Big Control or Lots of Little Ones — Visual Basic Feng Shui

One Big Control or Lots of Little Ones

Filed under ASP, Software Architecture

I’ve been delving into ASP.NET programming lately and one thing that immediately struck me as odd is just how many controls end up on an ASP page.

A typical data entry page consists of, generally, lots of labels and textboxes, a few option buttons or check boxes, even fewer combo boxes and list boxes, a grid maybe, and few buttons (buttons, links, whatever they happen to look like).

Granted, depending on the application, you may have a few particular screens that are more complicated (say, a scheduling screen), but by and large, for general data input, that about sums it up.

But when I look at what’s involved in ASP.NET to make that happen, it’s almost mind boggling.

Of course, you have a label control for a particular field, you have the field itself, but then you have separate validator controls for each kind of validation you might want to perform. Add in tables to get things to line up nicely

To me, it seems much more logical to have one “data input” control, that can handle all (or rather the most common) data entry tasks via properties.

Want a caption above the input box, rather than to the left of it; set a property. Want the text to be validated a alpha numeric, but only including A-F, and it must be > 4 chars, less than 10, blah blah; set a property (or two). What this field to be a choice between True/False; set a property to make it a radio button group, a list, or a drop down combo box.

Ages ago, there was a UI package called SmartUI. Looks like it’s now sold by Xceed. No idea whether it’s any good now. It was ok back then, although it had it’s share of issues. But I always thought the idea was right. One control that could do all sorts of the most common data input type tasks, just by dropping it on a form and setting a few properties.

I completely understand the idea of “modularizing” functionality and the ASP control model definitely does that.

So my question is, is that the best way?

All those controls eventually just render HTML anyway, so is there a penalty for one big control vs lots of little ones rendering that html?

Does it make the page easier for the user to work with?

Do separate little controls make it easier for the developer?

Microsoft used to say that INI files were the absolute best way to store your application settings. Then it became the registry, and INI files were passe. Now, it’s back to INI files…albeit with a lot more tag stuff, funny angle brackets and often terrible formatting…oh, right, I mean XML files.

My point is, I’m not one to just accept Microsoft’s take on a topic, no matter how much framework they’ve thrown at it. 

And I’m wondering if their control model might be another one of those reasons to break with the pack.


  1. Ralf says:

    I’m guilty of the mega-OCX crime myself. I have one favored tool in my box that started life as an alternative to the VB combo, but has picked up two additional unrelated user controls along the way. It’s soooo simple to just plop that bad boy into a new project and have my favorite things ready to go.

    It’s ~350K, but the way I understand it, the footprint is a one-time penalty, no matter how many times it’s invoked. And you are correct: it doesn’t seem to take any longer to initialize than the not-so-huge combo-only version of my toy. Maybe modern hardware is picking up the slack?

  2. Darin says:

    "I think Microsoft’s next push will be to store snippets of XML code within registry keys."

    That made me spew coffee on my monitor.

    You better hope I didn’t short it out!

    And granted, If I’m working in an in-house IT shop, slapping a web page together with separate little controls is likely the quickest way to get to "done", so I’d probably go with that.

    But I focus exclusively on commercial software offerings, so I’m always looking for ways to leverage my work as much as possible, and to avoid creating any more code than I have to, even if it’s just rote cut and paste stuff.

    What’s becoming strange, though, is with a web app, how do you categorize the back end? Is it traditional IT work (since it generally never leaves servers under your control) or is it commercial work (since it’s consumed by a mass market, not just your inhouse employees)?

    As for the "monster widget", from what I’ve seen so far, the init times seem to be completely manageable, no matter how big the widget gets. I may be just missing something, though.

    I remember some pretty monster OCX controls that could load with no more speed issues than the built in VB controls.

    I know what you mean about the cut and paste mentality, though. There was a time when code samples and snippets were pretty few and far between.

    Now, though, damn near anything you need is posted somewhere, it’s just a matter of finding it. And that’s both fantastic and a little disconcerting.

  3. Ralf says:

    I think Microsoft’s next push will be to store snippets of XML code within registry keys.

    The question you pose is interesting, but I fear, impossible to answer consistantly. The "best way" wholly depends on the requirements… an internal behind-the-firewall corporate app might get away with 500 widgets on a screen, whereas something intended for mass consumption probably can’t.

    Coding the 500-widget solution is relatively simple; the other way isn’t. Making somebody wait 15 seconds while your monster widget initializes may or may not be okay.

    Object Oriented Programming has always been about making developers happy, not about producing better product. If the goal was Quality Above All Else then we’d all be hand-crafting each widget from scratch every time. Each would be purpose-built for the exact circumstance, without a wasted Method or Event. They’d probably be coded in assembly for performance, too.

    Oh, modularity is a wonderful thing — done right it makes impossible projects possible and keeps developers sane. But ANY good thing can be taken too far, which is what I think is happening with some of the new MS technologies.

    Or heck, perhaps the current developer climate is to blame. It used to be usenet was full of folks asking, "how do I code this…?" but now you’re more likely to see, "where can I download something that…?" It’s a consumer mindset, baby! Developers no longer WRITE software, they piece precoded bits together and the only code they write is the glue that holds it all together.

    Ask Timmy to sort the contents of a list and he’ll look for the .Sort method, and freak out if there isn’t one. I swear, I have actually seen this happen with my own eyes.

    Keep adding rarely used methods because nobody wants to code around them, and soon your widget is pushing a megabyte and takes 2 seconds to initialize per instance. Oh sure, it plays MP3 files and has a cool skinning engine, but where’s the international support? *sob*

    So I refuse to answer your question on the grounds it may cause me to stop using modular technology and break out MASM 6…

Post a Comment

Your email is never published nor shared. Required fields are marked *