Recently I ran into the following issue when I tried to deploy a SharePoint 2010 Project in Visual Studio 2010 Beta 2. In the output window the following message was displayed and the deployment failed:

Error occurred in deployment step ‘Retract Solution’: The local SharePoint server is not accessible. Check that the server is running and connected to the SharePoint farm.

It turned out (thank you Event Viewer!) that the account that triggers the Deploy action in Visual Studio 2010 (typically the account you used to login in Windows) needs to have permissions in both the Configuration database and the Content database.

Finally the public betas of SharePoint 2010 (both SharePoint Foundation and SharePoint Server), Office 2010, SharePoint Designer 2010 and Visio 2010 are available on MSDN Subscriptions, so start your download engines right now! :-)

If you don't see the download, you can use this direct link (make sure you are signed in to the Download Center before you click the link).

During the last couple of weeks, we at U2U have been very busy building course material for our upcoming SharePoint 2010 courses. We expect that lots of experienced SharePoint developers, power users and administrators are very eager to get up to speed with the new version of SharePoint as soon as possible. That’s why the first course that we’ve build is titled Upgrade to SharePoint 2010. This course will focus on all the exciting new stuff in SharePoint 2010, so people with SharePoint experience will get all the relevant info as quickly as possible. Because an administrator is probably not interested in developer stuff, we’ve chosen to split the course into three different parts:

  • Part 1: Tools and Technologies (2 days)
    The focus of the first part of this course is on everything what’s new in SharePoint 2010 from a power user perspective. That means: everything you can configure in SharePoint 2010 without writing custom code. We’ll start with an overview of the new SharePoint 2010 platform, after that all the important new features will be discussed separately. Although this part will not involve building code customizations, it’s important for technical people (developers, architects, IT-Pro’s …) as well to know about these important new and enhanced features.
    Part 2: The Development Platform (2 days)
    SharePoint 2007 already was a very extensible platform: as a developer you could enhance and extend the out-of-the-box functionality using some powerful techniques. Unfortunately developing for SharePoint 2007 often required to developer to spend lots of time writing XML, using command line utilities,… This part of the course will focus on the new development tools in Visual Studio 2010 which will make the life of SharePoint developers a lot easier, and the new developer opportunities in SharePoint 2010.
  • Part 3: Administration and Configuration (1 day)
    Also for IT-Pro’s and System Administrators SharePoint 2010 has lots of new functionality. In this final part of the course, we’ll focus on how SharePoint 2010 can make the life of administrators significant easier. 

If you are a developer or architect I’d recommend you to follow all three parts of the course (yes even the administration and configuration part). If you are a power user, end user, manager or business decision maker (thus not a very technical person), I’d recommend you to attend the first part of our course. Finally if you are an IT-Pro or system administration, part 1 and 3 are relevant for you. You can read the full course description at the U2U site, and check out the schedule (the course is already scheduled in Brussels, Belgium in December and January, but we can deliver on-site courses as well).

In the near future U2U will expand its SharePoint 2010 training offerings to facilitate the needs of everybody who wants to get in the SharePoint 2010 game, even if you don’t have experience with the previous versions of SharePoint. So make sure you visit the U2U site once in a while to see if there is anything new. Alternatively you can subscribe to our newsletter over there, or you can follow us on Twitter as well (@u2u) or visit our Facebook page (and become a fan!).

People that are attending TechEd Europe in Berlin next week, make sure to visit the U2U booth to check out our new course material, and to receive a free SharePoint 2010 t-shirt (just mention that Jan sent you :-) ). If you have any questions and I’m not at the booth, feel free to ask for me. Or you can attend my BoF Session about SharePoint, Silverlight and jQuery on Thursday.

I’ve got the pleasure to be able to present a Birds-of-a-Feather (BoF) session at TechEd Europe next week: BOF14 Microsoft SharePoint, jQuery and Microsoft Silverlight: Better Together. If you are interested in these technologies please join the discussion on Thursday, 12:20 in Theater 6 – Pink.

Feel free to comment if you are planning to attend, it’s nice to know who’ll be there! :-)

