CAML is Here To Stay
I did three presentations at last week's Book Publisher's Summit, talking to publishers and authors on topics that would be great for developer-focused books on SharePoint Products, namely (a) programming with lists and libraries, (b) site definitions, and because the topic will be alive for quite some time, (c) Web Parts (today's technology, not the Whidbey stuff).
I'll post on libraries and Web Parts shortly. I want to respond to something I heard someone say when I was talking about site definitions. Part of a good custom site definition is one or more good custom list definitions. Good custom list definitions require doing some work in CAML (Collaborative Application Markup Language), our XML-based means of accessing and rendering the contents of SharePoint lists.
This guy said that the buzz on the street is that CAML's days are numbered. Sorry. Not true.
CAML is just too useful to kill. It covers both data and rendering instructions. It lets our List Viewer Web Part fetch a list and its rendering instructions in one step and then only have to apply the rendering to the data. It's blazingly fast. It's also backward compatible with everything we've done to date.
Personally, I'd enjoy synching up with other camps and switching from CAML XML to ADO.NET XML for data, and from CAML XML to XSLT for rendering. But we have many, many other things to get done. (Do you really want this more than per-item security, synchronous events on libraries and lists, and easier deployability? These is what I get asked for most often.)
Actually, if someone wants such things that badly, they can code them into a custom Web service and add it to our environment. CAML is one of the ways we perform so well. It's XML. We -- and you -- can do a lot with it. We're keeping it.
What we need to do is provide lots and lots of examples on CAML. We need to stop ignoring it and start making it a normal part of SharePoint site development. I'm working on making that happen.
But of course, this is just my opinion -- I could be wrong. What do you think?