It was a question of changing the class names (because they weren't panels) or making them actual panels.
I chose to make them actual panel controls, because that's how they are used (as a container). I got tired of always having to put a container inside a "panel" so I could actually put any content on the form. Making the controls be actual panels eliminated a bunch of "junk" XAML.
And it seemed harmless (since you can always put another layout control inside the panel).
If it is not harmless, I'll consider going the other way and renaming all the controls from blahPanel to blahDecorator - though I personally am not too keen on having to go back and add all that extra XAML into my forms.
Now is a good time for this discussion (today and tomorrow), because I'm just wrapping up for Beta 2.
I see what you are saying, and I find this to be a tough question.
Making the controls "invisible" makes them flexible, but ultimately adds to the XAML required on a form.
I tried making them be a "lookless" panel (inherit from Panel directly), but that's not possible. If they are actual "panel" controls, then they must control layout - that's the definition of a panel.
But I kept trying to put stuff "into" ValidationPanel, which of course didn't work. So I'd always have to go back and wrap the content with a StackPanel inside the ValidationPanel - that was the instigation for the change.
I suppose you are ultimately right. My guess is that 90% of the time having them be a real panel would be beneficial, but it probably precludes the other 10% from working at all...
But I do have to rename them, because keeping "Panel" on the end confuses me continually, and will almost certainly confuse many other people over the coming years.
I'm thinking either "Decorator" (to keep with the base class name) or "Provider". Or I could do what Microsoft appears to do and use no postfix at all:
Validator
Authorizer
ObjectStatus
That is probably the right answer.
Copyright (c) Marimer LLC