Category Archives: ASP

One Big Control or Lots of Little Ones (redux)

Filed under .NET, ASP, Rants, VB Feng Shui

Some time ago, (or here in the wonderfully virtual web world), I questioned the whole aspect of all this pile of controls in ASP.NET. Of course, you’ve got the grids and listviews, and you also have all the radio buttons, checkboxes. But then you’ve got a separate validator for each kind of validation you want to use, and even validators to let you combine other validators in “AND” and “OR” logical relations.

My thoughts were “Jeez. this is madness.”

Wouldn’t a single control that you could adapt to different display behaviors, validation rules etc be much easier to work with and create a more maintainable solution?

Well, apparently someone at Microsoft had the same bright idea, at least with the new ListView control in ASP.NET 3.5.

Take a read of Fritz Onion’s article in the latest MSDN magazine.

He describes the new ListView as a control that can “literally replace all other databinding controls in ASP.NET. That’s right. Every last one.”

Now, if they’d do the same for that validation nonsense, we might be getting somewhere!

daBlog’s New Medium Trust Made Me Sad (for a little while, anyway)

Filed under ASP, Blogging, dasBlog

Oops, don’t try this:

      Dim req As System.Net.HttpWebRequest = System.Net.WebRequest.Create(URL)

on an ASP.NET page in a web app marked with MEDIUM trust (as the new dasBlog 2.0 comes configured, as in this web.config file)

<?xml version="1.0" encoding="utf-8" ?>
        <trust originurl="" level="Medium">

Guess that’s one of the no-nos of medium trust.

In my case, the only place I’m doing this is where the incoming URL is a value fixed in code, not something coming from user input, so I don’t believe it can be usurped for unscrupulous uses (I think I just blew my “u” quota for the day<g>) .

If you’re wondering, that code came from the ICQ status request bit I coded up and blogged about here.

To solve it in my case, I went back to normal trust level.

Anyone know how you’d handle doing this in medium trust? 

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.