Menu ascx - use database? Best practice?

[Sandy]

Hello -

I have a book that illustrates pulling menu items from a Sql Server table
into an ascx via a stored procedure. Is this something that is done in the
real world?

I do like the effect when viewing it in the source code, however, because it
doesn't show the complete path to the file. (I'm talking about Internet
Explorer click View, click source code.)

It does seem like it causes an undue amount of trips to the server, although
the pages themselves in my application require a trip to the server in many
cases.

Can anyone give me any reasons why or why not to do it this way?

--
Sandy

[Curt_C [MVP]]

Sandy wrote:

Hello -

I have a book that illustrates pulling menu items from a Sql Server table
into an ascx via a stored procedure. Is this something that is done in the
real world?

I do like the effect when viewing it in the source code, however, because it
doesn't show the complete path to the file. (I'm talking about Internet
Explorer click View, click source code.)

It does seem like it causes an undue amount of trips to the server, although
the pages themselves in my application require a trip to the server in many
cases.

Can anyone give me any reasons why or why not to do it this way?

Does the menu change (is it really something that needs to be dynamic)?
If not stick it into a control with the values, otherwise, if you need
it to be dynamic you pretty much have to re-read it each time.

--
Curt Christianson
site: http://www.darkfalz.com
blog: http://blog.darkfalz.com

[Sandy]

Hi Curt_C -

Thanks for your response! I was thinking about just using hyperlinks and
putting them into a user control as an alternative.

Your statement "If not stick it into a control with the values" . . . can
you be more specific?

--
Sandy
"Curt_C [MVP]" wrote:

Sandy wrote:

Hello -

I have a book that illustrates pulling menu items from a Sql Server table
into an ascx via a stored procedure. Is this something that is done in the
real world?

I do like the effect when viewing it in the source code, however, because it
doesn't show the complete path to the file. (I'm talking about Internet
Explorer click View, click source code.)

It does seem like it causes an undue amount of trips to the server, although
the pages themselves in my application require a trip to the server in many
cases.

Can anyone give me any reasons why or why not to do it this way?

Does the menu change (is it really something that needs to be dynamic)?
If not stick it into a control with the values, otherwise, if you need
it to be dynamic you pretty much have to re-read it each time.

--
Curt Christianson
site: http://www.darkfalz.com
blog: http://blog.darkfalz.com

[Russ Farris]

Sandy,

Depends on your need if the menu items don't change very often then you can
always use the Cache object to store them and then invalidate the cache.

Or alternatively you could always use an XML file to store your menu items
and parse the XML and them dynamically that way.

We use both SQL and XML files where I work. Both are practical but you do
want to watch your round trips to the database.

Russ

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:EB******** *************** ***********@mic rosoft.com...

Hi Curt_C -

Thanks for your response! I was thinking about just using hyperlinks and
putting them into a user control as an alternative.

Your statement "If not stick it into a control with the values" . . . can
you be more specific?

--
Sandy
"Curt_C [MVP]" wrote:

Sandy wrote:

> Hello -
>
> I have a book that illustrates pulling menu items from a Sql Server
> table
> into an ascx via a stored procedure. Is this something that is done in
> the
> real world?
>
> I do like the effect when viewing it in the source code, however,
> because it
> doesn't show the complete path to the file. (I'm talking about
> Internet
> Explorer click View, click source code.)
>
> It does seem like it causes an undue amount of trips to the server,
> although
> the pages themselves in my application require a trip to the server in
> many
> cases.
>
> Can anyone give me any reasons why or why not to do it this way?
>

Does the menu change (is it really something that needs to be dynamic)?
If not stick it into a control with the values, otherwise, if you need
it to be dynamic you pretty much have to re-read it each time.

--
Curt Christianson
site: http://www.darkfalz.com
blog: http://blog.darkfalz.com

[Sandy]

Hi Russ -

Thanks for your response. My menu items don't change very often. Could you
be more specific on "use the Cache object to store them and then invalidate
the cache"?
--
Sandy
"Russ Farris" wrote:

Sandy,

Depends on your need if the menu items don't change very often then you can
always use the Cache object to store them and then invalidate the cache.

Or alternatively you could always use an XML file to store your menu items
and parse the XML and them dynamically that way.

We use both SQL and XML files where I work. Both are practical but you do
want to watch your round trips to the database.

Russ

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:EB******** *************** ***********@mic rosoft.com...

Hi Curt_C -

Thanks for your response! I was thinking about just using hyperlinks and
putting them into a user control as an alternative.

Your statement "If not stick it into a control with the values" . . . can
you be more specific?

--
Sandy
"Curt_C [MVP]" wrote:

Sandy wrote:
> Hello -
>
> I have a book that illustrates pulling menu items from a Sql Server
> table
> into an ascx via a stored procedure. Is this something that is done in
> the
> real world?
>
> I do like the effect when viewing it in the source code, however,
> because it
> doesn't show the complete path to the file. (I'm talking about
> Internet
> Explorer click View, click source code.)
>
> It does seem like it causes an undue amount of trips to the server,
> although
> the pages themselves in my application require a trip to the server in
> many
> cases.
>
> Can anyone give me any reasons why or why not to do it this way?
>
Does the menu change (is it really something that needs to be dynamic)?
If not stick it into a control with the values, otherwise, if you need
it to be dynamic you pretty much have to re-read it each time.

