Re: Why ASP.NET gets no Respect

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

> The Web-Forms IDE brings up an editor to insert server-side code - 
> as though a Web application were the same as a stateful single-user 
> desktop application - except the nuances of state management may not be
clear, at all.

With the addition of viewstate it's almost stateful :-) Sure, are there
nuances that you should be aware of, yup. But it's programming you need
to know something at some point. It often is as simple as handle the
event and redirect. Here's some production code: 

1 protected void cmdUpdate_Click(object sender, EventArgs e)
2 {
3 	Option dictionary =
Option.GetOption(OptionList.CustomDictionary);
4	dictionary.OptionDefault = tbDictionary.Text.Replace("\r\n",
"\t");
5	dictionary.Save();
6
7	Response.Redirect("maintainTables.cfm");
8 }

Yes, I know the code, but this is simple enough. Line 3 gets an Option
from the database -- specifically the CustomDictionary option -- line 4
sets the OptionDefault value for that object and line 5 saves it back to
the DB. Line 7 sends the user back to the maintenance page. Simple.


> A browser UI event may need to trigger client code - a JavaScript
function.  
> The event may then need to forward "something" to the server.  The
event may 
> need to update a variable in, or submit something from a different 
> document in a separate in-line frame.  Maybe the event should trigger a

> complex set of client actions, followed by a series of AJAX
interactions.

So do those things. There's nothing that stops you have having
javascript handlers on the client. And you don't have to post back to
the server at all. As you say it may be a ajax call or a submission to
another page. The server event handlers are just one option you have. 

> I meant the Object Browser...

Ah. In the ASP.Net world I don't use that too much, but when building
the business layer it's a great resource. Of course w/intellisense it's
like having the object browser as you type.

-Walden