…but we have ways of dealing with these critters.
I had a situation with a client whereby I wanted to introduce the use of Content Types for a custom list, but I soon discovered that I needed a slightly different behavior than you would apply CTs to. In this case, I did have a different column set for each type that I wanted to define/use – no problem. I also wanted a different set of required fields for each type, even though there was overlap between the columns used for each CT – also no problem. I also needed a custom NewForm.aspx for each CT – OK, that’s no problem either. The default EditForm.aspx (or more to the point, the ListFormWebPart control) should have been good for both cases – or so I thought.
Now the tricky part.
As it turned-out, when the defintion of each content type is non-overlapping, something that is usually desirable or at least acceptable, the standard process you would follow to create these custom types leads you smack into a dilema. If you want the EditForm.aspx to behave the same way for each and every Content Type – good luck.
In other words, I needed a different input form for each type, but I also needed a single all-encompassing item editing form for all Content Types. You’ll recall that the standard EditForm.aspx page will present just the columns that correspond to that type. You can select another CT while in the editing form, but that’s clunky.
It’s like calling the base class in a derived type – wee!