Adding print functionality to Data View Web Parts

Hi,
A question I got from a customer today was “How can I add a print button to data view web part which will print all documents in the view?”

Well, we have a product called iMUSH Print that allows you to print selected items/document from out of the box list views, and merge them into one PDF file for easy printing.

But the question remains, how do one connects this print functionality to a data view web part?

Well, lists or libraries, the answer is simple and took me about an hour to create a working POC.
First, lets have a look at out of the box iMUSH print feature in standard library view:

One thing to note, is that you can either use the checkboxes to select items for printing or click the print menu and select what you wish to print in the popup:

Ok, so obviously, this popup “knows” how to get a list of items for print. We will use this parameter to send the items form the DVWP.
Now, to the DVWP in SharePoint Designer:
2 changes are needed in the DVWP,

1. Add a print button HTML just before the <table> tag of the DVWP items:

<img alt="print" src="/_layouts/KWizCom_iMushFeature/ico_imush_print_16px.png"

onclick="KWizCom_DoDVWPPrint('/iMUSH/_layouts/KWizCom_iMushFeature/KWizComPrintList.aspx',

'567836FC-F9B1-4D48-80AC-D637772703D4', '', this.nextSibling);"/>

you will need to replace the url “/iMUSH/” with your real site URL, and the list id ‘5678…’ with your actual list/library GUID.

2. Locate the <tr> tag inside your DVWP items table, and add an “itemid” attribute to it:

<tr itemid="{@ID}">

That’s it for the DVWP.

Next you will have to add some javascript code to your page, anywhere in the page.
My favourite way about it is just adding a content editor web part.
Just insert this JS code:

<script>

function KWizCom_DoDVWPPrint(pageUrl, listId, viewId, dvwpTable)

{

var url = pageUrl + "?ListId=" + listId + "&View=" + viewId + "&ItemId=";

    //get items from dvwp

var items = "";

    for(var i = 0; i < dvwpTable.rows.length; i++)

  if(dvwpTable.rows[i].itemid != undefined)

        {

    if( items != "" ) items += ",";

            items += dvwpTable.rows[i].itemid;

  }

    url += items;

commonShowModalDialog(url,

'dialogHeight:300px;dialogWidth:180px;scroll:true;toolbar:no;status:no;resizable:yes;',

null, null);

}

</script>

and you are done!

Now, you can click print on the DVWP to print all items that are displayed in the web part, even after filtering but the user:




That’s it!

Just remember, this functionality requires a license for iMUSH Print.

Using jQuery in SharePoint 2010? Here is something you didnt expect!

If you are planning or using jQuery JS library in SharePoint 2010, there is one thing you didn't plan - for sure.
The $ sign from jQuery library is conflicted with the $ sign used in SharePoint JS - only in picture library "thumbnails" view.
Meaning, your code will not work if it has a picture library thumbnail view web part.
A wrong solution would be to append your JS to the end of the page - do this and your code will work, but the thumbnail view will stop working!
The solution for this is rather simple and annoying,
All you have to do is rename the $ sign into something else, like myJQ.
To do this - add this simple line of code at the end of your jQuery JS file:
var $jq = jQuery.noConflict();
and use $jq instead of $.
Note: you should use your own unique key instead of $jq.

Encode in JS Decode in C# problem

Just a quick one guys,

Recently we had a customer who complained about French tags that are not working with our tagging feature (field type, tag cloud for SP 2007 - pretty cool actually).

Well, apperantly we were doing some encoding of text in javascript using "escape()" and trying to decode it in C# on the server side using UrlDecode with no luck.

the text: "de l'entité" was not decoding correctly.

After trying to figure our whats wrong on the server side decoding function (I tried several alternatives) I almost gave up with no success whatsoever :(

So, I turned to look for alternatives in the Javascript encoding and found this new method called "encodeURI()". Apperantly this method can safely replace our "escape/unescape" in Javascript only it supports proper encoding and decoding with C# with no problems.

Works like a charm - from now on, use "encodeURI/decodeURI"!

Cheers, Shai.

Using LINQ and REST in SharePoint 2010

Among the new APIs available for SharePoint 2010 developers the 2 new most significant ones are LINQ and REST.

While developing server side code, you can now make use of LINQ to query your lists instead of using CAML.
The benefit of using LINQ is clear, working with strong typed objects and cutting down the development effort by a lot.
The problem comes when you are not sure what type of lists you are going to work on, and if you wish to support custom lists created by customers.
Before you can use LINQ on SharePoint you need to create an object that represent that list structure, and once the list changes (the fields you are querying are removed to renamed) you will not be able to use it anymore :(

But - remember, working on the server site with the SPList object is dengerous as well, as all you get are item[field_name] resutls, which is not strongly types and requies many validations to be done!

While working on the client side, you will be able to work using the client side object model (much like the server side, using Site/Web/List instead of SPSite/SPWeb/SPList we have on the server) but still that will not be strongly typed for you.
The news are that you will be able to use LINQ in the client side, that will allow you to automatically render the correct proxy objects in the client side (accessible from javascript / silverlight) and will be strongly typed!

So, by all means - start learning SharePoint REST syntax and commands...
here are some available commands to get you started:
$filter=
$expand=
$orderby={property}
$skip=n
$top=n
$metadata – bring all metadata of that object

These commands are accessible under the REST service URL which includes (sometimes) the entity name you wish to run against, like so:
http://site/subsite/_vti_bin/ListData.svc/{Entity Name}/{Options...}

This service URL can be registerd to the client using the standard ASP.NET AJAX way for registring services, and everything is made simple after that!

(If you need more info on ASP.NET AJAX you should definitly check these how-to's by Joe Stagner here: http://www.asp.net/learn/ajax-videos/ and specifically on registring services here: http://www.asp.net/learn/ajax-videos/video-82.aspx)

Well, are you excited as I am to move onto SharePoint 2010 yet? :)

Client API in SharePoint 2010

This is what I picked up in todays great session on client code;

Basically, Microsoft.SharePoint.Client is a wrapper that you can use at the client side (silverlight or javascript) to add get and update information.
Migration of code will require start using the Client API objects instead of the current API we all know in the server, but most objects are similar to help us update our code easily.
So - SPWeb will be web, SPList will be list etc...
Event SPContext exists as ClientContext!
the only difference is, that you run all your code on the clientContext object in the client side, and once you have a set of operations you wish to submit to the server you can do that by calling "clientcontext.ExecuteQuery()" or "clientcontext.ExecuteQueryAsync()" if you want the UI not to wait for the result.
If you wish to retrieve data form server to your client you can use the “Load” or “LoadQuery” methods. LoadQuery will return a result collection and will use method syntax or linq query syntax. It will build you XML query and will send them to the server next time you call “ExecuteQuery”.
Using the "Execute" or "Load" methods actually help reduce the number of trips done from the client to the server to reduce server load, bandwidth and improve responsiveness.
Nothing new, except you don't have to build your own wrapper and web services if you want to run some code on your SharePoint from the client. Basically this will communicate with client by dropping JSON code from the server to the client, the client will use the JSON to work with and send queries to the server in XML format.
I guess this will help us do less post back, as this will not be supported in wiki pages (no post back support).
A new cool thing is the SP.CamlQuery.CreateAllItemsQuery() method that renders a CAML that returns all items for a list. This will surly get you started with CAML query – the last stand of CAML in 2010 since views and forms are now defined by XSL.

More news from the SPC2009 will follow!