Ian,

Thank you for the response and the very thoughtful comments.  Yes, I do
agree that all things being equal, it would make the most sense to not
use 168 and use a JavaScript layout manager.  However, we have an
existing 168 compliant portal product that we are trying to add open
social gadget support to.  Given that, I have been trying to determine
the best way of doing this.

What I've done so far I believe is equivalent to your "trivial"
solution.  I have an iFrame portlet that is loading a trimmed down
version of the sample container that is packaged with shindig.  This
results in a gadget being rendered in the iframe.  As you say, this is a
pretty trivial solution, but I'm not sure if it's the best solution.
I'm looking for other options that ideally do not result in a huge
amount of work.

Tim 

-----Original Message-----
From: Ian Boston [mailto:[email protected]] On Behalf Of Ian
Boston
Sent: Monday, April 13, 2009 3:57 PM
To: [email protected]
Subject: Re: Shindig, OpenSocial, and Portlets

Presenting a portlet in a gadget should be no problem, its a portal
layout with a single portlet hosted inside a gadget iframe, IMHO,
slightly pointless over a servlet (as thats all a single portlet on a
page is conceptually) but if the code is all written....

Presenting a gadget in a portlet, there are 3 flavors, one trivial two
quite hard.
Trivial is a portlet that contains a gadget iframe, from the 168 point
of view this rather breaks the whole point of 168 which is a flat page
with no iframes.

Presenting a cajoled gadget inside a flat portlet is going to be hard as
168 will be trying to control the page lifecycle and the cajoed gadget
will also be expecting no page refresh.

Even harder would be to make a gadget obey the 168 page lifecycle.

IMVHO, it would make far more sense to make the portal layout manager
javascript and not use 168, then Gadgets and the 168 spec wouldn't be
fighting for control of the page lifecycle.

Ian
On 13 Apr 2009, at 09:45, <[email protected]>
<[email protected] 
 > wrote:

> Tim,
>
> This is an interesting problem :). While you are trying to host  
> gadgets
> using a Portal Server (front) over Shindig (back), I'm exploring the
> possibility of using Shindig (front) over Portal Server(back) i.e.
> exposing everything as gadgets (web pages, applications and portlets).
> Has anyone here written a portlet-gadget bridge or knows how to  
> present
> any JSR 168/286 portlet through a gadget (URL gadget?).
>
> Regards,
> Vinod
>
> -----Original Message-----
> From: Hafiz A Haq [mailto:[email protected]]
> Sent: Saturday, April 11, 2009 1:33 PM
> To: [email protected]
> Subject: Re: Shindig, OpenSocial, and Portlets
>
> I am integrating shindig into gxt based portlets, but it uses gwt .
>
> I am not sure if it would help you in anyway.
>
> Thanks and Regards,
> Hafiz
>
> 2009/4/10 Fisher, Tim <[email protected]>
>
>> Thanks for the response...   I'm told that the work Liferay did to
>> integrate Shindig is dated now and probably won't work with the most
> recent
>> version of Shindig.  The code is supposed to be in the Liferay SVN
>> repository, but I'm having a hard time even finding the code they
> wrote to
>> implement a Shindig portlet.
>>
>> I thought maybe someone would have some input even on integrating
> Shindig
>> into any portlet container.
>>
>> Tim
>>
>> -----Original Message-----
>> From: Vincent Siveton [mailto:[email protected]]
>> Sent: Wednesday, April 08, 2009 5:54 PM
>> To: [email protected]
>> Subject: Re: Shindig, OpenSocial, and Portlets
>>
>> IIRC Liferay adds recently a new shindig portlet plugin. I guess it
> will be
>> your first starting point :)
>>
>> Cheers,
>>
>> Vincent
>>
>> 2009/4/8 Fisher, Tim <[email protected]>:
>>> Has anyone rendered an OpenSocial gadget within a Liferay Portlet?
>>> Liferay portlets are JSR 168 & 286 compliant, so even if you
>>> integrated OpenSocial into another portlet container that would be
>>> interesting to me.  I'm thinking the solution would include Liferay
>>> rendering the portlet which then calls Shindig to render the gadget.
>>>
>>> Anyone with any relevant experience doing this?
>>>
>>> Tim
>>> The contents of this e-mail are intended for the named addressee
> only. It
>> contains information that may be confidential. Unless you are the
> named
>> addressee or an authorized designee, you may not copy or use it, or
> disclose
>> it to anyone else. If you received it in error please notify us
> immediately
>> and then destroy it.
>>>
>>
>>
>
>
> --
> He who asks is a fool for five minutes, but he who does not ask  
> remains
> a
> fool forever.
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any  
> attachments to this message are intended for the exclusive use of  
> the addressee(s) and may contain proprietary, confidential or  
> privileged information. If you are not the intended recipient, you  
> should not disseminate, distribute or copy this e-mail. Please  
> notify the sender immediately and destroy all copies of this message  
> and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The  
> recipient should check this email and any attachments for the  
> presence of viruses. The company accepts no liability for any damage  
> caused by any virus transmitted by this email.
>
> www.wipro.com

Reply via email to