Jason Salas' WebLog

On-air and online: making people laugh, making people think, pissing people off

Sponsors

ASP.NET sites that kick ass

Pals with blogs

Podcasts I listen to

Practicality of having typed view state/ViewState API for ASP.NET 2.0?

I’m quite sure someone has brought this up at some point either theoretically or jokingly, and I’m not sure how feasible it would be (although I think it would be pretty cool), but can/should a page’s view state be able to be typed, rather than just storing all data within as type object? 

 

Perhaps the convention of - ViewState[“key”] - could include a second argument when 2.0 rolls out, which would be the explicitly-stated data type for the data?

 

CHEESY EXAMPLE 1:

String myName = “Jason Salas”;

ViewState[“aDudeInGuam”,System.String] = myName;

 

Or, possibly this could be set in web.config for **certain** ViewState entries, providing typing information, as the Profile does object for personalization in 2.0? 

 

CHEESY EXAMPLE 2:

<viewstate keyName=“phoneNumber“ type=“System.Int32“/>

 

Or, maybe include a ViewState API (there’s a thought), similar to what is provided with the Cache API, wherein developers have a variety of overloaded methods from which to choose in setting/accessing view state values?

 

CHEESY EXAMPLE 3:

int homePhoneJenny = 8675309;

ViewState.Insert(“keyPhone”, homePhoneJenny,System.Int32);

 

Would this even be worth it, or make sense?  It seems to me like this would fit in nicely with Whidbey’s push towards more streamlined programming without the need for casting/recasting data. 

Certainly, many people would get something out of it when working with business logic, and if this would help improve the expensive performance hit caused by the Framework's internal binary serialization for types without readily-available type converters, that would be gravy.

 

What do you think? 

Posted: Dec 24 2003, 10:19 AM by guam-aspdev | with 7 comment(s)
Filed under:

Comments

Snorrk said:

I'd like to point out that this could also benefit client side scripting. Instead of having to use hidden form fields the client side script could modify the viewState directly. I'm not sure if this is actually feasable - just pointing out the fact. I remember reading something about v2.0 better support of client side scripting - can't remember where though. Letting controls decide if they want theyre viewState typed could be beneficial - giving controls that require client side code to modify theyre viewState the ability to do so.
# December 23, 2003 7:30 PM

Jason Salas said:

There's a good thought. Whidbey does provide a lot of helpful integration with managing server-side data to the client, but I'd also like to see more of the opposite - supporting client-side data pushed into server-side logic.
# December 23, 2003 7:35 PM

snorrk said:

When the christmas rush is over I'm thinking about sitting down and writing something to make it easier to modify a Control through client side scripting.

I'm thinking a c# control base class that includes a ClientState dictionary (strKey, obj, type) ala example 3 and some client side js code to make working with it easier (as in ClientState[strKey] = value). The base class would write the ClientState into a hidden field (like ViewState is now) - but in a format that the client side js would be able to parse and modify. On postback it would verify that the returned ClientState is valid and pass it on to the control.

In short: Client side editable ViewState.

Anyone interested enough to comment? Or am I trying to solve a problem that doesn't exist?
# December 23, 2003 9:04 PM

Jason Salas said:

Hi Snorrk,

That's a great idea. I'd be interested in working with you on the theory behind it (after the holidays), but optimally, I'd like to see this ship as part of the .NET Framework, so such could be implemented for other controls.
# December 23, 2003 10:19 PM

mike said:

Couple of thoughts, off the record, so to speak. Per the "cheesy examples" :-), if I read this correctly, you're proposing that viewstate also store a token of some sort indicating the type of the value (?). What happens on the getter? Does it pre-cast the value back to that type? E.g.


String myName = “Jason Salas”;
ViewState[“aDudeInGuam”,System.String] = myName;

// ...

String aName;
aName = ViewState["aDudeInGuam"] // works
DateTime aDate;
aDate = ViewState["aDudeInGuam"] // throws ??

As for client scripting, it would be interesting to hear about the scenarios. I don't think typing is the issue as such, since javascript types dynamically. It's really an issue of simply getting to the data in viewstate -- or is it setting? But javascript has access to the page in its client form, with controls populated, so is the issue primarily with being able to access arbitrary, non-control data?




# December 30, 2003 11:34 AM

TrackBack said:

# January 5, 2004 2:38 PM

Prashanth said:

Can any one help me for accessing the viewstate contents thro javascript code.
Kindly mail me at prashanth.k@sonata-software.com
# April 23, 2004 8:56 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)