Conditional Mandatory Fields and Inter-form Filtering
No, I'm not having that big neurotic breakdown you've all been expecting (although from the title one has to wonder). I'm on a quest. A quest for knowledge. A quest for an answer. Before I head off to dig into some Microsofties gray matter, I thought I would throw these questions out there for anyone to pick at.
SharePoint forms are pretty simple things. You define columns in a list and the ListFormWebPart will spit out a data entry form for all the fields, complete with the contract you created for each field (mandatory, html enabled, drop down list vs. checkboxes, etc.). This is great but it does have its limitations, namely two things you can do fairly easily with regular ASP.NET forms.
The first is the idea of a conditional mandatory field (or mandatory conditional if you prefer). Suppose you want the user to enter a Company name but only if they check a checkbox on the form first. This is handled by a simple event handler (CheckChanged on the checkbox) in the Web Form. However there's no interface in SharePoint to hook into the ListFormWebPart part this way (well, none that I know of). So you either define the field as mandatory or not. The alternative is that you build yourself an ASP.NET form in a custom webpart (or use SmartPart with a User Control) and do the coding yourself and then write the results out to your SharePoint list but now you're in development land rather than configuration land and it's expensive.
The second is filtering interdependant lists. There have been a few posts I've seen on this. Probably the best one I've seen is this one by Patrick Tisseghem in this blog. Suppose you have one list (Country) that needs to filter another (Province/State) which needs to filter yet another (City). Typical scenario. You don't want to show the list of every city to someone to pick from. You might also have a business condition where you don't want to present lists of information to some users based on some condition that's outside the scope of your SharePoint environment (say a corporate directory of who reports to whom). Anyways, again it's a fairly simple thing to do with regular ASP.NET by hooking into a change event on the list and rebinding the data to the lookup. Patrick's blog is a great tip however it does demand that you know the Guid for the list and runtime things like that to make it work. If you're trying to bake a solution into something like a SCHEMA.XML for a list you usually end up running into dead ends (see my frustration with not being able to define Lookup fields in the list definition for more on this).
Guids are a big part of SharePoint. Every site, every web, and every list has a guid to identify it. The trouble with guids is that they're only defined at runtime, meaning you either need to suck it out using CAML (which I think I've seen done by some posts by Ian Morrish before) do drop an albeit small but custom-written-none-the-less web part onto a page to get what you need. And to tie in with the "don't touch the system files in SharePoint or you'll be unsupported" thing that has reared it's head recently, you won't be able to do this very well with stock lists or admin pages.
Looking at the ListFormWebPart (and the other classes in the Microsoft.SharePoint.WebPartPages namespace) it may be possible to override the GetData and the RenderWebPart methods to do something funky before it hits the page. Anyways, if anyone has some interesting ideas to solving these it would be good to hear about them. It may only be that custom solutions (Web Parts) is what you need to do here but that's sometimes overkill. I'll post whatever results I find with discussions with others as we come up with them. Cheers!