Getting parent page classname?

[darrel]

I have this structure:

mypage.aspx (class = mypage)
myusercontro.ascx

On the mypage.aspx I can declare a variable:
animal = "monkey"

I can read this from the UC by simply doing this:
mypage.animal

How can I do that if I don't know which parent page the UC is being loaded
into (ie, it's being dynamiacally loaded)? I'm not sure how to find out what
the classname of the parent page is from the UC.

DISCLAIMER: It's my understanding that this isn't usually the preferred
method of passing data between the two and that, rather, I'd be better off
having the parent tell the UC what the variable is, instead of relying on
the UC to read it from the parent. I'm warming up to that concept, but, in
this case, it seems to be more work tha not. For instance I have 10 parent
pages and 10 UCs. If I set the variable in 10 UCs, and have each UC read it,
I'm only needing to maintain/set 10 bits of code. However, if the 10 parent
pages need to tell each individual control, then that's 100 bits of code
that need to be created to maintain things. So, to ask a second question, is
my logic wrong? If so, what are the drawbacks to my line of thinking (having
the UC read the variable from the parent)? (John has got me thinking down
this road...so, thanks John! and if anyone else would like to add their
opinion to the matter, please do!)

-Darrel

 

[John Saunders]

I have this structure:

mypage.aspx (class = mypage)
myusercontro.ascx

On the mypage.aspx I can declare a variable:
animal = "monkey"

I can read this from the UC by simply doing this:
mypage.animal

Have you tried that? I don't believe it will compile, and I don't know what
it would mean if it did compile. Which instance of mypage would this be
referring to?

How can I do that if I don't know which parent page the UC is being loaded
into (ie, it's being dynamiacally loaded)? I'm not sure how to find out
what
the classname of the parent page is from the UC.

DISCLAIMER: It's my understanding that this isn't usually the preferred
method of passing data between the two and that, rather, I'd be better off
having the parent tell the UC what the variable is, instead of relying on
the UC to read it from the parent. I'm warming up to that concept, but, in
this case, it seems to be more work tha not. For instance I have 10 parent
pages and 10 UCs. If I set the variable in 10 UCs, and have each UC read
it,
I'm only needing to maintain/set 10 bits of code. However, if the 10
parent
pages need to tell each individual control, then that's 100 bits of code
that need to be created to maintain things.

Actually, no. If you've got 10 UC all referencing the same piece of data,
then you should consider pulling that piece of data out into a base class
from which all 10 UC derive. There would be only a single property. Also, do
you really have 10 separate user controls all requiring the same piece of
data, and they're used from 10 separate pages and are dynamically loaded?

Also, if the user controls all know the name of the variable, then the page
can't change the name of the variable or, for instance, put it in Cache or
Session.

So, to ask a second question, is
my logic wrong? If so, what are the drawbacks to my line of thinking
(having
the UC read the variable from the parent)? (John has got me thinking down
this road...so, thanks John! and if anyone else would like to add their
opinion to the matter, please do!)

Children should not know that much intimate detail about their parents!

John Saunders

P.S. Your way, if something bad happens to that variable (for instance, if
it got set to Nothing), then your culprit could be any one of 10 UC. My way,
only the page can possibly have done that because the UC have no access to
the variables of the page.

 

[darrel]

Have you tried that? I don't believe it will compile, and I don't know
what

it would mean if it did compile. Which instance of mypage would this be
referring to?

Hmm...actually, let me try it (it didn't give a syntax error, so I assumed
it'd compile...)

Well, I just tried it, and it seems to work fine. Here's the specifics of
what I have:

My ASPX page:
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="default.aspx.vb"
Inherits="districts.default9th" %>
in the codebehind...

public shared currentDistrict
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
currentDistrict = "9"
End Sub

My Control:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
dim district as string = default9th.currentDistrict
response.Write ("district: *" & district & "*")
End Sub

That seems to work.

Actually, no. If you've got 10 UC all referencing the same piece of data,
then you should consider pulling that piece of data out into a base class
from which all 10 UC derive. There would be only a single property. Also, do
you really have 10 separate user controls all requiring the same piece of
data, and they're used from 10 separate pages and are dynamically loaded?

Here's the scenario:

We're building a site that will have 10 (or more) 'sub-sites' within them.
They'll all share the same core set of features with the only differences
being which 'district' they belong to. Depending on that, they'd render
different content/graphics/menus, etc.

So, I saw 3 options:

1) build one page and pass the 'district' info in via a querystring
2) build one page and handle the 'district' declarations via URL rewriting
3) create one parent 'template' ASPX page for each district, and set the
unique info there.

