CAML still has its humps.
The last few days I found myself wrestling quite a bit with CAML. The basic idea was to replace the standard "Create New Document" button in a document library with some logic - if no document template is specified for the doclib, replace the button with three different buttons - Create Word Document, Create Excel Spreadsheet and Create Powerpoint Presentation.
This involved several operations to the SCHEMA.XML - wrapping the proper buttons in an <IfEqual> tag to check if the TemplateUrl property has been set, rendering the proper buttons, and adding a new createNewDocument javascript function to instantiate the Sharepoint.OpenDocuments class and open the new document in its proper editor.
All this sharply highlighted the problems with CAML as it stands today, and reminded me of what I felt when I first saw ASP code - total and complete panic. I remember opening Visual InterDev and being completely baffled by the huge mess of HTML layout and virulent yellow ASP tags, all thrown haphazardly and confusingly. It's possible to write neat code in classic ASP that seperates content from layout, but it sure as hell ain't easy. I loved ASP.NET and the code-behind model, even though it still has many drawbacks. I think it's a great improvement and encourages readble, understandable code.
CAML, unfortunately, is still deep in the phase that Classic ASP was in. Instead of HTML layout with embedded server-side commands, we have the main CAML flow interspersed with <HTML> and CDATA blocks. The CAML syntax itself takes some getting used to - like polish notation, it's hard for someone used to the function(arg1, arg2) syntax to read the <Function><Arg1><Arg2></Function> style. But it's definitely doable. What makes it unreadable is the fact that in between the program flow and logic of the CAML code is the final rendered output, in full. So a simple condition such as:
if (TemplateUrl = "")
RenderThreeButtons();
else
RenderOneButton();
Becomes a huge mass of HTML code, all escaped with CDATA delimiters. It's hard to find what you're looking for even when it's right in front of you. This is due to several problems:
- Lack of inclusion support. CAML doesn't allow me to define arbitrary chunks of code and then include them later on in the code. This means that I can't abstract code, but have to have it fully written every time. It also means that I can't reuse code - in the example above I needed to replace the button rendering code TWICE - once in the AllItems view, once in the WebFolder view.
- Lack of proper development tools and standards. Some of this is mitigated by a good XML editor, but certainly not all of them. This includes:
- A proper CAML editor that supports nested syntax highlighting - for the top-level CAML, the embedded HTML, and javascript/vbscript embedded in the HTML.
- Support for code-folding, like Visual Studio's regions. The ability to view the CAML logic without the rendered HTML would clear up the mess immensely.
- An ability to flatten a CAML structure into a templated rendered view. This means that the following structure (slightly snipped for clarity):
<HTML>Owner of list </HTML> <ListProperty Property="ListName" /> <HTML>is </HTML> <ListProperty Property="Owner" />
should be flattened into:
"Owner of list <ListProperty Property=ListName> is <ListProperty Property=Owner>" - all HTML nodes normalized into a single string, with the intervening CAML nodes turned into placeholders.
This is, I suppose, a call for Microsoft to improve CAML support in future versions of Sharepoint - according to this post it will still be there in future versions, and several replies have echoed my problems.
Additionally, it's a call for community efforts to improve CAML usability. U2U have already released a tool to ease creation of CAML queries, but there is still a lot more to do.
I will try, of course, to add my own contributions to the community's struggle with CAML, but I can't promise anything - my personal pet projects tend to get neglected after a while. :)
4 Comments
Comments have been disabled for this content.
Dave Thomas said
but does caml's benefits out weigh the pitfalls?
Why not just use ASP.NET?
Avner Kashtan said
To tell the truth, I'm not sure at all. I'm not sure we really need a whole new syntax and a whole new model just to describe Sharepoint data. Can't it all be replaced with a richer object model and have it embedded directly into ASPX files, rather than having the awkward schema.xml file rendered, automagically, into the a little WebPartZone?
I think it would be much better. We have here a server-side technology with absolutely no interoperability with other technologies, very limited programmability and a confusing syntax. The ideas I suggested above would make existing development easier, and is an absolute necessity if future versions will be based on CAML (which they probably will, since no-one likes completely rewriting the core engine, especially after they did it from SPS2001 already).
But given a choice, I'd go for a real .NET solution any day.
Dave Thomas said
get your finger out and start on a web form based code generator thingy!
Rodolfo said
Hi AvnerK I hope you are well. Here's my mission. I need to change the look and feel of Custom List I have created. I have just started to play if it. It looks awful. I put a few border=1 on the tables on the CDATA section to get some ideia. If you know and could help me. I need to know which properties there display the fields names and the data within the fields. My mission is if achievable is to change the layout of the list and just display the title once you click the title it will display the other fields of the List. I hope you could give me some directions Rodolfo.Soares@eon-is.co.uk Many thanks Regards Rodolfo Soares