In 20 minutes a very important event is going to get started: the SharePoint Conference 2009! If you're not in Vegas (like me), get yourself in front of a computer with a big bag of chips, popcorn or whatever snack you prefer, and watch the keynote (featuring Steve Ballmer) live! I'm sure it will be a nice show and expect an avalanche of SharePoint 2010 information to be released shortly afterwards. Also make sure you keep an eye on Twitter, blogs, Facebook etc. to see the reactions of SharePoint fans all over the world. My buddies at EndUserSharePoint are going to cover the conference with lots of real time content, so these pages will be open on my pc as well. Have fun!

Summary: The SmartTools jQueryLoader enables the jQuery Javascript library in your SharePoint sites using an effortless and Assembly-Free deployment technique. Additionally the jQueryLoader will dynamically load custom Javascript files, deployed to a Document Library. Seeing is believing: watch this short screencast that shows the deployment and some sample scripts!

If you read my blog you probably know that using the jQuery Javascript library in SharePoint 2007 sites can enhance and extend the out-of-the-box user interface significantly. But up to now it was time consuming and a tedious job to enable jQuery in SharePoint sites, for example: adding a Content Editor Web Part to the page, open the properties, copy/paste a script using the Source dialog etc. Even worse: these steps needed to be done on every page where the desired jQuery functionality should become active.

These issues can be solved by using the new SmartTools jQueryLoader that I’m releasing today! The SmartTools jQueryloader basically is a Javascript file that dynamically loads additional custom Javascript files stored in a predefined Document Library. This Document Library has extra columns to specify when and in what order those Javascript files should be loaded. So making available a new js file (containing your next amazing extension) in your SharePoint sites will be as easy as uploading that file to the Document Library. The jQueryLoader will take care of loading your script accordingly.

 

The jQueryLoader script itself, and the jQuery library as well, need to be loaded of course in every page in your SharePoint sites. This is accomplished by making a small change to the Master Page that’s in use in your SharePoint sites. All these configuration steps, including the creation of the Document Library, changing the Master Page, adding the jQueryLoader etc, are executed with an automated installation page. The really cool thing about this installation page is that it’s a basic SharePoint Site Page that doesn’t contain any server side code; everything is accomplished using Javascript. That means that to make use of the jQueryLoader (and its installer), there is nothing that needs to be changed, configured or deployed on your servers! That’s what is called Assembly-Free by the way.

 

Here is an overview of the installation steps:

  1. Navigate to any Document Library in a SharePoint site.
  2. Upload the SmartToosls.jQueryLoader.Install.aspx file to that Document Library (this file can be deleted after the installation).
  3. Open the uploaded page by just clicking on it.
  4. Select the desired installation options by checking their checkboxes in the list. For a first-time installation you typically check at least the first four checkboxes (see below).
  5. Click the Start Installation button and keep an eye on the Installation Log at the bottom of the page.
  6. That’s it!
The different installation options which can be selected are:
  • Create js Document Library: will create a hidden Document Library called js. This Document Library will have four custom columns:
    • Autoload (true/false): to specify if the jQueryLoader should dynamically load the file
    • Sequence (number): to specify the order in which the files are loaded
    • ApplyTo (text): a regular expression to specify on which pages the file should be loaded
    • Group (text): an optional value to group different files together
  • Create or update jquery.js: will upload the jQuery library to the js Document Library. 
  • Create or update smarttools.jqueryloader.js: will upload the jQueryLoader script to the js Document Library.
  • Update the default.master: will make a change to the default.master Master Page (or the one you select by changing the value in the textbox). This change adds three script tags in the head element of the HTML page.
  • Update the default.master of a child site: (optional) will make a change to the Master Page of a child site (see previous option). Notice that this child site will make use of js Document Library of the current site.
  • Add test Web Part (optional): will add a test Web Part to the default.aspx (Home) page of the site to verify if jQuery is active.
  • Enhanced Tasks View, Task Notifications and AJAX Lists (all optional): will add various sample scripts to show of the power of jQuery in SharePoint see the demo screencast for more information.