The advantage of #3 was that it will be fairly easy for us to develop a
completely new template if one of the 10 districts desides they want
something radically different.

The usercontrols include things like the site menu, breadcrumb navigation,
side bars, content, directories, feedback forms, etc. They'll all work the
same, but will need to know which 'site' they're presently being loaded
into.

I think the main problem I am having is the whole OOP concept of the base
classes.

Also, if the user controls all know the name of the variable, then the page
can't change the name of the variable or, for instance, put it in Cache or
Session.

Well, the page wouldn't need to...at least not this specific variable.

Children should not know that much intimate detail about their parents!

;o)

What if you come from a liberal family? ;o)

P.S. Your way, if something bad happens to that variable (for instance, if
it got set to Nothing), then your culprit could be any one of 10 UC.

Ah...well, the thing is this variable won't change. The ASPX page sets it
and that's it. The concept is like this:

district1.aspx
- loads all the UCs and they need to know they are currently in the
'district 1 page'

district1.aspx
- loads all the UCs and they need to know they are currently in the
'district 2 page'

etc...

-Darrel

 

[darrel]

This also works, but I'm guessing this is a horrendous hack:

I made a new class called sharedVariables.

I can then set a variable in this from anywhere and read it from anywhere.
So, the aspx page can set it:

projectclass.sharedVariables.district = "9"

and any UC can read it:

district = projectclass.sharedVariables.district

Now, this is simple, and it works. But I'm guessing there's a big catch to
this that I'm not seeing?

-Darrel

 

[John Saunders]

Hmm...actually, let me try it (it didn't give a syntax error, so I assumed
it'd compile...)

Well, I just tried it, and it seems to work fine. Here's the specifics of
what I have:

My ASPX page:
<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="default.aspx.vb"
Inherits="districts.default9th" %>
in the codebehind...

public shared currentDistrict
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
currentDistrict = "9"
End Sub

My Control:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
dim district as string = default9th.currentDistrict
response.Write ("district: *" & district & "*")
End Sub

That seems to work.

That only "works" because currentDistrict is Shared. You also have a
synchronization problem, as you can have multiple requests trying to set
currentDistrict at the same time. If it is a constant, that's ok, but in
general, it's a problem.

Here's the scenario:

We're building a site that will have 10 (or more) 'sub-sites' within them.
They'll all share the same core set of features with the only differences
being which 'district' they belong to. Depending on that, they'd render
different content/graphics/menus, etc.

So, I saw 3 options:

1) build one page and pass the 'district' info in via a querystring
2) build one page and handle the 'district' declarations via URL rewriting
3) create one parent 'template' ASPX page for each district, and set the
unique info there.

The advantage of #3 was that it will be fairly easy for us to develop a
completely new template if one of the 10 districts desides they want
something radically different.

The usercontrols include things like the site menu, breadcrumb navigation,
side bars, content, directories, feedback forms, etc. They'll all work the
same, but will need to know which 'site' they're presently being loaded
into.

When you say that they differ based on the district, do you mean that they
differ based on the value of a string, or do you mean that they differ based
on information about a district?

At any rate, I now see that "district" isn't really a property of the page,
but is rather a property of the user session. I recommend that you place it
in Session state, and have the user controls fetch it from there.

I think the main problem I am having is the whole OOP concept of the base
classes.


Well, the page wouldn't need to...at least not this specific variable.


;o)

What if you come from a liberal family? ;o)

Then you still have to watch out for local laws...

Ah...well, the thing is this variable won't change. The ASPX page sets it
and that's it. The concept is like this:

district1.aspx
- loads all the UCs and they need to know they are currently in the
'district 1 page'

This page should set:

Session("District") = 1

district2.aspx
- loads all the UCs and they need to know they are currently in the
'district 2 page'

This page should set:

Session("District") = 2

John Saunders

P.S. You seem to be new to OOP, so the following is something to just keep
in the back of your mind. Depending on how the controls change based on the
district, you might want to consider using something like the Abstract
Factory Pattern. It would allow you to have multiple pages, multiple user
controls and multiple districts, with few if any dependencies between them.
A page could create whatever user controls it needed, and would
automatically get the control customized for the district. The page wouldn't
even have to know how many districts there are.

 

[John Saunders]

This also works, but I'm guessing this is a horrendous hack:

I made a new class called sharedVariables.

I can then set a variable in this from anywhere and read it from anywhere.
So, the aspx page can set it:

projectclass.sharedVariables.district = "9"

and any UC can read it:

district = projectclass.sharedVariables.district

Now, this is simple, and it works. But I'm guessing there's a big catch to
this that I'm not seeing?

