Q - How do I persist members variables/properties on Page level?

[Usenet User]

I know I can use ViewState for member fields and variables declared on
Page level to persist between postbacks, for example:

private const string FormModeTag = "_FormMode_ ";

private string FormMode
{
get
{
object formMode = this.ViewState[FormModeTag];
if( formMode != null )
{
return (string)formMod e;
}
else
{
return "";
}
}
set
{
this.ViewState[FormModeTag] = value;
}
}
Is there some other and/or better way? I found PersistentMode
attribute, but it seems it only works with controls' properties, not
with Page properties.

Thanks!

[Steve C. Orr [MVP, MCSD]]

ViewState is considered the best practice (in almost all cases) for
persisting a value between postbacks on the same page. It has the perfect
scope for such an operation. There are of course other caching options but
they have a less than ideal scope.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net

"Usenet User" < @ . > wrote in message
news:3i******** *************** *********@4ax.c om...

I know I can use ViewState for member fields and variables declared on
Page level to persist between postbacks, for example:

private const string FormModeTag = "_FormMode_ ";

private string FormMode
{
get
{
object formMode = this.ViewState[FormModeTag];
if( formMode != null )
{
return (string)formMod e;
}
else
{
return "";
}
}
set
{
this.ViewState[FormModeTag] = value;
}
}
Is there some other and/or better way? I found PersistentMode
attribute, but it seems it only works with controls' properties, not
with Page properties.

Thanks!

[Brock Allen]

> Is there some other and/or better way?

What do you mean? This is the model for insuring a value is passed back and
forth between postbacks.

I found PersistentMode
attribute, but it seems it only works with controls' properties, not
with Page properties.

PersistMode has to do with how the syntax in the ASPX is interpreted by the
ASP.NET parser. It has nothing to do with ViewState.

-Brock
DevelopMentor
http://staff.develop.com/ballen

[Kevin Spencer]

> Is there some other and/or better way?

ViewState is a tool. Asking if there's a better way is like asking if there
is a better tool than a hammer. It all depends on what you are doing. A
hammer is perfect for hammering nails, but lousy at cutting plywood.

The most important thing is to know what all of your tools are, what each
one is used for, what its characteristics are, and when it is appropriate to
use it.

ViewState, for example, is not particularly good for storing large chunks of
data. It slows down the Response time by adding to the content of the Page.
It is, however, perfect for storing the state of a Server Control, which is
very small. It has the advantage of not consuming resources (memory) on the
server side.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Usenet User" < @ . > wrote in message
news:3i******** *************** *********@4ax.c om...

I know I can use ViewState for member fields and variables declared on
Page level to persist between postbacks, for example:

private const string FormModeTag = "_FormMode_ ";

private string FormMode
{
get
{
object formMode = this.ViewState[FormModeTag];
if( formMode != null )
{
return (string)formMod e;
}
else
{
return "";
}
}
set
{
this.ViewState[FormModeTag] = value;
}
}
Is there some other and/or better way? I found PersistentMode
attribute, but it seems it only works with controls' properties, not
with Page properties.

Thanks!

[Usenet User]

On Thu, 24 Mar 2005 09:12:57 -0500, "Kevin Spencer"
<ke***@DIESPAMM ERSDIEtakempis. com> wrote:

Is there some other and/or better way?

ViewState is a tool. Asking if there's a better way is like asking if there
is a better tool than a hammer. It all depends on what you are doing. A
hammer is perfect for hammering nails, but lousy at cutting plywood.

The most important thing is to know what all of your tools are, what each
one is used for, what its characteristics are, and when it is appropriate to
use it.

ViewState, for example, is not particularly good for storing large chunks of
data. It slows down the Response time by adding to the content of the Page.
It is, however, perfect for storing the state of a Server Control, which is
very small. It has the advantage of not consuming resources (memory) on the
server side.

Thank you all who responded, I am getting the idea. I only see a
couple of drawbacks with ViewState:

1) Must be implemented manually, per each variable/property.

2) Uncovers the inner data of the class by sending it to the client.
What if it is not meant to be seen?

[Steve C. Orr [MVP, MCSD]]

ViewState is encoded so its content cannot be easily seen by a typical user.
Also, ViewState can be configured to be stored on the server instead of the
client, if you prefer.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net
"Usenet User" < @ . > wrote in message
news:d5******** *************** *********@4ax.c om...

On Thu, 24 Mar 2005 09:12:57 -0500, "Kevin Spencer"
<ke***@DIESPAMM ERSDIEtakempis. com> wrote:

Is there some other and/or better way?

ViewState is a tool. Asking if there's a better way is like asking if
there
is a better tool than a hammer. It all depends on what you are doing. A
hammer is perfect for hammering nails, but lousy at cutting plywood.

The most important thing is to know what all of your tools are, what each
one is used for, what its characteristics are, and when it is appropriate
to
use it.

ViewState, for example, is not particularly good for storing large chunks
of
data. It slows down the Response time by adding to the content of the
Page.
It is, however, perfect for storing the state of a Server Control, which
is
very small. It has the advantage of not consuming resources (memory) on
the
server side.

Thank you all who responded, I am getting the idea. I only see a
couple of drawbacks with ViewState:

1) Must be implemented manually, per each variable/property.

2) Uncovers the inner data of the class by sending it to the client.
What if it is not meant to be seen?