Re: web controls are NOT good use of encapsulation
From: Scott (noemail_at_this-is-extra-hotmail.com)
Date: 04/14/04
- Next message: Mike Towle: "Creating Controls"
- Previous message: NH: "DropDownList - display each Item in different color"
- In reply to: Jason Shohet: "Re: web controls are NOT good use of encapsulation"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 14 Apr 2004 14:38:20 -0400
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.
"Jason Shohet" <__ash477@yahoo.com> wrote in message news:Oqm54ekIEHA.4020@TK2MSFTNGP10.phx.gbl...
> 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
>
>
- Next message: Mike Towle: "Creating Controls"
- Previous message: NH: "DropDownList - display each Item in different color"
- In reply to: Jason Shohet: "Re: web controls are NOT good use of encapsulation"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
