Project SocialSite in Action

It's Sunday morning and the Sony Ericsson Open Men's final is terrible, so I've decided to start writing a blog entry I've been preparing for a few days. Last week while doing some research and comparing a few social platforms for a project I stumbled upon a fairly new open source project called Socialsite. I was pretty impressed with what it's got to offer and found the documentation is still a bit scarce, so I thought a blog entry could contribute in some way to anyone out there trying to get a better insight into getting started with Socialsite or at least introducing the project to those unfamiliar with Socialsite.

The first thing to know about Socialsite is how it differs from any other social network platforms available out there (i.e. Dolphin, Ning, Kickapps, etc). The existing documentation does a pretty good job explaining what Socialsite is, so I won't delve into explaining all the concepts behind it. The pitch line, though, for keeping you reading is that Socialsite is different as it not only can also be used to build a socially enabled site, but it allows you to socially enable your EXISTING site. The trick to being able to do this (and what makes Socialsite interesting and different) is that Socialsite only works as your social graph repository, storing information on the user's connections, activities, etc. Your site already stores the user credentials and roles and provides authenticating and session management, so why keep your site from doing what it has always done (and hopefully does well) if all you want is to socially enable it?

Sociasite allows you (it actually forces you) to keep your current user authentication while using Socialsite for what it's good at. That is, store your social graph (which can be shared by more than one site), allow you to add OpenSocial gadgets, and even access your social activities and more through OpenSocial Web Services.

Now for a little less conversation and a little more action, I'll show you how I 'socially enabled' the famous open source application 'Appfuse' to show just a bit of what Socialsite can potentially do. The appfuse version I used is the Struts 2 Modular in full source mode (It just made it easier to identify the User manager and declare the Struts 2 actions and Spring beans).

There are several blogs and guides out there that explain the basic steps of what to do to socially enable your site with SocialSite, however I will attempt to fill in some gaps I found on those guides and by integrating Socialsite with an out-of-the-box application like Appfuse I'm hopefully providing a faster and easier way to test what Socialsite can do.

Since your existing application (in this case Appfuse) is in charge of user management, the first step in socially enabling your site is to provide an authentication delegator that Socialsite can use to call and verify user logins. The delegate can be any page that returns a JSON response in the following format:

{'timeout': 3600,'assertions': {'containerId': 'appfuse','viewer': {'id': 'user'},}}

This response will give Socialsite information on who is the current logged in 'VIEWER' and the 'OWNER' of the profile. Since in Appfuse (out-of-the-box), the logged-in user can only view his own profile, in this example the viewer will always be the same as the owner. The class that generates the JSON response in my Appfuse example SocialsiteContextAction.java is a Struts 2 action class which writes directly to the response object as opposed to forwarding to a JSP or any other view technology (for demonstration purposes).

Once you have this in place, all you have to do is declare the Struts 2 action in your struts.xml file. Call it whatever you want. I called it 'socialsite_context' pretty clever uh? Then you can invoke the action as http://localhost:8080/appfuse/socialsite_context.html. Notice the '.html' in the end; this is because Appfuse uses a filter that allows you to call all your Struts 2 actions with the '.html' extension instead of the common '.action'.

Now that your delegate is ready and working, the next step is to register your delegate with Socialsite. Socialsite will not allow any application delegate to make use of the social graph, so you need to explicitly tell Socialsite to 'trust' your delegate by adding it to a socialsite_context.xml in the classpath. If Socialsite is running in glassfish, the location for the XML file will be .<GLASSFISH_HOME>/domains/domain1/lib/classes. Use the following socialsite_context.xml file to have socialsite trust your appfuse application. The file assumes appfuse is deployed to your localhost and at the /appfuse context root so please change this accordingly to resemble your installation.

If this step wasn't required, then any site could access and even modify your social graph and that would not be great!

Once you have these two steps in place then all you have to do is add some JavaScript to Appfuse to load the Opensocial gadgets and tell Socialsite about your delegate.

In mainMenu.jsp, add the following code:

<script type=“text/javascript”
src=“http://localhost:8080/socialsite/js/consumer.jsp”></script>
<script type=“text/javascript”>
socialsite.setContext({
attributes’: {
‘ownerId’: ‘${pageContext.request.remoteUser}’,
‘viewerId’: ‘${pageContext.request.remoteUser}’
},
‘delegate’: {
‘method’: ‘GET’,
‘url’: ‘http://localhost:8080/appfuse/socialsite_context.html?owner=${pageContext.request.remoteUser}’,
‘headers’: {
‘cookie’: document.cookie
}
}
});
</script>

All you are doing here is providing context for Socialsite, letting it know who the owner and viewer are for the page (same in this case) and what authentication delegate it should use (the one you alreadycreated). The query string parameter 'owner' allows SocialSite to tell Appfuse who the profile owner is. Your application obviously knows about the viewer (as it is the logged-in user) but the owner, if you had public profiles, could be a different user. Look at the code again in SocialsiteContextAction.java to see how the request parameter 'owner' is being used to tell SocialSite who the owner is.

Now you actually have to add a Gadget that displays the data in your social graph. The following JavaScript code will take care of that.

<script type="text/javascript">
   socialsite.addGadget({'spec':'/local_gadgets/dashboard.xml', 'removable':false});
</script>

I have uploaded the modified version of mainMenu.jsp in case you need it.

Guess what? You are done! Now you can log in to Appfuse using the normal default user/user credentials or those of any other users you created and you will see the Main Menu page displaying the Socialsite user dashboard gadget!

If you experience any issues viewing the Gadgets, you might want to make sure that your users in Appfuse have an existing profile in Socialsite. You can add a profile for your users easily through the self registration link of your Socialsite installation at https://localhost:8181/socialsite/selfregistration/SelfRegistration

Check out the following screenshots to see the socially enabled version of Appfuse.

I hope this entry is useful to anyone, you don't have to follow the steps exactly with Appfuse the point is to get your creativity going and build any crazy thing you can think of. Project Socialsite is still not production ready but the community seems actively involved and hopefully they'll continue to grow. I'm looking forward to a production release!

Next to come, OpenSocial RESTFull web services and Socialsite making them easy!