Hey,
For the past few weeks we've been working on integrating Shindig with
Netlog. Our sandbox is finally live on http://en.netlog.com/go/developer/opensocial
(If you don't have a Netlog account yet, you'll have to register
first)
Cassie and others asked us to leave a few notes on our implementation:
The basic steps are surprisingly straightforward:
- Provide implementations for the interfaces in
org.apache.shindig.social.opensocial.*
For Netlog, we're just using our internal API to request the data, so
the opensocial services basically make calls using our java client-
side api and reformat the output for Shindig. We haven't implemented
Netlog-specific calls yet, it's just the basic opensocial stuff for now.
- Inject our implementation using guice
We have one guice module which injects our GadgetTokenDecoder,
PeopleService, DataService and ActivitiesService implementations. This
required us to replace both the CommonGuiceModule and
SocialApiGuiceModule (code injections cannot be overridden), so we
also had to inject BasicRemoteContentFetcher, BasicContentCache and
the OpenSocialDataHandler.
As far as the build process goes, maven is not my cup of tea, so it's
kinda hacked together for now:
- Using svn:externals properties, we import a specific revision (right
now r653446) of the shindig repository in our working copies.
- Before building, the Shindig working copy is patched with a diff
file stored in our repository to represent our local changes. Amongst
other changes, this patches the web.xml file to use our guice module
in stead of CommonGuiceModule and SocialApiGuiceModule.
- After patching, Shindig (java/server) is built, our own *Service
implementations are built and the resulting jar files are put in the
war folder before running.
The sane thing to do would probably be to create our own pom.xml that
"installs" our jars in the local maven repository and add it as a
dependency to the server pom file, but I haven't had the time or
courage to look into this.
We're using Jetty to test, and Tomcat in production.
Pieter De Schepper did the gadget rendering part, and these are his
notes about gadgets.js:
- in the gadget render function: added appid and set the current view
- made the serverBase configurable
- some html changes to use our layout
- change in userprefsmenu toggle (toggle: show userprefsmenu, hide
gadget)
A few questions that came up while testing:
At first, Shindig didn't seem to pass the compliance test gadget
(default url in our sandbox), but after adding one line to features/
opensocial-0.7/jsonperson.js to indicate the type of dateOfBirth, it
works:
JsonPerson.constructObject(opt_params, "dateOfBirth", Date);
Has this just been overlooked, or is this change somehow incorrect?
A lot of gadgets from opensocialdirectory.org and the photostatus
sample ( http://opensocial-resources.googlecode.com/svn/samples/photostatus/trunk/photostatus.xml
) don't work as they require opensocial-0.5. Are the specs backwards
compatible, and if so, shouldn't Shindig handle opensocial-0.5
compatible gadgets with the opensocial-0.7 implementation?
There seem to be problems with the initial height of gadgets. It seems
that if an initial height is set in the gadget's xml, it's not passed
through correctly by Shindig. Also, a lot of gadgets don't seem to
call _IG_AdjustIFrameHeight() after initialization. Is there anything
we can do to make sure gadgets are displayed correctly?
Lieven Dekeyser
Desktop Application Developer
Netlog NV
Emile Braunplein 18
B-9000 Ghent
Belgium
