CollapsiblePanelProperties Adjustments

Hmm - I'm not super against it but the business of adding "helper" ctors often gets complicated for classes that have more than a few properties. So on the other hand...

In your example above, you save the TargetControlID line, but you're still left doing all the others. And if there's several properties, you end up with the difficult-to-understand code:

collapsibleExtender1.TargetProperties.Add(new CollapsiblePanelProperties(panel1.ID, panel1.ID, textBox1.ID,"Opened","Closed", true, null, null, null, 10, 50))

Or else you end up with 10 different constructors with various permutations of the property values, which has always bothered me too.

It makes a lot more sense for things like ConfirmButton, but then you've got a consistancy issue that some controls have helper constructors and some don't.

Anyway, again I don't have really strong feelings here, but I do need to be evangelized. :)

Oh a quick note on your code above: you don't need to pass in ClientIDs there. The framework will do that for you automatically (it does basically the same code you've got there) provided it's in the right naming scope to find the control you're referencing.

Shawn

I completely agree, helper ctors can be a real pain in the butt. And there's nothing I hate more than having to pass null into a constructor. But I don't think that having a couple would be an "unclean" design. I think every ExtenderProperties object should have a couple additional ctors (where appropriate) to reduce the lines of code necessary to complete a task.

For example, every ExtenderProperties object should have the following constructor:

Public Sub New(ByVal targetControlID As String)

...because every Extender has a Target.

From there, I think the CollapsiblePanelProperties object should have the following constructors

Public Sub New(ByVal targetControlID As String, ByVal textLabelID As String, _
ByVal labelText as String, ByVal suppressPostBack As Boolean)
Public Sub New(ByVal targetControlID As String, ByVal textLabelID As String, _
ByVal openedText As String, ByVal closedText as String, ByVal suppressPostBack As Boolean)

I don't thnk that would be too crazy, and could cut down on the number of lines I have to use to initialize it programmatically, without sacrificing too much readability.

On another note, the ClientID thing is a function of the design I'm using. The naming context is not in the correct scope because I'm using a UserControl to define a standard header (will make is a composite control eventually) that has a couple properties (like "Title" and "IconUrl") to create a poor-man's portal window. That UserControl gets added to the Panel's controls collection, which means the name is inaccessible to "FindControl". Now, if FindControl was recursive (I think there should be an overloaded method that is, which is a big beef of mine since the v1 days) that would be another story.

Anyways, it was just a thought. My company's coding standards say that required properties that do not have defaults should be included in constructors where appropriate. For me, it's always nice when IntelliSense gives you a few other options when instantiating a new object.

Thanks for your time! Looking forward to the next drop ;).