Do you like ASP.Net?

[Kasracer]

I have worked with ASP.Net for a decent chunk of time and it does have quite a few decent controls and it makes web development insanely easy but there are two things that really bug me in ASP.Net.

• ViewState & ControlState
• PostBacks

ViewState and ControlState seem to be attempts to force a state to work in a stateless environment. The web is stateless and it feels akward and almost hacky to me that objects gets serialized and put into a hidden field. The web wasn't meant to work that way and it adds extra bloat to the pages. Let's face it, ASP.Net can be used well to eliminate this but I have not worked with one developer who did so. In fact, everyone I've worked with or seen that use ASP.Net heavily rely on ViewState or ControlState.

PostBacks are my #1 annoyance on the web and ASP.Net makes it not only easy but practically encourages doing so using events. They can break back and refresh functionality in the web browser and they're not intuitive as it will cause the screen to flash and make the user lose their place at times (depending on what the postback is doing) especially if the user started to enter information into another box while the browser is trying to post back (I can't tell you how many times I hit tab on an input, start typing in another input and then the postback finishes and I lose the data in the second input. Ugh!).

Am I the only one?

[mendhak]

Considering that I am the first person to reply to your post, thereby making two of us - yes, you're the only one.

Having looked at PHP and ASP for a long time, ASP.NET gives you more power. In order to get this working, they have had to make use of whatever they could within this stateless framework and considering those limitations, I think they've done a great job.

In an old PHP/ASP "app", I'd have had to perform the maintenance of values myself. In ASP.NET, the basic functionality of maintenance is done for you. In both cases, we're making use of some mechanism that could easily be said to be against the way the web works. And I would rather spend that time I saved on working on the main functionality of the website instead of making hundreds of tweaks to make it look right.

About that, though - To say that the web wasn't meant to work this way is too much of a purist statement. In such an ideal world, we'd only have HTML pages with one DIV on it.

I understand what you mean though - a POST should post to a page which in turn will process those values and do something with it. Fair enough, it should, but the way postbacks have been implemented doesn't really deviate that far from the way things were once done, albeit in a more generic, framework-like manner.

[Kasracer]

Considering that I am the first person to reply to your post, thereby making two of us - yes, you're the only one.

I understand this is a mostly Microsoft site and I wasn't trying to insult anyone or anything like that (in case that has driven away anyone from posting). I'm truely interested in hearing everyone's opinion regarding this since many of us use ASP.Net on a daily basis.

I'm not trying to knock ASP.Net. I use it daily at my job and it's a great language. There are just somethings about it that bother me.

In an old PHP/ASP "app", I'd have had to perform the maintenance of values myself. In ASP.NET, the basic functionality of maintenance is done for you.

What do you mean by maintenance? If you mean automatic value population on post-back then asp and php can do this for you as well except that instead of everything being done for you in an IDE, you have to write a little script (or pop in one of the many popular PHP frameworks).

I understand what the design view and IDE can give you but I wouldn't write off PHP, ASP, CGI, JSP or anything else right away as they all have this ability. If you're making a custom server control in ASP.Net and are not utilizing ViewState, you also have to handle this yourself by inheriting the IPostBackDataHandler (or something like that) or iterating through the Request.Form dictionary.

I would rather spend that time I saved on working on the main functionality of the website instead of making hundreds of tweaks to make it look right.

I'm not sure what this is supposed to mean. No matter what technology you use, you have to design the site and that design will work in any framework. It sounds like you're saying ASP.Net helps you to avoid making "hundreds of tweaks to make it look right" but that's not true as the design process will be the same.

I once took a site designed for PHP, took the template and threw it in an ASP.Net page and it worked just fine. I also had to do the reverse (ASP.Net -> PHP) to allow some designers to work on a linux server when testing the site. Unless the site is designed poorly, there shouldn't be any tweaks to make it look right because of the language. That just seems silly to me.

About that, though - To say that the web wasn't meant to work this way is too much of a purist statement. In such an ideal world, we'd only have HTML pages with one DIV on it.

I don't think it's a purist statement at all and your idea of only HTML pages with one DIV seems silly. The web is stateless and all web technologies have been able to deal with this (HTML, XHTML, CSS, JS, JSP, PHP, ASP, ASP.Net, ColdFusion, etc) so there is no reason why it would "only have HTML pages and one DIV on it". As far as I know, ASP.Net is the only server side technology that has a built in system for trying to create an environment with a state when there is no state. I'm sorry but it just seems like an odd and akward solution to me.

