Iron Coder: Review of Darren’s Round 1 Solution

Darren has posted up his round one solution. I’ve had a chance to give it a quick once over and I can see where he is coming from with the design. It is similar in spirit to the extender provider approach although he puts the custom security code in the controls themselves.

I think Darren’s approach will fall down where Josephs will which is the cost of continually sub-classing controls. For example, I could add close to any of the other controls on the toolbox right now and they would just work immediately – no need to do any work to get any benefits.

Admittedly that might be a bit short sighted considering somethings can be harder to do from an extender provider, but it’d be interesting to see if I would ever have to pay for the decision to use an extender provider over sub-classing. Actually, we used this extender provider approach on a project after most of the UI had been constructuted and it saved us a great deal of time.

One hybrid approach you could take is sub-class the container controls like forms and user controls. Any component on the design surface can be an extender provider, so you can get some of the benefits without actually having to drag the thing on in the first place.

If you look at the design surface in VS.NET today you can see a number of properties that don’t actually exist – such as Accessibility, this is an example of an extender provider which is baked into the design surface without you having to do anything.

Finally – Darren makes a really good point about the potentially ever growing if-block. I had contemplated factoring this out into some kind of factory of control handlers where the factory dynamically discovered a handler for each control – but the only non-hardcoded way I could think to do it was by a brute force search of the assemblies loaded into the AppDomain – since I only had one specialisation so far I didn’t think it was worth it.

My Iron Coder Solution for Round 1

I justed posted up my Round 1 Iron Coder solution at Project Distributor. I wonder how Joseph is coming along with his, or even if he has checked his RSS feeds yet to know when the deadline is – although he has plenty of time to get it done.

For my solution I built an extender provider (duh) which adds a “Roles” property to each component on the design surface. I’ve done a really quick Camtasia screen recording to document the user experience.

Currently it will work with controls generically but tab pages in particular need some special attention. The reason is that although a TabPage ultimately derives from Control, there are somethings that you can do with a Control that you can’t do with a TabPage. For example if I set the Visible property on a TabPage to false it has no effect at all.

This is because the tab control actually renders the tabs, not the individual tab pages, and it doesn’t honour the visible property, so the only way to do it is remove the tab page from the collection of tab pages. Here is my lock-down code where you can see the customisation.

One thing that the sub-classing camp does have going for it is that it has a nice logical place to put snippets of code like this – I just happen to think sub-classing is a high price to pay for it. Over time I think the extender provider approach will show its versatility when we throw a few more controls into the mix – in my case it takes little to no extra effort to do that.

In the long-run however neither sub-classing or extender providers are the way of the future – Avalon has a much more different object model and I wouldn’t be surprised if security and validation could be painted on as if it were a style.