--
Curt Christianson
site: http://www.darkfalz.com
blog: http://blog.darkfalz.com

[Frankie]

You basically have two decisions to make, and two options for the
implementation of each:
DECISION 1: Implement menu as (1) a user control OR (2) put it into each
page by itself (i.e., not encapsulated in a user control).
DECISION 2: Create the menu items as (1) hard-coded into the menu's HTML
definition OR (2) dynamically load the menu items into the menu at runtime.

Any combination of these decisions/implementations can happen. Which you go
with can be determined by a number of factors.

I have a book that illustrates pulling menu items from a Sql Server table
into an ascx via a stored procedure. Is this something that is done in
the real world? << Yes - all the time.
I do like the effect when viewing it in the source code, however, because
it doesn't show the complete path to the file. << Not sure what you're talking about... as the browser MUST have a complete
path, otherwise it can't possibly retrieve the file from your Web server.
It does seem like it causes an undue amount of trips to the server << .... and Can anyone give me any reasons why or why not to do it this way?<<

I'll address both:
Yes - and that's what Russ' post was addressing. If you are loading the menu
items dynamically, then the code that loads the items into the menu can
first retrieve the menu items from any number of locations, including the
database, an XML file, or any number of objects loaded in any number of
locations in memory (Application state, session state, the Cache object,
etc - each with its benefits and drawbacks). For performance reasons you
would want to reduce number of trips to the database, and you wouldn't want
to be reading an XML file every time either. That's why you'd want to pull
the menu items from some location in memory. The Cache object is a great
place to do this - but you'd have to make sure that your code doesn't assume
the data is there (i.e., have it look to the Cache first, then if it's not
there, then go to the database OR xml file; which ever is persisting the
items). You'd also have to take specific steps to ensure that stale data
doesn't exist in the Cache (i.e., you don't want to update the database or
XML file that is holding the menu items without ALSO invalidating the
Cache - which is a big way to say "Clear the Cache").

Remember, you don't have to make it this complex. If you have a simple Web
site with just a few pages that change infrequently, then one
straight-forward (yet flexible) way to go would be to store the menu items
in an XML file and then load those at runtime into the menu.

If you have a more sophisticated Web site with much higher traffic levels
and more complex needs (like showing different menus depending on whether
the user is logged in or not, and if they are, then showing them certian
menu items depending on what they have permissions to see), then you would
certainly benefit from storing the menu items in a database (and not
hard-coding them or storing them in an XML file). Then, for performance
reasons you'd want to have the menu's code behind logic retrieve the menu
items from memory (and go to the database only if not available in memory).

Regardless of the simplicity or complexity of your site, it would almost
always be a good idea to put the menu in a user control and not hard-code it
into each aspx page (even if you have just a few pages).

HTH

-F

-HTH

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:D4******** *************** ***********@mic rosoft.com... Hi Russ -

Thanks for your response. My menu items don't change very often. Could
you
be more specific on "use the Cache object to store them and then
invalidate
the cache"?
--
Sandy
"Russ Farris" wrote:

Sandy,

Depends on your need if the menu items don't change very often then you
can
always use the Cache object to store them and then invalidate the cache.

Or alternatively you could always use an XML file to store your menu
items
and parse the XML and them dynamically that way.

We use both SQL and XML files where I work. Both are practical but you
do
want to watch your round trips to the database.

Russ

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:EB******** *************** ***********@mic rosoft.com...

> Hi Curt_C -
>
> Thanks for your response! I was thinking about just using hyperlinks
> and
> putting them into a user control as an alternative.
>
> Your statement "If not stick it into a control with the values" . . .
> can
> you be more specific?
>
> --
> Sandy
>
>
> "Curt_C [MVP]" wrote:
>
>> Sandy wrote:
>> > Hello -
>> >
>> > I have a book that illustrates pulling menu items from a Sql Server
>> > table
>> > into an ascx via a stored procedure. Is this something that is done
>> > in
>> > the
>> > real world?
>> >
>> > I do like the effect when viewing it in the source code, however,
>> > because it
>> > doesn't show the complete path to the file. (I'm talking about
>> > Internet
>> > Explorer click View, click source code.)
>> >
>> > It does seem like it causes an undue amount of trips to the server,
>> > although
>> > the pages themselves in my application require a trip to the server
>> > in
>> > many
>> > cases.
>> >
>> > Can anyone give me any reasons why or why not to do it this way?
>> >
>> Does the menu change (is it really something that needs to be
>> dynamic)?
>> If not stick it into a control with the values, otherwise, if you need
>> it to be dynamic you pretty much have to re-read it each time.
>>
>> --
>> Curt Christianson
>> site: http://www.darkfalz.com
>> blog: http://blog.darkfalz.com
>>

[Sandy]

Thanks All!!
--
Sandy
"Sandy" wrote:

Hello -

I have a book that illustrates pulling menu items from a Sql Server table
into an ascx via a stored procedure. Is this something that is done in the
real world?

I do like the effect when viewing it in the source code, however, because it
doesn't show the complete path to the file. (I'm talking about Internet
Explorer click View, click source code.)

It does seem like it causes an undue amount of trips to the server, although
the pages themselves in my application require a trip to the server in many
cases.

Can anyone give me any reasons why or why not to do it this way?

--
Sandy