Betrand Le Roy made a post called “Why you shouldn’t expose public properties from your pages”. For the 99% of the scenarios I agree with him since it would obviously prevent your control from being reused ubiquitously, but there is at least one scenario where I see this as acceptable: when creating a shell environment scenario like Windows Explorer or MMC.
We have the concept of a Library at Mimeo. The Mimeo Library implementation behaves a lot like MMC. You can plug in folder providers (analogous to MMC snap-ins or Explorer Shell Extensions) for the tree view on the left and then each of those folders have specific “item view” controls associated with them that get loaded into the right hand pane when the folder is selected. So these “item view” controls are specialized and are meant to be hosted in a certain environment that mandates certain behavior from them, as dictated by a abstract base control class they all derive from and provide specific behavior for, as well as provides a base set of hosting behvaior for them. I’d love to show a screen shot to provide better visualization of what I mean, but since we’ve only recently entered a beta process I can’t.
Now the only real question is: Why should the page be the shell? Why not another control? In actuality, it could and probably should be since I’m a big fan of componentizing, but that’s just the way it started since we didn’t need to reuse the whole browser anywhere else. Now we’re into the beta process so it’s not worth taking the risk of introducing bugs while extracting it. Hopefully after v1.0 release it’ll be a medium priority for v1.1.
That’s one case where it’s more legitimate to expose public properties from your page but not that much more legitimate.
I prefer to solve this problem the way we did with WebParts: WebParts need the presence of a special component on the page, the WebPartManager. And they also need a special container, the Zone. This way, the Page itself does not need to be specialized, but you can still have this class of serviced, connected components, and it’s still perfectly reusable.
Having to distribute your special version of Page with your components is really something that should be avoided.
What if you want to use some other components on the same page which want their own different version of Page?
Yeah, that’s why I stipulated that it’s not a perfect excuse since we should probably hoist the host out into a control that itself can be reused. Since we never need this functionality anywhere else we just started it in the page. So, in the end, I guess I do agree with you 100%.