Add one more option for ClientIDMode enumeration in ASP.NET.

It's often the case we use ID of a control only in order to reference it from Code-Behind and we don't need the id attribute to be rendered on client-side. It only creates unnecessary garbage data to be transferred to client. ClientIDMode.Static can decrees the amount of data being transferred, but it's still > 0 and one must be extremly careful not to generate duplicate IDs.

ClientIDMode.None would prevent ID from being rendered to resulting HTML markup. The CliendID property would return null (or empty string). Supporting controls will not render the ID attribute in this case at all.

With al those new and improved pattern implementations for VS2010 like ASP.NET MVC and MVVM for SL and WP7. There is also one missing and thats the MVP pattern for ASP.NET WebForms. Almost all my clients who develop with ASP.NET WebForms makes an big mess of their WebApp architecture and that's because they don't use an proper User Interface pattern and develop all their businesslogic in their WebForms, not to mention the testability. Several years ago the patterns & practices team developed Web Client Software Factory who contained the ObjectContainerDataSource with the MVP pattern. The ObjectContainerDataSource is in my honoust opinion a good way to support the MVP pattern in ASP.NET WebForms, so therefore I'll would vote to default support the MVP pattern with the ObjectContainerDataSource to be added into future versions of Visual Studio.

ASP.NET specifically:

I have recently been developing some server controls, and let me tell you: Efficient Memory Management is nearly impossible to achieve on the framework... And for one simple reason:

Developers cannot catch a true page's life without going to extremes like creating your own HTTPModule to catch a request, play with it, and then redirect. Not only that, but the HTTPModule can't even interact with the Application code...

The most explicit example of this comes from some recent work i've been doing developing a custom grid control. Basically, the developer asked me this:

Can you make a grid control that i can bind to once, if not postback, and then it'll manage everything on its own (e.g.: paging, sorting, filtering, etc), AND, i don't want to have to rebind my datasource every single time the page loads. It should keep it in memory, for that user, for that page. I may have 100-1000 records i get from my DB, and i don't want to have to make a trip to the database again every time the user changes the filtering or sorting or changes pages because 1) we don't have the bandwidth, and 2) this would be a 3 hop operation every time, and frankly that's just inefficient when we could use the webserver to do it all and have a single 3-hop jump at the start.

That seemed very logical and efficient to me, and i knew i was able to persist data easily between postbacks.

Unfortunately, however, i am now forced (after developing the entire control as well! yay!) to say no to this developer, because the framework does not allow me to manage memory on a per-user-per-page basis, without me forcing that developer to implement a ton of code, and a custom HTTP module, just to manage the memory the control uses.

Here's why... i only have these memory management options:

1) ControlState (meets per user per page)

- beyond 100 records as a datasource, the hidden field becomes so huge, that page performance is adversely affected.

2) Session State (does not meet per user per page)

- Since this state ties ALL user memory used to a single session (e.g.: the entire time the user is on the site, or has left the site for a certain amount of time), having 1000 or more users on at the same time (this is our case) and not having that memory cleared for say, 20 minutes, each having loaded at least one of those grids with 1000 records, would essentially kill a 64gb rammed web server. Not the desired effect.

3) Application State (does not meet per user per page)

- Using a clever combo of session id and control id for the key, i am definitely able to manage the memory, but for one thing: i have no way to execute a method when the user leaves a page without coding my own HTTPModule, and even then, i'm not even sure this type of life cycle can be achieved with my own http module. This means that effectively, unless the user re-visits the same page that created the memory in the first place, it will stay in memory until the application dies (and therein lies the problem).

4) Write to disc (XML) (does not meet per user per page)

- Again here, we have the exact same problem as the application state, because we can't clear that memory on a per page basis. The only workaround, all be it ineffective, to this would be to put a service on the webserver that checks every few minutes if the user's session is alive, and if not, kill the XML file. But then again, i can do that in global.asax already, and that's not the solution we want because we're back to the same problems we had with session state.

So here's my suggestion:

Can you please implement a way for developers to dynamically create rules on the application that would fire for every page request, with a small amount of page information as properties/accessible variables like: Request Came From: [pagename], Request Going To: [pagename], SessionID: [sessionid]

The ruleset i personally see as a stack of delegates based on conditions, but feel free to implement as you see fit... i see it like this:

Definition:

Application.AddRule(string RuleKey, string SessionID, string PageLeft, delegate ActionToPerform, string optional PageRequested)

Application.RemoveRule(string RuleKey)

And then control developers could not only persist data wherever they want, but they could also manage that memory so easily it would be a piece of cake! Liek so, for example:

ServerControl.cs:

OnInit(){

Application.HttpRules.Remove(ViewState["MemKey"]);

Application.HttpRules.Add(GenerateKey(),Context.SessionID, Context.Request.RawURL, new delegate(){function(){Helpers.ClearCachedMemory([keyid]);}});

}

Helpers.ClearCacheMemory(string keyid)

{

[CHOOSE YOUR STATE MANAGER! HOW AWESOME IS THIS!? :) ]

StateManagerChosen[keyid] = null; //OR

StateManagerChosen.Remove(keyid);

}

With just this tid bit of information/processing available to us little developers, it would then be a lot easier to persist, and manage the memory used by each user (session), on a per page basis. Thus, you would essentially eliminate the need for storing large amounts of data in the viewstate or control state to persist the information, while giving the developer the choice of where to store this data, and providing them with an easy way to manager it manually :)

I hope this all fits and is accepted on the form. :S

Mathieu Charlebois

Senior Programmer Analyst