I have a non trivial ASP.NET Web application that implements its navigation
system via a user control (menu.ascx) placed on every page.
It is important to note that the user control that hosts the menu is
injected into every page at runtime when the page is requested (i.e., it's
not declared in any ASPX).
The user control contains a menu that is dynamically populated and styled at
runtime (fwiw: it's ComponentArt's Menu for ASP.NET - but that's irrellevant
to this question)
The data for the menu is retrieved from a SQL Server database - and loaded
into the menu at runtime during the Page_Load event procedure of menu.ascx.
I have implemented security such that different DataSets are used to
construct the menu: If the current user is NOT logged in, then they get a
standard menu which is stored in the Application state. But once the user
logs in, then they get a user-specific menu - with its supporting DataSet
stored in their Session.
The application code always attempts to retrieve the menu's DataSet from
either the Application state or the Session - and hittis the db only if not
found in one of those places.
This all works very well - and production runtime performance is acceptable.
But I want to do better.
While I have reduced db hits as much as possible, the property values for
the menu are set on *every* page request (during the page_load event of
menu.ascx). This seems like it is or should be totally unnecessary. I would
like to set the menu properties only once and then never again if possible
(with the only exception being that an unauthenticated user logs in - in
which they would get new menu properties - which should then be in effect
for the duration of their session)
ViewState, AFAIK, is how we maintain control property settings between page
requests. But I'm not sure it will help me here. To EnableViewState on
either the PlaceHolder into which I'm injecting the user control, or on the
user control would not help me in this case because the user control is
injected into each page at runtime (via a PlaceHolder) - or so I think. If
I'm correct, then a newly requested page would not have the opportunity to
have the menu's viewstate because only previously-opened pages would have
the menu's ViewState information (and not the currently/newly-opened page).
You can see that this is where I'm getting a little fuzzy on what's going on
here with ViewState as it relates to my application and its menu and hosting
user control.
So - I would appreciate it if someone could shed some light on what's going
on here with respect to ViewState and how I might be able to continue with
my existing architecture (of injecting into each page the menu's user
control at runtime) AND NOT have to continue setting all of the menu's
properties on every page request - and ideally only once or twice per
session).
Thanks!
7  1926 
Have you looked into using the Cache object ?
The situation you describe sounds tailor-made for it.
Juan T. Llibre
ASP.NET MVP http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================
"Smithers" <A@B.com> wrote in message news:eu**************@tk2msftngp13.phx.gbl... I have a non trivial ASP.NET Web application that implements its navigation system via a
user control (menu.ascx) placed on every page.
It is important to note that the user control that hosts the menu is injected into every
page at runtime when the page is requested (i.e., it's not declared in any ASPX).
The user control contains a menu that is dynamically populated and styled at runtime
(fwiw: it's ComponentArt's Menu for ASP.NET - but that's irrellevant to this question)
The data for the menu is retrieved from a SQL Server database - and loaded into the menu
at runtime during the Page_Load event procedure of menu.ascx.
I have implemented security such that different DataSets are used to construct the menu:
If the current user is NOT logged in, then they get a standard menu which is stored in
the Application state. But once the user logs in, then they get a user-specific menu -
with its supporting DataSet stored in their Session.
The application code always attempts to retrieve the menu's DataSet from either the
Application state or the Session - and hittis the db only if not found in one of those
places.
This all works very well - and production runtime performance is acceptable. But I want
to do better.
While I have reduced db hits as much as possible, the property values for the menu are
set on *every* page request (during the page_load event of menu.ascx). This seems like
it is or should be totally unnecessary. I would like to set the menu properties only
once and then never again if possible (with the only exception being that an
unauthenticated user logs in - in which they would get new menu properties - which
should then be in effect for the duration of their session)
ViewState, AFAIK, is how we maintain control property settings between page requests.
But I'm not sure it will help me here. To EnableViewState on either the PlaceHolder into
which I'm injecting the user control, or on the user control would not help me in this
case because the user control is injected into each page at runtime (via a
PlaceHolder) - or so I think. If I'm correct, then a newly requested page would not have
the opportunity to have the menu's viewstate because only previously-opened pages would
have the menu's ViewState information (and not the currently/newly-opened page). You can
see that this is where I'm getting a little fuzzy on what's going on here with ViewState
as it relates to my application and its menu and hosting user control.
So - I would appreciate it if someone could shed some light on what's going on here with
respect to ViewState and how I might be able to continue with my existing architecture
(of injecting into each page the menu's user control at runtime) AND NOT have to
continue setting all of the menu's properties on every page request - and ideally only
once or twice per session).
Thanks!
With all due respect - have you actually read my OP?
The whole issue centers around reducing the number of times I set properties
in a user control that is injected into each page at runtime - NOT reducing
db hits. I'm already caching data - just not in the Cache object because it
is not the best place, IMHO, for user-specific values.
If I missed something about how the Cache can be helpful to my particular
situaion - then can you please be a bit more specific?
-S
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:ex**************@TK2MSFTNGP14.phx.gbl... Have you looked into using the Cache object ?
The situation you describe sounds tailor-made for it.
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================
"Smithers" <A@B.com> wrote in message
news:eu**************@tk2msftngp13.phx.gbl...I have a non trivial ASP.NET Web application that implements its
navigation system via a user control (menu.ascx) placed on every page.
It is important to note that the user control that hosts the menu is
injected into every page at runtime when the page is requested (i.e.,
it's not declared in any ASPX).
The user control contains a menu that is dynamically populated and styled
at runtime (fwiw: it's ComponentArt's Menu for ASP.NET - but that's
irrellevant to this question)
The data for the menu is retrieved from a SQL Server database - and
loaded into the menu at runtime during the Page_Load event procedure of
menu.ascx.
I have implemented security such that different DataSets are used to
construct the menu: If the current user is NOT logged in, then they get a
standard menu which is stored in the Application state. But once the user
logs in, then they get a user-specific menu - with its supporting DataSet
stored in their Session.
The application code always attempts to retrieve the menu's DataSet from
either the Application state or the Session - and hittis the db only if
not found in one of those places.
This all works very well - and production runtime performance is
acceptable. But I want to do better.
While I have reduced db hits as much as possible, the property values for
the menu are set on *every* page request (during the page_load event of
menu.ascx). This seems like it is or should be totally unnecessary. I
would like to set the menu properties only once and then never again if
possible (with the only exception being that an unauthenticated user logs
in - in which they would get new menu properties - which should then be
in effect for the duration of their session)
ViewState, AFAIK, is how we maintain control property settings between
page requests. But I'm not sure it will help me here. To EnableViewState
on either the PlaceHolder into which I'm injecting the user control, or
on the user control would not help me in this case because the user
control is injected into each page at runtime (via a PlaceHolder) - or so
I think. If I'm correct, then a newly requested page would not have the
opportunity to have the menu's viewstate because only previously-opened
pages would have the menu's ViewState information (and not the
currently/newly-opened page). You can see that this is where I'm getting
a little fuzzy on what's going on here with ViewState as it relates to my
application and its menu and hosting user control.
So - I would appreciate it if someone could shed some light on what's
going on here with respect to ViewState and how I might be able to
continue with my existing architecture (of injecting into each page the
menu's user control at runtime) AND NOT have to continue setting all of
the menu's properties on every page request - and ideally only once or
twice per session).
Thanks!
re: I'm already caching data - just not in the Cache object
That's why I asked.
Sorry to have disturbed you.
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================
"Smithers" <A@B.com> wrote in message news:ua**************@TK2MSFTNGP10.phx.gbl... With all due respect - have you actually read my OP?
The whole issue centers around reducing the number of times I set properties in a user
control that is injected into each page at runtime - NOT reducing db hits. I'm already
caching data - just not in the Cache object because it is not the best place, IMHO, for
user-specific values.
If I missed something about how the Cache can be helpful to my particular situaion -
then can you please be a bit more specific?
-S
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:ex**************@TK2MSFTNGP14.phx.gbl... Have you looked into using the Cache object ?
The situation you describe sounds tailor-made for it.
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================
"Smithers" <A@B.com> wrote in message news:eu**************@tk2msftngp13.phx.gbl...I have a non trivial ASP.NET Web application that implements its navigation system via
a user control (menu.ascx) placed on every page.
It is important to note that the user control that hosts the menu is injected into
every page at runtime when the page is requested (i.e., it's not declared in any
ASPX).
The user control contains a menu that is dynamically populated and styled at runtime
(fwiw: it's ComponentArt's Menu for ASP.NET - but that's irrellevant to this question)
The data for the menu is retrieved from a SQL Server database - and loaded into the
menu at runtime during the Page_Load event procedure of menu.ascx.
I have implemented security such that different DataSets are used to construct the
menu: If the current user is NOT logged in, then they get a standard menu which is
stored in the Application state. But once the user logs in, then they get a
user-specific menu - with its supporting DataSet stored in their Session.
The application code always attempts to retrieve the menu's DataSet from either the
Application state or the Session - and hittis the db only if not found in one of those
places.
This all works very well - and production runtime performance is acceptable. But I
want to do better.
While I have reduced db hits as much as possible, the property values for the menu are
set on *every* page request (during the page_load event of menu.ascx). This seems like
it is or should be totally unnecessary. I would like to set the menu properties only
once and then never again if possible (with the only exception being that an
unauthenticated user logs in - in which they would get new menu properties - which
should then be in effect for the duration of their session)
ViewState, AFAIK, is how we maintain control property settings between page requests.
But I'm not sure it will help me here. To EnableViewState on either the PlaceHolder
into which I'm injecting the user control, or on the user control would not help me in
this case because the user control is injected into each page at runtime (via a
PlaceHolder) - or so I think. If I'm correct, then a newly requested page would not
have the opportunity to have the menu's viewstate because only previously-opened pages
would have the menu's ViewState information (and not the currently/newly-opened page).
You can see that this is where I'm getting a little fuzzy on what's going on here with
ViewState as it relates to my application and its menu and hosting user control.
So - I would appreciate it if someone could shed some light on what's going on here
with respect to ViewState and how I might be able to continue with my existing
architecture (of injecting into each page the menu's user control at runtime) AND NOT
have to continue setting all of the menu's properties on every page request - and
ideally only once or twice per session).
Thanks!
Have a look at output caching,
This works by caching the result of the render of a page (or control)
then using this,
In win 2003 and IIS 6 this is a kernal level cache and is very quick
Why is it necessary for you to place the menu control on the page at
runtime? Do you need to dynamically remove the menu from the page
under certain conditions?
Bill E.
Hollywood, FL
Thank you very much! I'll take a look.
-S
<ga**********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com... Have a look at output caching,
This works by caching the result of the render of a page (or control)
then using this,
In win 2003 and IIS 6 this is a kernal level cache and is very quick
<< Why is it necessary for you to place the menu control on the page at
runtime? >>
Because the location of the menu in the aspx and the particular menu to be
implemented can change at runtime depending on a number of runtime
conditions.
-S
<bi********@netscape.net> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com... Why is it necessary for you to place the menu control on the page at
runtime? Do you need to dynamically remove the menu from the page
under certain conditions?
Bill E.
Hollywood, FL This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Lloyd Sheen |
last post by:
Is there any one who has actually done this. I have now scanned more web
articles about this with the realization that not one of them (including
MSDN docs) outlines how to do this. This is...
|
by: SoftLion |
last post by:
what is the difference between component and web user control ?
Thanks !
|
by: Samuel |
last post by:
Hi,
I am building a page that makes use of user control as a templating
technique. The following is that I have in mind and it is actually working:
Root/
-- login.aspx
-- login.aspx.vb
--...
|
by: Prabhudhas Peter |
last post by:
Hai,
I've Created a User control for example a Button and i've given the font
of the text as Bold and compiled it. Now i've used this Usercontrol
everywhere in my project. Now i changed the font...
|
by: Ronald S. Cook |
last post by:
We have a Windows app that has one main form (a shell, sort of). We then
load user controls into a panel on the form depending on what the user has
selected.
Our current code to unload the...
|
by: moondaddy |
last post by:
I'm using asp.net 2.0 and c# and would like to share some user control
between several websites. these websites are on the same server and have a
physical location right next to each other like...
|
by: Joseph Geretz |
last post by:
Don't get me wrong - I'm a fan of .NET; I am enthusiastic about the richness
and elegance of the environment. However, richness and elegance should be
dedicated toward making development easier for...
|
by: =?Utf-8?B?V29ua28gdGhlIFNhbmU=?= |
last post by:
Hello All--
Just a general (or perhaps loaded) question - is it considered good or bad
practice to use code-behind with a CustomControl.generic.xaml file?
For instance, with a control I'm...
|
by: brixdotnet |
last post by:
Hi there!
I made own user control for displaying and editing content. In
Page_Load of this control is checked if user is authorized for editing
if so, button for editing is shown, otherwise...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