If these are variables and not constants, then there's a really big catch -
multiple requests are accessing that data at the same time, with no
synchronization! Big no-no!

John Saunders

 

[darrel]

That only "works" because currentDistrict is Shared. You also have a
synchronization problem, as you can have multiple requests trying to set
currentDistrict at the same time. If it is a constant, that's ok, but in
general, it's a problem.

Yes, that was the one 'catch' I could think of. Page1 gets loaded by person
a, it gets set, then page2 gets loaded by person b and it resets again. Then
person a does something to trigger a postback, and things can get messy.

I could just have the UC's read the variable on load, and then store it
themselves for postback, but I can see where in more elaborate cases the
synchronization issue would become a problem.

When you say that they differ based on the district, do you mean that they
differ based on the value of a string, or do you mean that they differ based
on information about a district?

Umm...either/or I guess. Point being that I have 10 unique ASPX pages, but
the same control will be loaded into each one and will need to behave
slightly differently depending on which ASPX page loads it. The UC needs to
know that specific information. For instance, all 10 pages are going to load
a usercontrol that will render the site menu from an XML file. Whenever that
UC is loaded, it needs to know what district page it is in so it loads the
appropriate XML file for that district.

At any rate, I now see that "district" isn't really a property of the page,
but is rather a property of the user session. I recommend that you place it
in Session state, and have the user controls fetch it from there.

Umm...well, it IS a property of the page in that district9.aspx will always
be the template for district 9 pages.

This page should set:
Session("District") = 1

Hmm...so, if the user hops from district1 page to district2 page, I'm still
resetting the session state. What is the advantage of that vs. resetting a
variable?

And since the session state (from my understanding) requires cookies, could
that cause any problems for non-cookied people? (Not that I'm terribly
concerned about the non-cookie folks, but I like to keep as much of the
logic on the server side as I can).

P.S. You seem to be new to OOP

Yes. My background has progressed from art major -> html jockey -> asp
hack -> better asp.net hack

;o)

I have taken some basic Java courses which gave me a bit of a foundation,
but I definitely need to do some more reading about OOP in general.

Thanks for all your advice, John. I'll look up the factory model
information...

-Darrel

 

[darrel]

If these are variables and not constants, then there's a really big
catch -

multiple requests are accessing that data at the same time, with no
synchronization! Big no-no!

Hmm...I can see that now.

Page1 loads, sets the variable, and then starts bringing in all of the
usercontrols which, in turn, read that variable one-by-one as they load in.
If page2 is loaded by someone else during page 1's loading of the UCs, the
variable would obviously change. That'd be no good. ;o)

-Darrel

 

[John Saunders]

Yes, that was the one 'catch' I could think of. Page1 gets loaded by
person
a, it gets set, then page2 gets loaded by person b and it resets again.
Then
person a does something to trigger a postback, and things can get messy.

I could just have the UC's read the variable on load, and then store it
themselves for postback, but I can see where in more elaborate cases the
synchronization issue would become a problem.


Umm...either/or I guess. Point being that I have 10 unique ASPX pages, but
the same control will be loaded into each one and will need to behave
slightly differently depending on which ASPX page loads it. The UC needs
to
know that specific information. For instance, all 10 pages are going to
load
a usercontrol that will render the site menu from an XML file. Whenever
that
UC is loaded, it needs to know what district page it is in so it loads the
appropriate XML file for that district.

Well, no, that UC doesn't need to know what district it's "in", it needs to
know the name of the XML file. Let someone other than the UC figure that
out, then just tell the UC which XML file to load.

Umm...well, it IS a property of the page in that district9.aspx will
always
be the template for district 9 pages.

That's just an implementation detail. What if you decided some day to use a
single page, like, default.aspx?district=1? The user controls shouldn't have
to know that you changed the name of the page!

Hmm...so, if the user hops from district1 page to district2 page, I'm
still
resetting the session state. What is the advantage of that vs. resetting a
variable?

Ahah! You didn't say that the user can change districts! I'll have to think
about that.

At any rate, the big difference is that a Session "variable" is global to
all pages, and a real variable in a page is not.

And since the session state (from my understanding) requires cookies,
could
that cause any problems for non-cookied people? (Not that I'm terribly
concerned about the non-cookie folks, but I like to keep as much of the
logic on the server side as I can).

If you can't exclude non-cookied people from your site, then you can use
cookieless sessions.

Yes. My background has progressed from art major -> html jockey -> asp
hack -> better asp.net hack

;o)

You and many others!

I have taken some basic Java courses which gave me a bit of a foundation,
but I definitely need to do some more reading about OOP in general.

