Archives / 2004 / November
  • Why you shouldn't expose public properties from your pages

    We often have users asking us how they can access some variable that's in their page class from their user or custom controls.
    The answer is that your page class can expose public properties, and then any control can cast its Page property to your specific Page-inherited class and gain access to the new properties.
    But the second half of the answer is that you should really not do that even though it's possible.
    There is a double reason for that.
    The first is that it's your page that should orchestrate your controls (by accessing their properties and methods), not your controls orchestrating your page.
    And the second, which is very close, is that your controls should not depend on your page implementing special properties or methods or containing specific controls. Otherwise, you're breaking one of the most important qualities of WebControls, that is their reusability. Any control should have the ability to be dropped on any page and just work.
    Your user and custom controls should be components, that is, they should be independant, encapsulated and reusable entities. It's your page (or containing controls) only that should orchestrate the controls and glue them together. The glue should stay outside and should never ooze inside.
    A consequence of that is that your Page generally has no good reason to expose new public properties, because no one should have to consume them.

  • How to split server styles

    If you've been developing custom WebControls, in some cases, you may have had to split a server-side style on two HTML elements. Usually we want to apply the border and similar properties to a container like a div or td, and the Font properties and ForeColor to a text element such as a link (because a link forces the color and text-decoration, for example).