I understand what you mean though - a POST should post to a page which in turn will process those values and do something with it. Fair enough, it should.

but the way postbacks have been implemented doesn't really deviate that far from the way things were once done, albeit in a more generic, framework-like manner.

I haven't seen any non-ASP.Net sites do this in a very long time but I'll take your word for it. It's a bad user experience IMO no matter which framework it's run on.

[penagate]

All server-side languages in practical commercial use enforce the concept of state over a stateless protocol. PHP does this with session IDs either stored in cookies or appended to the URL.

State is an application concept. HTTP statelessness is a protocol concept. To say that sessions or viewstates are applying state in a stateless environment is to muddle two layers of architecture.


(Also, I think you mean auto-postback where you've referred to postback. Any POST form submission is a postback but auto-postback is the supreme annoyance which you describe. Background postback (AJAX) is superior since it does not interrupt the user's workflow.)


On the point of state again: I once created a small web application (using PHP) that utilised JavaScript to postback while switching between tabs of a form. That's definitely maintenance of application state in my view but does not break the HTTP model. (And yes: it worked without JavaScript too. Without scripting support, the data simply wasn't saved until all tabs were filled out and the whole form was commited in one go.)

When people talk about the web as being 'stateless' they refer to the concept that any idempotent resource accessed in the same manner should consistently yield the same result — in other words, idempotent requests to resources should be deterministic. When people talk about web applications breaking statelessness, they ignore the fact that state forms a part of the request — even if the client-side state consists of only a token identifying state data stored on the server, and thus the token might not change when the data does, the token is merely a reference and so the request differs in content even if the body and headers sent from the client are identical.

[Kasracer]

All server-side languages in practical commercial use enforce the concept of state over a stateless protocol. PHP does this with session IDs either stored in cookies or appended to the URL.

Session and State are different (otherwise ASP.net wouldn't have seperated them). A session is a specific users logged into an environment but a state is how something is currently displayed and keeping that for the next change (hence why ASP.Net serializes data then deserializes it on postback).

State makes ASP.Net controls handle more like desktop controls. Session is really just a connection that allows the server to know its the same user / connection.

State is an application concept. HTTP statelessness is a protocol concept.

I agree but...

To say that sessions or viewstates are applying state in a stateless environment is to muddle two layers of architecture.

I'm not sure how you draw this conclusion from your previous statement. The stateless environment is not the protocol that delivers the environment but the environment itself (the HTML/XHTML page the browser renders).

State in ASP.Net is applied to the Html/Xhtml being delivered to the web browser. The HTTP protocol is just how it gets there.

Also, I think you mean auto-postback where you've referred to postback.

Yes and no. It's just semantics but .Net refers to a postback as a page posting to itself for an event for other reason. auto-postback implies the page is somehow doing this by itself without user assistance.

Any POST form submission is a postback

Not true. Any POST is a POST. Any postback is a postback. They're different in that a POST is sending form data to a specific page but a postback implies that the page is posting data back to itself. .Net typically posts data back onto itself but many other frameworks do not so they're not the same (but use the same technology).

Again, just semantics and not a big deal

auto-postback is the supreme annoyance which you describe

Background postback (AJAX) is superior since it does not interrupt the user's workflow.

Again, semantics but it can be either a post or get with Ajax so it wouldn't be a background postback.

On the point of state again: I once created a small web application (using PHP) that utilised JavaScript to postback while switching between tabs of a form. That's definitely maintenance of application state in my view but does not break the HTTP model. (And yes: it worked without JavaScript too. Without scripting support, the data simply wasn't saved until all tabs were filled out and the whole form was commited in one go.)

Sure I think you could say that's a form of maintaining the application state but my point being is PHP wasn't serializing data into hidden form inputs as it didn't need to, it could logically progress without costly and ugly serialization / deserlization. My problem with ASP.Net's implementation wasn't that it was keeping where the user was in the page but the fact that it's taking almost exactly the same approach as a desktop application in that it's storing everything in a serialized piece of data that makes the page heavier than it needs to be. It just seems sloppy to me as there are more elegant solutions (even when using ASP.Net).