The optional sample scripts are just there to give you an idea what can be accomplished using jQuery in SharePoint sites, and to show you how easy it is to deploy them. The real added value is of course your creativity to build custom scripts making SharePoint even better. Feel free to contact me when you’ve got a cool sample as well!

 

When I was installing a brand new demo environment using Microsoft's latest and greatest platforms (Windows Server 2008 R2 and SQL Server 2008) I ran into an annoying issue related to SharePoint. The slipstreamed installation (including SP2) went fine, but when I tried to create a new Collaboration Portal or Publishing Portal I got the error: "The Office SharePoint Server Standard Web application features feature must be activated at the web application level before this feature can be activated.".

After some searching I learned that MOSS SP2 was not correctly applied, re-installing MOSS SP2 solved the issue. Apparently this is a known issue which can be avoided by adding the Web Server Role before running the slipstreamed SharePoint installation.

Related posts:

In my previous post I introduced a small script to extend the Edit Control Block (ECB) of list items and documents. The added menu items in the ECB allow users to update certain metadata fields for that item or document. The cool thing is that everything is happening in the background with the help of jQuery, even the actual updating of the data. The result: no postbacks or full page loads, pure AJAX goodness just like showcased in the SharePoint 2010 sneak peek videos. Today I’m releasing a new and improved version of the script, based on your feedback. Here are the changes:

Column names can have a display name and an internal name

In the previous version of the script you’d had to specify the names of the columns you’d like to ajaxify based on the internal name (which escapes spaces etc). In the new version of the script you can specify the display name as well. For example this is a possible configuration for a Task list:

columns: ["Status", "Priority", "% Complete#PercentComplete", "Description#Body"]

For the Status and Priority columns, no internal names are specified since they are the same as the display names. But notice that the next two columns have a # sign in them. The part preceding the # sign is the display name, the part after the # sign is the internal name from SharePoint.

Column values can have a display name and an internal name.

This works exactly as the column names, so if there is a # sign, the first part will be the display value, the second part will be the internal value. For example this is the array of values for the % Complete column of a task list:

["100%#1.00000000000000", "75%#0.750000000000000", "50%#0.500000000000000", "25%#0.250000000000000", "0%#0"]

Internally percentages are stored as values between 0 and 1. But we’d like show them as real percentages to the user of course: e.g. 100% will be displayed, while 1.00000000000 will be stored in SharePoint.

Multiple lists and document libraries can be configured in the same script.

Now you can also use the script if there is more than one list view web part on a page: in the lists option of the ajaxListConfig variable, multiple lists can be defined based on their name.

var ajaxListConfig = {
    lists:
        [
            {   name: "Tasks",
                columns: [ ... ],
                values: [ ... ] },
            {   name: "Issues",
                columns: [ ... ],
                values: [ ... ] },
        ],
    debug: 0, // set to 1 to see log messages
    animationSpeed: "fast" // possible values: "slow", "normal", "fast" or a number (milliseconds)
};

User entered values are now supported.

In the previous version, the user could only use the predefined values for a column (which makes lots of sense for Choice columns). In the new version, if the values option of a list configuration is equal to null (instead of an array of values), dialog is displayed in which the user can fill out a new value. For example in the Task list below, the Update Description menu item is displayed, but there is submenu to display the possible values.

 

When the user clicks on the Update Description menu item, a dialog is displayed to allow the user to modify the value. Once again there are no postbacks. To display the dialog I’m using the Imprompty jQuery extension (included in my script). Notice that there is no Rich Text editing (yet), so HTML tags will be stripped out. Also there is no support for editing Person fields etc.

 

Finally ...

