The product documentation for SharePoint 2010 includes extensive details about each of these approaches, together with examples and walkthroughs describing approaches to common client-side data access requirements. This documentation focuses on the merits and performance implications of each approach for different real-world scenarios, and it presents some guidance about how to maximize the efficiency of your data access operations in each case. Before you start, you need a broad awareness of the capabilities of each approach. The following table shows what you can do in terms of data access with the CSOM, the REST interface, and the ASP.NET Web services.
List join queries
External list queries
SharePoint Foundation object model access
Access to SharePoint Server functionality (beyond SharePoint Foundation)
So, you’ve finally succumbed to the hype and decided to use jQuery in SharePoint? Good for you. I’m sure you are fully prepared with the knowledge of the pros and cons using jQuery as well as have all the requisite knowledge.
You don’t? You mean you are going to copy and paste scripts from blogs and then ask the blogger to modify the script to work for your particular circumstance? Oh, that’s nice.
Well, assuming you actually want to understand what you are doing, maybe even learn a thing or two, I’ve decided to link to several of my past jQuery blogs in an order which will hopefully help you learn how to successfully use SharePoint and jQuery together. I’ll even do my best to keep this post updated as I write new blogs on the subject.
Before getting started…
Make sure you have some good background knowledge.
When you start using things like SPServices and the Client Object Model to query SharePoint list data you will need to understand SharePoint’s query language CAML. I always refer to it as the ugly crossbreed of XML and SQL.
Undoubtedly one of the most common tasks you will perform with jQuery is getting and setting SharePoint form fields. This blog walks you through the process with the most common field types. A corresponding blog post to this one is Setting SharePoint Lookup Lists w/ jQuery (+/- 20 items)because unfortunately at some point you will fall victim to this SharePoint quirk.
So, now that you understand the basics of using jQuery in SharePoint and know how to get/set SharePoint form fields, this blog helps you apply that knowledge to perform the common task of creating an automatic parent/child list relationship. There are MANY ways of accomplishing this functionality, but I actually prefer this method. It may be a little more technical than the other solutions I’ve blogged about for creating a Parent/Child list relationship, but this solution has the least impact on SharePoint and should also upgrade easily.
Okay, at this point you should be ready to start interacting with SharePoint list data using SPServices. This blog post walks you through the basics with a VERY commented script. If you think you have your head wrapped around reading list data with SPServices, you might also check out the following blog posts using SPServices to accomplish some tasks normally achieved using server side code:
Using SPServices & jQuery to Find My Stuff from Multi-Select Person/Group Field – Determines the groups a current user belongs to in order to determine if the current user is part of a group or person assigned to a list item.
Now that jQuery and SPServices is old hat, I walk you through the process of integrating SharePoint List Data into a third party jQuery library.
Other SharePoint tips and tricks using jQuery
So, here is a smattering of other blog posts on the subject which you may find helpful, or might give you ideas for your projects. Some of them are just academic, and some you can put into practice immediately.
What? Is this not enough? I’d say for the price you paid, it’s a bargain!!
I hope to do a few blog entries on more advanced topics like Callbacks, templates, and design patterns. Also, as we move towards SharePoint vNext I do think it might be a good idea to start to wean myself off of SPServices and start using the Client Object Model more (although nothing leads me to believe that SPServices will not work in vNext). So, look for me to start a series on the Client Object Model as well and provide any tips or tricks I learn along the way.
As always, let me know what YOU want to learn and I’ll see what I can do! Thanks again for stopping by.
Have you ever encountered the following error in Microsoft Office SharePoint Server (MOSS) 2007?
An error occurred during the processing of . The attribute ‘autoeventwireup’ is not allowed in this page.
I just searched for this using Bing and it seems like I’m not the only one who has ever experienced this issue. However, glancing through a few of the top search results, I didn’t see any solutions to the error.
The problem occurs when you have a custom master page which includes code and that master page subsequently becomes unghosted. I believe this happens with custom page layouts that are customized as well.
I have to admit that I was completely stumped when I first encountered this error a few years ago while working on the Agilent Technologies project. I eventually tracked down the root cause to be unghosted pages, but we were not using SharePoint Designer to create or customize our master pages, so I couldn’t understand why we would occasionally encounter this error.
My speculation is that when the feature/solution containing the custom master page is deactivated, retracted, and deleted (as part of the “DR.DADA” process), SharePoint has some “smarts” within it that essentially equates to:
Hey, this master page (or page layout) is currently in use so removing it could really break the site.
Therefore, I’d better make a copy of it and store it in the database (i.e. unghost it).
Unfortunately, when we subsequently added, deployed, and activated the solution/feature, SharePoint would still attempt to use the unghosted master page and summarily generate the error stating that “the attribute ‘autoeventwireup’ is not allowed in this page.”
Note that this is pure speculation on my part as to what was causing the master page to become unghosted.
However, what I do know for sure is that once I reghosted the master page, the AutoEventWireup error would magically disappear.
Here are the steps to reghost a master page or page layout:
Browse to Site Settings page for your site. Note that if your master page is causing the AutoEventWireup error, you can explicitly specify the URL (e.g. http://fabrikam/_layouts/settings.aspx).
On the Site Settings page, under the Look and Feel section, click Reset to site definition.
On the Reset Page to Site Definition Versionpage:
In the Reset to Site Definition section, ensure the option to he Local URL of the page box,
In the confirmation dialog that appears stating that you will lose all customizations, including web part zones, custom controls, and in-line text, click OK.
Note that in ASP.NET, the default value for the AutoEventWireup attribute is true. Therefore you might assume that you could simply remove the attribute from your custom master page in order to avoid the error when the master page is unghosted. After all, the error clearly states that the AutoEventWireup attribute is not allowed in this page, right?
In other words, the solution to the problem would seem to be simply be a matter of changing something like this…
I attempted to resolve this by converting the BreadcrumbSiteMapPath_OnPreRender event handler to a method and invoking the method from the Page_PreRender event handler instead. However, that only led to yet another error:
Code blocks are not allowed in this file.
Sensing a very deep “rat hole” at this point, I decided it wasn’t worth pursuing this issue any further.
Fortunately, as I’ve stated before, I don’t believe master pages and page layouts deployed through solutions and features should subsequently be customized through SharePoint Designer. In my opinion, these items should be tightly managed through your SCM (software configuration management) process — in other words, versioned in your source control system and subsequently deployed through a formal change process.
Of course, if your custom master pages and page layouts are very simple (i.e. no code-behind) then you probably will never encounter this problem.
I want to show you one of the ways how to quickly establish parent – child relationship in SharePoint. By using this way you will be able to add child items on the parent item view page as shown in the image below:
The idea how to add new child item form is borrowed from OOTB SharePoint Blog application template. By investigating how comments are implemented on Post.aspx page I was able to reuse OOTB SharePoint:SubmitCommentButton control which is used by BlogCommentsForm SharePoint:RenderingTemplate. BlogCommentsForm rendering template is defined in Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATECONTROLTEMPLATESDefaultTemplates.ascx file. So here are quick steps how to achieve this:
First you need a parent and child lists. In my example I have Orders and Oder details lists. In child list you need to create a lookup column to parent list named PostTitle (you must use this name because this is the name of column which is used by OOTB SubmitCommentButton functionality). It is important to choose ID column in the “In this column” combo box. You can hide PostTitle lookup column if you want.
Now using SharePoint Designer 2007 open your site and navigate to the parent list folder. Copy DispForm.aspx and rename the copy CustomDispForm.aspx (you can choose whatever name you want).
In the CustomDispForm.aspx replace ListFormWebPart with DataFormWebPart.
Add new ListFormWebPart for the new child list item form. Choose New item form in List or Document Form dialog.
Add child list Web Part for displaying all child list items.
Set CustomDispForm.aspx to be the parent list default display form.
In the DefaultTemplates.ascx find SharePoint:RenderingTemplate with ID=”BlogCommentsForm”. Select and copy all SharePoint:RenderingTemplate tag.
Create new file SubmitNewProduct.ascx and paste the code you copied in step 7 (you can choose another file name).
Find SharePoint:SubmitCommentButton tag and modify Text attribute to whatever you want (in my example I will use “Add Product”). Save the file in the same directory as DefaultTemplates.ascx.
Using SharePoint Designer 2007 open CustomDispForm.aspx created in step 2. Find ListFormWebPart added in step 4. Change TemplateName tag to a name you named the file in step 8.
Now when you open Order (parent list item) you already can add new child items. But last web part on page still displaying not filtered child items list. All you need to do is Edit the page and modify last web part by setting the following filter: PostTitle is equal to [ID].
In the next post I show how to implement a child item selection from another list. If you noticed in the image above Order details item have a lookup column name Product. By selecting Product automatically are filled child item fields. In others solutions it may be enough to have just a lookup column, but in my case I need to fix product details (name, price and etc.) at the time of Order or Invoice creation because later on product price may change.
Sometimes (very often) we have to be faced with the user requirements of master-detail lists. If you want to implement a very basic one, it’s very simple: lookup fields can have very big strong. For example, you need to store company data with contact people:
Well, how can you store these info pieces in SharePoint lists? – Of course, you’ll simply have two lists: first one for the companies, and the second one for the contact persons. In this second list you have to make a lookup column referring to the Companies list. In this column we’ll store the info where is that person’s working:
That’s great, but in most cases that’s not enough. You can maintain companies and contacts in different spaces, in different lists. The main problems with this are the followings:
You cannot see the related contacts on the Company’s form. For example, I’d like to have a form for Company1 where I can see Thomas, Spencer, Percy, Harvey and Harold.
You cannot maintain the contacts directly from the companies data form. When you view/edit a contact person, you’ll be redirected to the contacts list’s AllItems.aspx instead of the related company’s DispForm.aspx.
So, would you like to know what I’m talking about? The default display form of a company is something similar this:
Instead of that, I’d like to see something like that:
I’m very sorry because of the Hungarian UI, but to be honestly this example is from my company’s Intranet site. Most probably you’re interested in a few words, so let’s start your first Hungarian lesson:
Ügyfél = customer
Kapcsolattartó = contact person
Bezárás = close
That’s it, I hope you understand everything else 🙂
Well, making a form like that is very simple, you just have to create a Data View webpart with SharePoint Designer. The source list of this Data View is the contacts list, filtered by the current company: create a custom company DispForm webpart based on the URL’s ID parameter, and you can connect this webpart to the Data Views. You need this trick just because the URL contains the company’s ID, but in the Data Views you need the name of that.
In the Data Views, all of the the items’ link redirect you to the selected contact person’s DispForm / EditForm – and very similar, the New Contact (“Új kapcsolattartó”) link placed in the footer of the webpart redirects you to the contacts list’s NewForm.aspx.
That’s well and good, but how are we redirected to the company’s page from these forms? – This step requires two little tricks. First of all, we have to tell the forms where to come back. It’s pretty easy, just place a parameter in the URL. For example, the New Contact (“Új kapcsolattartó”) link is something like this:
where CustomerID is the ID of the current company, and you can read this from the URL as a QueryString parameter:
OK, we’re ready on the companies’ side, let’s jump to the contacts list. Here we should update all forms (DispForm.aspx, EditForm.aspx, NewForm.aspx) and learn them to redirect us to the related company’s DispForm instead of Lists/Contacts/AllItems.aspx. As the logic of this modification is similar on all these forms, let’s only see the NewForm.
First of all, what you have to do to change the default redirecting of Save and Cancel buttons is to replace the default NewForm webpart to a custom one. Changing the redirecting to a static URL is very simple, but in this case we need a dynamic URL in the redirection, because of the CustomerID parameter. Let’s dig into it and see the way of dynamic redirecting step-by-step:
Read the CustomerID parameter from the URL (see above).
Place the following snippet to the beginning of the Data View webpart’s code. With it you can build the redirect URL (RedirectLoc) in a dynamic way: