Gritter and Sharepoint: integrate nifty notifications in your intranet!

I’m working with a client on building up a project management tool in Sharepoint; one thing that’s really piqued their interest is the concept of getting short flashes of information when their staff logs into the landing page. I think it’s a lovely idea, and I’m intend on giving them this functionality – but how, you might ask? There doesn’t seem to be any Sharepoint feature for doing that!

We tend to forget that Sharepoint is, above all, a web-based solution. This means that, with a little ingenuity (and sometimes a lot of sweat and blood), you can integrate some of the latest, coolest web features into your existing Sharepoint. Fortunately, notifications are not too complicated. In this short article, we’re going to walk through creating very cool notifications using Gritter, a jQuery-based “plugin”, with Sharepoint.

Step One: Create a Sandbox

This may be as simple as creating a new page in your Site Pages repository. I seriously recommend implementing a proof-of-concept rather than work on your production page… If you’re not familiar with these libraries, the last place you want to test things out is on your production work, as easy as these implementations may seem.

Apart from your page, your sandbox will need a few extra files. These you can either place in the Site Assets repository of your PoC portal, or in the Site Assets repo of your root. The latter has the benefit of being accessible to your entire audience (or at least I assume so, it will depend on your permissions). The files that you need are the latest minified version of jQuery, the latest version of Gritter, and the latest version of SPServices (double-check these pages for compatibility issues, of course – if Gritter or SPServices tell you that they won’t work with certain versions of jQuery, don’t use those versions…)

When downloading Gritter, you’ll notice that it is a zip file that has several folders and files. I recommend that you keep those in one single place in your Site Assets. I find it’s easiest to use Sharepoint Designer to do that.

Step Two: Add Your jQuery References

Now that you have a sandbox, you can start working with it. In case you’re wondering, this section is assuming that you’re working with Sharepoint Designer to do your work.

Open your sandbox page in SPD, editing it in Advanced Mode. Locate the PlaceHolderMain placeholder and add the references to your script files:

<!– Inserted by Rick – references to jQuery scripts –>

<!– These are the references to jQuery and SPServices. –>

<script type=”text/javascript” src=”../SiteAssets/jquery-1.8.3.min.js”></script>

<script type=”text/javascript” src=”../SiteAssets/jquery.SPServices-0.7.2.min.js”></script>

<!– These are the references to Gritter: –>

<link rel=”stylesheet” type=”text/css” href=”../SiteAssets/gritter/css/jquery.gritter.css” />

<script type=”text/javascript” src=”../SiteAssets/gritter/js/jquery.gritter.min.js”></script>

<!– End Rick insertions. –>

You can test that the libraries loaded correctly by firing up Chrome, navigating to your PoC page, and opening your Console (F12). In the Console, type the following:

$
$(document).SPServices
$.gritter

If either of these return ‘undefined’, review your references, make sure the files are uploaded in the correct location.

Step Three: Setting up your notifications!

OK, now we know that all the necessary libraries are loaded. Time to develop notifications.

Always develop incrementally, testing your code one chunk at a time. To that effect, here’s code that you should insert after the above script blocks:

<!– Here’s a test notification –>

<script type=”text/javascript”>

$(document).ready( function() {

$.gritter.add({

title: ‘This is a test notification’,

text: ‘This will fade after some time’

});

});

</script>

If that works, you know that Gritter is functional for static content! Now it’s time to pull the real notifications from a list — this is where SPServices comes in. Before we proceed, we need something to pull information from: create a custom list with a single title for your PoC, “Latest Activities” for instance. Then, you will call the GetListItems function using SPServices.

The following code replaces your test notification:

<!– Code for notifications –>

<script type=”text/javascript”>

//This function throws up the notification:

function notify(curTitle, curContent) {

$.gritter.add({

title: curTitle,

text: curContent

});

}

//This retrieves the latest item of your Latest Activities.

function getLastActivity() {

$(document).SPServices({

operation: “GetListItems”,

async: false,

listName: “Latest Activities”,

CAMLRowLimit: 1,

CAMLQuery: “<Query><OrderBy><FieldRef Name=’Created’ Ascending=’False’ /></OrderBy></Query>”,

CAMLViewFields: “<ViewFields><FieldRef Name=’Title’ /></ViewFields>”,

completefunc: function(xData, Status) {

$(xData.responseXML).SPFilterNode(“z:row”).each(function() {

notify(‘For your information…’, $(this).attr(“ows_Title”));

});

}

});

}

//On document load, throw up the notification:

$(document).ready( function() {

getLastActivity();

});

</script>

Et voilĂ  — Gritter and Sharepoint notifications in a nutshell! Your page will load and, once loaded, will call the getLastActivity function. getLastActivity pulls the latest item from the Latest Activities list (we use the CAMLQuery parameter to order by create date, and the CAMLRowLimit parameter to only return one parameter), and use a callback function to call the notify() function. The notify function is what is responsible for rendering the Gritter notification.

Happy notifying!

Rick.

Truncating your SQL 2008 Database with a few lines of SQL…

Here’s a scenario you may be familiar with: you’ve got yourself a nice Sharepoint setup that you’ve gotten to run rather nicely. Conscientious admin that you are, you’ve set up a good, solid maintenance plan that checks your database health, backs up your database and transaction log… But all of a sudden, your backup drive fills up. Since everything has been hunky dory you only realize this during your next server check and by then, the transaction log’s grown to monstrous proportions! You clear up your backup drive and free up space, but you realize to your horror that your transaction log isn’t shrinking… Oh no!

If all of this is hitting home, you’ve probably already realized that the nifty little commands that used to work in SQL Server 2005 aren’t working on SQL Server 2008. So did I. Here’s my new trick for truncating your SQL 2008 database, hope it helps. I would highly recommend you read the whole article thoroughly before proceeding, it has information that you need to know before you do what you’re about to do.

Open up SQL Management studio, then open a query window to the database. For simplicity’s sake, I’ll assume your DB is called WSS_Content but if you’ve got multiple Content Databases / Site Collections (as well you should), the same applies with a different database name / log file name.

First, run this:

alter database WSS_Content set recovery simple with NO_WAIT
go
checkpoint
go
dbcc shinkfile(WSS_Content, 1)
go
alter database WSS_Content set recovery full with NO_WAIT

And get yourself some coffee. Lots of coffee — the bigger your transaction log is, the longer it will take. Run this during a weekend, or as soon as you can when there are as little people in your office as possible; do NOT abort the process, or you’ll regret it.

The above snippet of code switches your database from a full recovery model to a simple recovery model. The full recovery model makes thorough use of the transaction log; the simple does not. Before SQL Server actually makes any changes to its database, it stores the commands in the transaction log – this is so that if your server crashes it can continue to execute what it was doing when it crashed. This is what makes your SQL database so nice and robust: it is catalogging EVERYTHING it’s doing so that if something goes wrong it can retrace its steps.

I know what you’re thinking, and no. It’s not a good idea to keep your database in ‘simple’ mode, no matter how good your backups are. The rule of thumb is that if you have a production database that stores data of any relevance at all to you, you should be using the full recovery model, period. If your database is a ‘holding area’, if you’re just using it to perform computations and pass it off to another database, you can use a simple recovery model, maybe even run the database on a RAID-0 array so it’s nice and fast. Or if your database is written to only once a day, for instance if you are retrieving data from another site or the web and caching it locally, then backing it up immediately afterwards. Those are the only two examples I can think of where it makes sense to use a simple recovery model.

Now that you’ve executed the above code, the following code should be pretty fast:
backup log WSS_Content to disk = N'{some backup location of your choice}’
go
dbcc shrinkfile(‘WSS_Content_Log’, 1)

This is what actually shrinks the file. It makes a backup of the transaction log as SQL 2008 expects it and then shrinks the file. Of course, if you have enough space in your backup drive, you may wish to just execute this code – it’ll all depend on how big your transaction log has grown.