... some small bug fixes and performance enhancements are done. To use the script, configure it to your needs (when you download it, it’s configured for a default Task and Issue list), then follow these steps:

  1. Navigate to the page where you would like to use it (e.g. http://yoursite//Lists/Tasks/AllItems.aspx for the Task list).
  2. Click Site Actions, Edit Page (top right).
  3. Click Add a Web Part.
  4. Select the Content Editor Web Part in the Miscellaneous section and click Add.
  5. Optionally drag the Content Editor Web Part to the bottom of the screen (otherwise a small space will be displayed on top of the page).
  6. Click open the tool pane in the web part.
  7. Click Source Editor ... in the properties task pane.
  8. Copy and paste the modified script in the Text Entry dialog and click Save.
  9. Click Exit Edit Mode (top right) and verify the result.
You can download the script over here. Let me know if you have any issues and/or any feature requests!

[This script has been updated over here] I'm pretty sure every SharePoint enthusiast has seen those great Sneak Peek videos Microsoft released some time ago. And I'm sure that lots of the new features shown were very exciting for lots of you. Since SharePoint 2010 is still quite far away in the future, let's try to bring some of the 2010 stuff to SharePoint 2007! In the overview video, Tom Rizzo showed some new user interface functionality, pretty much all of it was heavily using asynchronous Javascript code to dynamically do updates, change layouts etc. All of this of course to prevent those nasty full page reloads. One of the features that caught my eye was the inline editing of list items or documents: without reloading the page, or opening a new page, it's possible in SharePoint 2010 to edit meta data. Pretty cool! And I want to have it in my SharePoint sites, today.

In my previous post I showed how you can add extra functionality to the Edit Control Block (ECB), let's take that technique and make it more flexible and customizable. Here is the result I'm looking for:

 

Notice that everything you see is happening completely at the client side, without any code deployed to the server, without any full page postbacks. So how do you get this working in your SharePoint sites? Just download this script file [This script has been updated over here] and open it. On top of the script you'll find the ajaxListConfig variable which you can change to customize the script:

var ajaxListConfig = {
    columns         :new Array("Status", "Priority"), // columns to ajaxify
    values          :new Array(
                        new Array("Not Started", "In Progress", "Completed",
    "Deferred", "Waiting on someone else"), // values for Status
                        new Array("(1) High", "(2) Normal", "(3) Low") // values for Priority
                        ),
    debug           :0, // set to 1 to see log messages
    animationSpeed  :"slow" // possible values: "slow", "normal", "fast" or a number (milliseconds)
};

When you download the script, it's configured for a default Task list. If you want to enable it on other list types or Document Libraries, or you're running SharePoint in another language than English the following options need to be changed:

  • columns: in the array you need to type the names of the columns you want to ajax-enable
  • values: for every column defined in the columns option, you need to provide an array of values

Optionally you can set the debug option to 1, so a log window is being displayed in case something goes wrong. The animationSpeed option allows you to set the speed of the fancy fade in and out effects for the updated values. When all options are set, follow these steps:

  1. Navigate to the page where you would like to use it (e.g. http://yoursite//Lists/Tasks/AllItems.aspx for the Task list).
  2. Click Site Actions, Edit Page (top right).
  3. Click Add a Web Part.
  4. Select the Content Editor Web Part in the Miscellaneous section and click Add.
  5. Optionally drag the Content Editor Web Part to the bottom of the screen (otherwise a small space will be displayed on top of the page).
  6. Click open the tool pane in the web part.
  7. Click Source Editor ... in the properties task pane.
  8. Copy and paste the modified script in the Text Entry dialog and click Save.
  9. Click Exit Edit Mode (top right) and verify the result.

Remember when the script doesn't work as expected, set the debug option to 1 and you'll see the log messages appearing at the bottom right of the screen. Btw, thanks my Twitter buddies who tested the script! (feel free to follow @jantielens).

[This script has been updated over here]

Other articles in this series:

In the previous articles I explained the basic technique to add custom menu items to the Edit Control Block (ECB) using Javascript. Basically it comes down to writing a Javascript function called Custom_AddListMenuItems or Custom_AddDocLibMenuItems (respectively for adding menu items to the ECB of Lists and Document Libraries). In these custom functions you can use the CAMOpt Javascript function (found in the default core.js file) to add as many items as you want. Using the CASubM function you can also build hierarchical menus.

The next thing that I would like to discuss is how to create "context sensitive menu items" in the ECB using these techniques. What do I mean with "context sensitive"? Let’s take a look at the out-of-the-box ECB of a Document Library. In that ECB a menu item is displayed to Check Out a document. But this menu item is only displayed when the document is not yet checked out. When the document is checked out, the ECB displays the Check In and Discard Check Out menu items instead. So based on the metadata of the document, the ECB is different in this scenario.

     

To illustrate how you can build context sensitive ECB menu items yourself, let’s take the following example: we’ll enhance the ECB of a default Task list so it shows menu items to quickly mark a task as Completed, In Progress etc. In the following screenshot the ECB for Test Task 1 is displayed. The Status of that task is set to Not Started, so the Update Status menu item only displays In Progress, Complete, Deferred and Waiting child menu items.

 

In the same task list, there is also a Test Task 2 item for which the status is set to In Progress. The Update Status menu item in the ECB now displays Not Started, Complete, Deferred and Waiting.

 

Since the customized ECB is configured in a Javascript function (Custom_AddListMenuItems in this case), we need to be able to retrieve the Status value of the item for which the ECB is currently being rendered. The core.js and init.js out-of-the-box Javascript files, give us little meta data information: only the item ID, checked out status etc are available. In this case technically it is possible to retrieve the Status value of the list item by querying the HTML DOM. Although this technique would work, it would only work if the needed meta data is actually displayed. E.g. if the Status column would not be displayed in the view, the information could not be retrieved. Therefore I’m using another technique that retrieves the necessary meta data information by making a call to the lists.asmx web service. This web service has a web method called GetListItems that can retrieve all meta data for one or more list items (as described in an earlier post). Once we have the meta data, the rendering of the ECB menu items is easy:

function Custom_AddListMenuItems(m, ctx) {
    var soapEnv =
        "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'> \
            <soapenv:Body> \
                 <GetListItems xmlns='http://schemas.microsoft.com/sharepoint/soap/'> \
                    <listName>" + ctx.listName + "</listName> \
                    <viewFields> \
                        <ViewFields> \
                           <FieldRef Name='Status' /> \
                       </ViewFields> \
                    </viewFields> \
                    <query> \
                        <Query><Where> \
                            <Eq> \
                                <FieldRef Name='ID' /> \
                                <Value Type='Integer'>" + currentItemID + "</Value> \
                            </Eq> \
                        </Where></Query>\
                    </query> \
                </GetListItems> \
            </soapenv:Body> \
        </soapenv:Envelope>";

    var wsurl = ctx.HttpRoot + "/_vti_bin/lists.asmx";
    
    $.ajax({
        async: false,
        url: wsurl,
        type: "POST",
        dataType: "xml",
        data: soapEnv,
        complete: function(xData, status) {
            var status = $(xData.responseXML).find("z\\:row:eq(0)").attr("ows_Status");
            
            var menuItem = CASubM(m,"Update Status");

            var statusOptions = new Array("Not Started", "In Progress",
                    "Completed", "Deferred", "Waiting on someone else");

            for(var i in statusOptions) {
                var statusOption = statusOptions[i];
                if(statusOption  != status)
                    CAMOpt(menuItem, statusOption ,
                    "changeTaskStatus('" + wsurl + "','" + ctx.listName + "','" +
                    currentItemID + "','" + statusOption + "');");
            }
        },
        contentType: "text/xml; charset=\"utf-8\""
    });
    
    CAMSep(m);
    return false;
}

First the SOAP Envelope to send to the GetListItems web method is constructed (soapEnv variable); it uses the listName property of the ctx object (defined by SharePoint in the init.js), and the currentItemID (defined by SharePoint in the core.js). The jQuery ajax method is used to make a the web service call. When the data is retrieved (the complete option of the ajax method) the current Status value is extracted and stored in the status variable. Next a new menu item is added to the ECB using the CASubM function (since this menu item will contain child items). Finally there is a loop over all possible Status values (stored in the statusOptions array); every possible Status is added as a sub menu, except the Status that is currently assigned to the task item. Notice that the third parameter of the CAMOpt function is a Javascript call to the changeTaskStatus function, passing the web service URL, the list ID, the item ID and the selected status as parameters.

The changeTaskStatus function is pretty straight forward: once again a web service call is made, this time to the UpdateListItems web method of the lists.asmx web service. The SOAP Envelope sent to this web method contains a Batch element in which an update is described of the Task list item.

function changeTaskStatus(wsurl, list, itemid, newstatus) {
    var batch =
        "<Batch OnError=\"Continue\"> \
            <Method ID=\"1\" Cmd=\"Update\"> \
                <Field Name=\"ID\">" + itemid + "</Field> \
                <Field Name=\"Status\">" + newstatus + "</Field> \
            </Method> \
        </Batch>";

    var soapEnv =
        "<?xml version=\"1.0\" encoding=\"utf-8\"?> \
        <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" \
            xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" \
            xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \
          <soap:Body> \
            <UpdateListItems xmlns=\"http://schemas.microsoft.com/sharepoint/soap/\"> \
              <listName>" + list + "</listName> \
              <updates> \
                " + batch + "</updates> \
            </UpdateListItems> \
          </soap:Body> \
        </soap:Envelope>";

    $.ajax({
        url: wsurl,
        beforeSend: function(xhr) {
            xhr.setRequestHeader("SOAPAction",
            "http://schemas.microsoft.com/sharepoint/soap/UpdateListItems");
        },
        type: "POST",
        dataType: "xml",
        data: soapEnv,
        complete: function(xData, result) {
            window.location.href=window.location.href;
        },
        contentType: "text/xml; charset=utf-8"
    });    
}

When the web service call is done (the complete option of the ajax method) the page is refreshed by setting the href of the window.location property to it’s current value. As a result the page will display the updated value of the Status.

Although this is pretty cool, it’s a pity of course that everything is happening using client side Javascript; except updating the value of the Status column in the HTML page (which done with a full page refresh). Let’s try to fix this! To get to the location in the HTML DOM where the Status of the Task item is displayed is quite complex due to how SharePoint generates the HTML for a List view. The getItemTD function below will get a reference to the TD element for a specific Task item. First of all this method selects a table element with the ID set to the combination of the list ID and view ID. Notice that this table ID needs to be escaped for jQuery to make the selection. Next the TR element (row) is selected for the Task item, based on the ID of a table nested on the TR which is the same as the item ID. After that the header row is selected so the index of the Status column can be calculated. Using this index the correct TD element (table cell) is selected and returned.

function getItemTD(itemid) {
    var tableid = ctx.listName + "-" + ctx.view;
    
    // escape the table id ({ and } should become \{ and \}
    tableid = tableid.replace(/{/g, "\\{").replace(/}/g, "\\}");

    // select them TR for the item
    $itemrow = $("#" + tableid + " table[id='" + itemid + "']").parent().parent();
    
    // select the header row
    $headerrow = $(">tr:eq(0)", $itemrow.parent());

    // select the table in the header row for the specified column
    $idtable = $("th>div>table[Name='Status']", $headerrow);
    
    // calculate the index of the column, based on the idtable
    var columnIndex =$(">th",$headerrow).index($idtable.parent().parent());
    
    // based on the index, let's get the TD
    return $(">td:eq(" + columnIndex + ")", $itemrow);
}

To make us of this function the complete option of the ajax function, used in the changeTaskStatus function, has to be changed:

...
complete: function(xData, result) {
    getItemTD(itemid).text(newstatus);
},
...

The getItemTD function is used to select the table cell which should be updated with the new value. The result is that now the Status of a Task item can be updated, both in the SharePoint database and the web UI, without full page postbacks!

You can download the full source code of this sample over here. To use it, navigate to a default Task list (e.g. http://yoursite/Lists/Tasks/AllItems.aspx) and add a Content Editor Web Part to the page. Open the Tool Pane of the Content Editor Web Part and paste the downloaded script in the Source property of the web part (detailed instructions to add the web part can be found over here). Notice that on top of the script a reference is made to the jQuery library hosted by Google. Once again, if you host the jQuery library yourself (e.g. in a Document Library), feel free to update the URL.

 

More Posts Next page »