Thanks for all your advice, John. I'll look up the factory model
information...

Actually, I'd recommend that you not do that. Instead, I think you should
get this to work in a way that you'll understand today. "Tomorrow", you can
learn from this "mistake", and you'll then understand what the Abstract
Factory pattern is for and how to use it.

John Saunders

 

[darrel]

Well, no, that UC doesn't need to know what district it's "in", it needs
to

know the name of the XML file. Let someone other than the UC figure that
out, then just tell the UC which XML file to load.

Ahh...OK. So, then the ASPX page should simply tell the UC 'load districtX
XML'.

It seems like ultimatly, it probably just makes sense to pass a parameter to
the UC as the aspx page loads it. I'd have to do it for each UC, but in the
end, that's probably not as a big of a deal as I'm making it to be.

That's just an implementation detail. What if you decided some day to use a
single page, like, default.aspx?district=1? The user controls shouldn't have
to know that you changed the name of the page!

Well, right. Hence my original question...how can a UC get the 'name' of the
parent page dynamically.

Ahah! You didn't say that the user can change districts! I'll have to think
about that.

Yea, it's really 10 distinct sections of one larger site. All the sections
will share pretty much the same functionality (hence wanting to only use one
set of UCs).

At any rate, the big difference is that a Session "variable" is global to
all pages, and a real variable in a page is not.
Gotcha.

Actually, I'd recommend that you not do that. Instead, I think you should
get this to work in a way that you'll understand today. "Tomorrow", you can
learn from this "mistake", and you'll then understand what the Abstract
Factory pattern is for and how to use it.

Well, that's not bad advice. Actually, this current phase of the site is
actually a rewrite of phase I. So, I'm already improving on all the mistakes
I made the first round.

The big hangup is I'm still thinking a bit like ASP. Make a page, use SSIs
to include/share a bunch of functions. And just declare a few variables at
the top of the page so all the included functions can use it.

In Phase I I relied a lot of query strings as the 'shared' variable across
controls. But I'd rather try something more efficient and keep the variable
out of the query string if possible.

Ideally, the XML file is going to contain a variety of information I want
other UC's to see. Instead of having each UC read the same XML file, I'm
thinking it'd be better if one UC read it and sent the data to the other
UCs.

Anyways, you've given me plenty to think about. Have a good new year!

-Darrel

 

[John Saunders]

Ahh...OK. So, then the ASPX page should simply tell the UC 'load districtX
XML'.

It seems like ultimatly, it probably just makes sense to pass a parameter
to
the UC as the aspx page loads it. I'd have to do it for each UC, but in
the
end, that's probably not as a big of a deal as I'm making it to be.

It's not, really. What's 10 assignment statements cost you?

Well, right. Hence my original question...how can a UC get the 'name' of
the
parent page dynamically.

It shouldn't, for one thing, and for another, knowing the name won't help
it. Your example worked both because strDistrict was Shared and because you
hardcoded the name of the page (the page class, actually). That doesn't work
if the name of the page is in a variable. You have to do things with
Reflection that should probably be avoided at this stage. Besides, the user
controls should not know anything at all about the pages they're on. Believe
me, you'll be much better off!

Yea, it's really 10 distinct sections of one larger site. All the sections
will share pretty much the same functionality (hence wanting to only use
one
set of UCs).


Well, that's not bad advice. Actually, this current phase of the site is
actually a rewrite of phase I. So, I'm already improving on all the
mistakes
I made the first round.

The big hangup is I'm still thinking a bit like ASP. Make a page, use SSIs
to include/share a bunch of functions. And just declare a few variables at
the top of the page so all the included functions can use it.

In Phase I I relied a lot of query strings as the 'shared' variable across
controls. But I'd rather try something more efficient and keep the
variable
out of the query string if possible.

Ideally, the XML file is going to contain a variety of information I want
other UC's to see. Instead of having each UC read the same XML file, I'm
thinking it'd be better if one UC read it and sent the data to the other
UCs.

Independance is better: have each UC be able to read their own XML file.
Perhaps the parameters for UC1 are all within an element called <UC1Params
/>. So, write your code so that it works whether that element is the only
one in a file, or whether parameters for all 10 UCs are in the file:

File1.xml:
<parameters>
<UC1Params />
<UC2Params />
</parameters>

File2.xml:
<parameters>
<UC9Params />
<UC10Params />
</parameters>

Pass File1.xml to UC1 and 2 and File2.xml to UC9 and 10, and they shouldn't
care what else is in the file.

Anyways, you've given me plenty to think about. Have a good new year!

Same to you.

John Saunders