You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Lieven Dekeyser <li...@netlog.com> on 2008/05/06 13:45:54 UTC
Shindig & Netlog
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
Re: Shindig & Netlog
Posted by Cassie <do...@google.com>.
On Tue, May 6, 2008 at 4:36 PM, Lieven Dekeyser <li...@netlog.com> wrote:
>
> On 06 May 2008, at 15:05, Cassie wrote:
>
> Fantastic writeup!
>> Just two quick things...
>>
>> On Tue, May 6, 2008 at 1:45 PM, Lieven Dekeyser <li...@netlog.com>
>> wrote:
>>
>> 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?
>>>
>>
>>
>> just an oversight(see the todo in the file :), i'll fix this.
>>
>
> Cool :-)
>
>
> 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?
>>>
>>
>>
>> shindig supports 0.6 and 0.7 right now and will shortly also support 0.8
>> we don't have support for 0.5 cause the code wasn't written until 0.6 was
>> already live. we could maybe write a js translation layer like we did for
>> the 0.6 apis and put that into shindig so that we support 0.5 as well. i
>> don't remember off hand what the diffs from 0.5 to 0.6 were but if it is
>> important to you guys you might want to give it a shot.
>>
>
> I don't think it's very important, and if the specs aren't backwards
> compatible I don't see a problem in requiring at least opensocial 0.6 for
> Netlog.
> Are there other directories of opensocial gadgets than
> opensocialdirectory.org ? It would be nice to be able to test our sandbox
> a little more...
I think you will just want to look at the hi5, myspace and orkut dirs. Of
course, you will need user accounts...
We don't have one open dir yet, but hopefully that will come later.
>
>
> Thanks,
>
>
> Lieven Dekeyser
> Desktop Application Developer
>
> Netlog NV
> Emile Braunplein 18
> B-9000 Ghent
> Belgium
>
>
>
>
Re: Shindig & Netlog
Posted by Lieven Dekeyser <li...@netlog.com>.
On 06 May 2008, at 15:05, Cassie wrote:
> Fantastic writeup!
> Just two quick things...
>
> On Tue, May 6, 2008 at 1:45 PM, Lieven Dekeyser <li...@netlog.com>
> wrote:
>
>> 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?
>
>
> just an oversight(see the todo in the file :), i'll fix this.
Cool :-)
>> 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?
>
>
> shindig supports 0.6 and 0.7 right now and will shortly also support
> 0.8
> we don't have support for 0.5 cause the code wasn't written until
> 0.6 was
> already live. we could maybe write a js translation layer like we
> did for
> the 0.6 apis and put that into shindig so that we support 0.5 as
> well. i
> don't remember off hand what the diffs from 0.5 to 0.6 were but if
> it is
> important to you guys you might want to give it a shot.
I don't think it's very important, and if the specs aren't backwards
compatible I don't see a problem in requiring at least opensocial 0.6
for Netlog.
Are there other directories of opensocial gadgets than
opensocialdirectory.org ? It would be nice to be able to test our
sandbox a little more...
Thanks,
Lieven Dekeyser
Desktop Application Developer
Netlog NV
Emile Braunplein 18
B-9000 Ghent
Belgium
Re: Shindig & Netlog
Posted by Cassie <do...@google.com>.
Fantastic writeup!
Just two quick things...
On Tue, May 6, 2008 at 1:45 PM, Lieven Dekeyser <li...@netlog.com> wrote:
> 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?
just an oversight(see the todo in the file :), i'll fix this.
>
> 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?
shindig supports 0.6 and 0.7 right now and will shortly also support 0.8
we don't have support for 0.5 cause the code wasn't written until 0.6 was
already live. we could maybe write a js translation layer like we did for
the 0.6 apis and put that into shindig so that we support 0.5 as well. i
don't remember off hand what the diffs from 0.5 to 0.6 were but if it is
important to you guys you might want to give it a shot.
as an example, here is the translation from 6 to 7
http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/opensocial-0.6/opensocial6to7.js
you would just need to write a 5 to 6 one (or 5 to 7 i suppose)
let me know if you have any questions.
>
> 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
>
>
>
>
Re: Shindig & Netlog
Posted by Lieven Dekeyser <li...@netlog.com>.
On 16 May 2008, at 15:36, Matthew (Chewy) Trewhella wrote:
>>
>> 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?
>>
>>
>> Interesting, can you give an example? Do you see
>> _IG_AdjustIframeHeight()
>> (or its new equivalent, gadgets.window.adjustHeight()) in the
>> initialization
>> code - or are you referring to this method not being called/
>> callable on
>> resize events?
>>
>
> In my experience, a lot of people who build gadgets simply don't use
> this
> function.
> I'm not sure if that's what Lieven is referring to, but I'm guessing
> so.
Sorry, forgot to reply to this one. That's exactly what I meant.
Thanks,
Lieven Dekeyser
Desktop Application Developer
Netlog NV
Emile Braunplein 18
B-9000 Ghent
Belgium
Re: Shindig & Netlog
Posted by "Matthew (Chewy) Trewhella" <ch...@google.com>.
>
> 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?
>
>
> Interesting, can you give an example? Do you see _IG_AdjustIframeHeight()
> (or its new equivalent, gadgets.window.adjustHeight()) in the
> initialization
> code - or are you referring to this method not being called/callable on
> resize events?
>
In my experience, a lot of people who build gadgets simply don't use this
function.
I'm not sure if that's what Lieven is referring to, but I'm guessing so.
Re: Shindig & Netlog
Posted by John Hjelmstad <fa...@google.com>.
On Tue, May 6, 2008 at 4:45 AM, Lieven Dekeyser <li...@netlog.com> wrote:
> 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.
>
In what way are you attempting to retrieve the height and width attributes?
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?
Interesting, can you give an example? Do you see _IG_AdjustIframeHeight()
(or its new equivalent, gadgets.window.adjustHeight()) in the initialization
code - or are you referring to this method not being called/callable on
resize events?
Congratulations on your launch!
--John
>
>
> Lieven Dekeyser
> Desktop Application Developer
>
> Netlog NV
> Emile Braunplein 18
> B-9000 Ghent
> Belgium
>
>
>
>