Though, we are not discussing an HTTP Model as HTTP is just a protocol that the web uses to deliver content.

When people talk about web applications breaking statelessness, they ignore the fact that state forms a part of the request — even if the client-side state consists of only a token identifying state data stored on the server, and thus the token might not change when the data does, the token is merely a reference and so the request differs in content even if the body and headers sent from the client are identical.

Like I discussed previously, I'm not trying to say it's wrong or bad to pass any data to keep the same progression within a web application. I just disagree with the way it's typically handled in an ASP.Net application in the form of serialized data.

[penagate]

Session and State are different (otherwise ASP.net wouldn't have seperated them).

On a purely practical level, yes. On an academic level, sessions are a manner of implementing data persistence — otherwise known as state.

I'm not sure how you draw this conclusion from your previous statement. The stateless environment is not the protocol that delivers the environment but the environment itself (the HTML/XHTML page the browser renders).

Au contraire, monsieur: HTML and XHTML are formats of representations of resources. By definition they have no concept of state.
Protocols can have state: TCP/IP, for example. HTTP deliberately avoids it. Applications built over HTTP can employ it if they wish.

I think we are talking about different things. Usually when one refers to statelessness on the web they refer specifically to the design of HTTP. Perhaps you mean something different?

It's just semantics but .Net refers to a postback as a page posting to itself for an event for other reason. auto-postback implies the page is somehow doing this by itself without user assistance.

My understanding was that auto-postback was a property of a control which meant it could trigger a POST request upon certain conditions without the requirement of additional code. I could be wrong, of course...

Sure I think you could say that's a form of maintaining the application state but my point being is PHP wasn't serializing data into hidden form inputs as it didn't need to, it could logically progress without costly and ugly serialization / deserlization. My problem with ASP.Net's implementation wasn't that it was keeping where the user was in the page but the fact that it's taking almost exactly the same approach as a desktop application in that it's storing everything in a serialized piece of data that makes the page heavier than it needs to be. It just seems sloppy to me as there are more elegant solutions (even when using ASP.Net).

I agree.

Though, we are not discussing an HTTP Model as HTTP is just a protocol that the web uses to deliver content.

Well... when you employ a protocol, you necessarily employ its model too.

[Kasracer]

I think we are talking about different things. Usually when one refers to statelessness on the web they refer specifically to the design of HTTP. Perhaps you mean something different?

I'm not referring to the protocol that delivers the page but the page itself. When a page arrives on the client side, there isn't a native way to save the state of the controls on the page but you can send data back and forth. That's what I'm referring to (Maybe I didn't explain it correctly / well enough?)

My understanding was that auto-postback was a property of a control which meant it could trigger a POST request upon certain conditions without the requirement of additional code. I could be wrong, of course...

The only way a control can do a postback is if it calls the generated JavaScript to do the postback. For this to happen, the user has to click on something that raises an event in your code so at all times you are specifying what's doing the postback. Unless I am misunderstanding your point (which is entirely possible at this hour).

I agree.

Well... when you employ a protocol, you necessarily employ its model too.

Why? Video games typically use UDP for its efficiency but they have a state. The protocol doesn't determine state as it's just a tube to send data back and forth. It's the connection persistance, the server and client implementations that determine whether a technology can persist a state or not.

[Kasracer]

I'm affraid someone is going to reply to all / most of my points at some point. I don't think I have the energy to reply that much, heh.

[penagate]

I'm not referring to the protocol that delivers the page but the page itself. When a page arrives on the client side, there isn't a native way to save the state of the controls on the page but you can send data back and forth.

Okay, but that's application state. Initially you referred to 'state in a stateless environment'. In generic terms, the application environment can be either stateful or stateless as you wish. In ASP.NET-land, application state is considered a necessity. Is this the point you were making? If so, I agree that it should be easy to toggle application state on and off.

Why? Video games typically use UDP for its efficiency but they have a state. The protocol doesn't determine state as it's just a tube to send data back and forth. It's the connection persistance, the server and client implementations that determine whether a technology can persist a state or not.

Yeah but again we're talking about two different levels of architecture. The protocol has no concept of state per se but the application can control its state over the protocol. Application state is irrelevant to the underlying protocol.

I think at this point we are arguing whether the glass is half-empty or half-full.

[Kasracer]

Well my glass is half full

I just wanted to get other people's opinions on some of the things that bothered me about ASP.Net but I think I worded the original post poorly.

[penagate]

Now that we've sorted that out: I agree with you on all counts.

[mendhak]

What do you mean by maintenance? If you mean automatic value population on post-back then asp and php can do this for you as well except that instead of everything being done for you in an IDE, you have to write a little script (or pop in one of the many popular PHP frameworks).

Expand on this - are those 'frameworks' or scripts not relying on values submitted to the same page either via form or querystring?

I'm not sure what this is supposed to mean. No matter what technology you use, you have to design the site and that design will work in any framework. It sounds like you're saying ASP.Net helps you to avoid making "hundreds of tweaks to make it look right" but that's not true as the design process will be the same.

I once took a site designed for PHP, took the template and threw it in an ASP.Net page and it worked just fine. I also had to do the reverse (ASP.Net -> PHP) to allow some designers to work on a linux server when testing the site. Unless the site is designed poorly, there shouldn't be any tweaks to make it look right because of the language. That just seems silly to me.

No, I wasn't talking about design in a visual sense, I meant "work right" instead of "look right" - in terms of functionality flow. One of ASP.NET's best features, obviously, is that it takes away a lot of housekeeping which one performs regularly as part of website creation and maintenance.

I don't think it's a purist statement at all and your idea of only HTML pages with one DIV seems silly.

It's subjective. You can say anything is against the way the web was meant to work. The web is what we make of it, after all. Flash, for example, was something that may not have been envisioned to be a large part of the web experience back then, but it is now. And the evolving standards are complying with this as we see from new specifications.

I haven't seen any non-ASP.Net sites do this in a very long time but I'll take your word for it. It's a bad user experience IMO no matter which framework it's run on.

You mentioned that "it can be done without" (sans quotes, paraphrased) - what did you mean? I think that's what's nagging you the most - you don't like the hidden field with the viewstate information in it, combined with the form submissions being performed to deliver functionality. So what were you talking about when you mentioned that it could be done another way?

[mendhak]

Session and State are different (otherwise ASP.net wouldn't have seperated them). A session is a specific users logged into an environment but a state is how something is currently displayed and keeping that for the next change (hence why ASP.Net serializes data then deserializes it on postback).

Session is a way of maintaining state, viewstate as well, and cookies too. State is a concept which is implemented in different ways depending upon requirements.

State makes ASP.Net controls handle more like desktop controls. Session is really just a connection that allows the server to know its the same user / connection.
I agree but...
I'm not sure how you draw this conclusion from your previous statement. The stateless environment is not the protocol that delivers the environment but the environment itself (the HTML/XHTML page the browser renders).

State in ASP.Net is applied to the Html/Xhtml being delivered to the web browser. The HTTP protocol is just how it gets there.

Well, he's got it, I just quoted it to look like I am dissecting your post. I'm really just skimming over most of it, because my stomach hurts.

Not true. Any POST is a POST. Any postback is a postback. They're different in that a POST is sending form data to a specific page but a postback implies that the page is posting data back to itself. .Net typically posts data back onto itself but many other frameworks do not so they're not the same (but use the same technology).

POST = postback. POSTback = POST to the same page. A common feature again. For example, an 'address lookup field' in a page that requires a refresh depending on the country selected from a dropdown.

Sure I think you could say that's a form of maintaining the application state but my point being is PHP wasn't serializing data into hidden form inputs as it didn't need to, it could logically progress without costly and ugly serialization / deserlization.

My problem with ASP.Net's implementation wasn't that it was keeping where the user was in the page but the fact that it's taking almost exactly the same approach as a desktop application in that it's storing everything in a serialized piece of data that makes the page heavier than it needs to be. It just seems sloppy to me as there are more elegant solutions (even when using ASP.Net).

I haven't seen PHP5 (that's what you're talking about?). How is it doing it. Is this what you were referring to earlier?

I just disagree with the way it's typically handled in an ASP.Net application in the form of serialized data.

I disagree with the way ASP.NET AJAX (well, first with that name as it causes search engine confusion) deals with URLs and browser history maintenance when it comes to 'actions' performed. It changes the URL and appends an anchor to the end.

http://localhost/blah.aspx#action18
and later...
http://localhost/blah.aspx#action19

Others may like it, and I may find it comfortable, but it does give you a forward-backward functionality which many people find useful. Others may not agree.

[Kasracer]

Expand on this - are those 'frameworks' or scripts not relying on values submitted to the same page either via form or querystring?

No they do just as ASP.Net relies on them. It's just how forms work and the underlying piece of ASP.Net still gets the data from the form or querystring to re-populate controls during a postback.

No, I wasn't talking about design in a visual sense, I meant "work right" instead of "look right" - in terms of functionality flow. One of ASP.NET's best features, obviously, is that it takes away a lot of housekeeping which one performs regularly as part of website creation and maintenance.

What housekeeping are you referring to?

It's subjective. You can say anything is against the way the web was meant to work. The web is what we make of it, after all. Flash, for example, was something that may not have been envisioned to be a large part of the web experience back then, but it is now. And the evolving standards are complying with this as we see from new specifications.

Agree though I still don't like how Flash has to be embedded using non-standard html. You had mentioned in an ASP.Net posting a way to do it but that along with other ways do not include all of the functionality that should exist for a Flash video (i.e. checking for the latest version, showing a way for users to download Flash if they don't have it and a couple other things).

You mentioned that "it can be done without" (sans quotes, paraphrased) - what did you mean? I think that's what's nagging you the most - you don't like the hidden field with the viewstate information in it, combined with the form submissions being performed to deliver functionality. So what were you talking about when you mentioned that it could be done another way?

Correct I don't like the serialization / deserialization of control components within a form. Doing it another way would be to not utilize ViewState and ControlState and only pass what you absolutely need via form variables.

Now I know some might ask "well isn't that just the samething?" but I don't think so. First off, serialization has some overhead so the data passed is already going to be slightly larger than necessary (though, in some instances compression can be applied). Add that to the obfusticated output of the serilization process makes it difficult for other components or pages to possibly process that data along with the extra data .Net sometimes takes with it to the serilization process makes the whole process sloppy, imo.

Ajax is also an alternative as is Flash remoting (depending on the project of course).

[mendhak]

I have a clearer understanding of your point of view now. It's like Being John Malkovich, except you're not John Malkovich. You might be.

When I had first started ASP.NET, I was thinking along the same lines, but I eventually accepted it considering that this is how they chose to implement it. Perhaps in a few years (hah, never), specifications will let us do more in a cleaner way (never).

[szlamany]

I'm new to ASP.Net (as mendhak and penagate can certainly attest to!).

We are trying to create easy, fast and intuitive pages for users to access student data for large school districts.

One of our recent pages had a selection dropdown - "All Students", "Teams", "Grade", "Homeroom" and "Name". When you chose Teams or Grade, for instance, a second dropdown appears (via postback) that shows you all the teams and grades in the school (of which there are only a handful). When you chose Name there is a pause as the postback comes back with the second drop down filled with the 1500 names of students in the school.

Is this the kind of delay that you are finding problematic?

How would one go about doing this differently?

And on a second question - could someone please explain what is meant by the terms SERIALIZATION and DESERIALIZATION?

Thanks!

[Kasracer]

Is this the kind of delay that you are finding problematic?

Yes and no. It's not really a problem per say but I don't think it's a good user experience.

How would one go about doing this differently?

Well, you could use Ajax or cache the data within some Java scripting to set the second box.

And on a second question - could someone please explain what is meant by the terms SERIALIZATION and DESERIALIZATION?

Serialization and deserialization are basically processes that take an object, convert it into a string which can be later "deserialized" back into the class.

[mendhak]

I'd allow the delay to occur 'the first time', but if I know the data is going to be more or less static over a given period of time, I'd cache the data so that subsequent retrievals of the same data goes faster.

Serialization can also occur to binary format in addition to textual. Think of it as a process in which you would take an in-memory object and convert it to a format that can be placed on a storage medium (file-based for example); and it would be formatted in such a way that you can later pick up that same object and reconstruct your in-memory object as it was. It's like the concept of transports in Star Trek. Though Chief O'Brien would be able to explain it better, the object is stored, transported, stored, then converted.

Look at this really really simple example from MSDN
http://msdn2.microsoft.com/en-us/lib...k0(VS.71).aspx

[szlamany]

When you say cache the data so the delay occurs only on the first time - where would you cache that?

And...that link didn't work for me.

[mendhak]

I'm not being patronizing, but you did click that link rather than copy paste it right? I just clicked on it 10 times to make sure it's working, and it is. Nevertheless, I'll paste some of what it says

The easiest way to make a class serializable is to mark it with the Serializable attribute as follows.

[Serializable]
public class MyObject {
  public int n1 = 0;
  public int n2 = 0;
  public String str = null;
}

The code example below shows how an instance of this class can be serialized to a file.

MyObject obj = new MyObject();
obj.n1 = 1;
obj.n2 = 24;
obj.str = "Some String";
IFormatter formatter = new BinaryFormatter();
Stream stream = new FileStream("MyFile.bin", FileMode.Create, FileAccess.Write, FileShare.None);
formatter.Serialize(stream, obj);
stream.Close();

So you can see that it's stored in a binary format to disk. Note that this is not what kasracer mentioned. He is talking about serializing in a textual format. That too is possible, as it says:

The BinaryFormatter used above is very efficient and produces a compact byte stream. All objects serialized with this formatter can also be deserialized with it, which makes it an ideal tool for serializing objects that will be deserialized on the .NET Framework. It is important to note that constructors are not called when an object is deserialized. This constraint is placed on deserialization for performance reasons. However, this violates some of the usual contracts the runtime makes with the object writer, and developers should ensure they understand the ramifications when marking an object as serializable.

If portability is a requirement, use the SoapFormatter instead. Simply replace the BinaryFormatter in the code above with SoapFormatter, and call Serialize and Deserialize as before. This formatter produces the following output for the example used above.

<SOAP-ENV:Envelope
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle=
  "http://schemas.microsoft.com/soap/encoding/clr/1.0"
  "http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:a1="http://schemas.microsoft.com/clr/assem/ToFile">

  <SOAP-ENV:Body>
    <a1:MyObject id="ref-1">
      <n1>1</n1>
      <n2>24</n2>
      <str id="ref-3">Some String</str>
    </a1:MyObject>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

That gives you XML. Textual. Yadda yadda.

[mendhak]

About your caching question.

Let's say your business layer has a method, Get1500StudentNames(). Because it is a lot of data and you assume that it'll be relatively static, you can cache it in the method itself.

First, check System.Web.Caching.Cache["YOURCachedDataStringIdentifier"] to see if it has the data you want. If it's not there, call your stored proc, get your data, then System.Web.Caching.Cache.Add("YOURCachedDataStringIdentifier"), and send the dataset back to the calling class.

Next time a call comes in, when you check the cache, you do find the data there, so just cast it to dataset (or whatever your return type is) and send it back. So you've saved yourself a call, which might be what was causing the delay.

Here's what a cache insert would look like

string CachedItem9 = (string)Cache.Add("CacheItem9",
    "Cached Item 9", null,
    System.Web.Caching.Cache.NoAbsoluteExpiration,
    System.Web.Caching.Cache.NoSlidingExpiration, 
    System.Web.Caching.CacheItemPriority.Default,
    null);

Dim CachedItem9 As String = CStr(Cache.Add("CacheItem9", _
    "Cached Item 9", Nothing, _
    System.Web.Caching.Cache.NoAbsoluteExpiration, _
    System.Web.Caching.Cache.NoSlidingExpiration, _
    System.Web.Caching.CacheItemPriority.Default, _
    Nothing))

Try this link - http://msdn2.microsoft.com/en-us/lib...ing.cache.aspx

You can also specify a method delegate to call when the cached object expires, in which you can simply call the stored proc again and repopulate the object in cache.

[mendhak]

I forgot to add, if you use Sql Server Notification Services, read this too http://aspalliance.com/1541_Understa...th_ASPNET_20.2

[szlamany]

MDSN logs me in automatically and kind of re-directs me to a "CONTENT NOT FOUND" page - no patronizing felt

I'll look at what you posted and try to get to the link a different way.

[penagate]

How would one go about doing this differently?

The first choice could be on one page. The second choice could be on the next. This way, the processing required to populate the second list of choices is triggered by the user.

Then, you could enhance that by using AJAX to add the second choice to to the page on the fly after the first is selected, with some indicator that makes it clear that action is happening while this is done.