web controls are NOT good use of encapsulation

[Jason Shohet]

There seems to be no way for an ascx control to grab a value from a parent
page. It can call an event, but nothing can be returned to the control.
So if a control needs a value that is available off the parent page, the
parent is forced then to set values on the control, which means that the
control is tightly bound to the page

--jason shohet

 

[Scott]

OK; I'll bite, what kind of value do you want to grab from the parent page (a property of some
sort, or a child control on the parent page)? What have you tried so far?

Scott

 

[Jason Shohet]

Thanks for biting Scott & sorry i didn't get back earlier to the ng.
The issue is encapsulation & polymorphism.

My goal: An ascx control should be able to say, "I need an number for an
organization, in order to work (i've gotta persist some data to the
database). I don't know who my parent is... some webpage. I don't care.
But i want to call a function on you called 'GetOrg( )' and I want you to
return me a number."

The problem: ascx controls cannot call functions on the parent that return
a value. IOTW, this doesn't work:

strOrg = myParent.InvokeMember("GetOrg", System.Reflection..., new
object[]{});

It works if GetOrg is a function that just returns void, IE:

myParent.InvokeMember("GetOrg", System.Reflection..., new object[]{});


This is an awful problem because now I have to resort to the parent webpage
(which the control sits on) manually setting values on the control... I
wanted to avoid that and it doesn't seem like its possible to do.

 

[Jason Shohet]

You hinted that Reflection is hard on resources, is that true?

you might create your own Page subclass, then in your control you could do the following:
....
MyPage page = this.Page as MyPage;
if (page != null)
OrgValue = page.GetOrg();
else
OrgValue = // some default

Ok, above: If this.Page.GetOrg() is used when the control sits on a
regular webpage, it won't work because that func. hasn't been compiled as
part of the class (?) -- so .NET doesn't see it unfortunately at
compiletime.
But as you say, if I inherit a new page subclass, and add that method, and
compile that page, this.Page.GetOrg() will be a func. available to be seen
from the control, thats a good idea. But it sorta limits reusability
because I'll have to remember every time I use this control that it can only
be placed on a page subclass which has this method on it. A regular webpage
with this method on it, Page.GetOrg() won't be able to see it w/o
reflection, and with reflection it can't return a value (seemingly). Still
thats a good solution.

Or, if the Org value is something that is global to the application,

consider using the Global.asax; then the Control could do:

OrgValue = Global.GetOrg();

I'm not sure how global.asax works in the above, to tell you the truth. I
always thought the global is so you could do things on certain global events
like Application.Start. IE, In Application Start, I would get the
connection string from someplace (like web.config), and put it into the
Application object. Then later on I can get it back from the application
object. But can the global.asax store a value, without the applicaiton
object / session to help it? I'll read up on this a bit

case you describe is kind of opposite to the way I think of the

relationship between Pages/Controls -- the Page class (whether a

subclass or not) should know what the contract for the child controls it's

using are, and set them up accordingly.... but I'm not a

fanatic about it

Ok, but the more the parent has to know about items on the control the less
"plug-and-play" it is. If I have the parent setting a hidden field,
hf_orgid, well I've gotta remember now to do that everytime I use this darn
control. If the hidden field isn't populated, the control won't work. It
seems a better tactic is for the control to attempt to manage as much as it
can about how it functions. The control knows it needs an organization # to
work. So let it broadcast a call, "Hey, GetOrg() ! Whomever is my
parent and hears me, give me that org #". If I forget about this control
and pick it up in 2 years and plug it in somewhere, it will blow up
immediately on GetOrg. I'll take a look & see that its looking for a func.
on its parent that returns an org #. Thats easy to work with.
But if I pick up the control after 2 years & use it somewhere, and it
doesn't work because some hidden field or value isn't set correctly, I'll
have forgotten what I need to do. I'll think, "Maybe the control has a bug
etc". I'll have to trace it, debug it, only to find out that some hidden
field has to be set somehow, at some point in time, from outside the
control. Of course thats what commenting code is for, but still it seems
neater to see that there's a function call built-in to the control which is
expecting back a value from its parent.

Sorry 2 babble & ty for the advice, Jason Shohet

 

[Scott]

It's not as inexpensive as a method call; it depends on how you are using it -- in the end it's up to you. The example I sent you
does return a value, so you should be able to run some tests and see if you are going to have a problem.

As far as a design pattern for Parent/Child relationships in ASP.NET; I guess my preference is for a control that requires a
particular value from the outside to enforce that via the compiler -- hence my preference for subclassing -- or at runtime using
exceptions (i.e. "I'm a control that needs something and you didn't provide it..."). What you suggest -- broadcasting -- sounds like
something I might have done in my old Perl/scripting days; arguably, I think the C# approach makes for better applications and
certainly makes it easier to build larger applications.

Good luck.