You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Akash Xavier <ak...@gmail.com> on 2008/02/03 18:39:41 UTC
creating a custom container
Hi everyone,
I just downloaded the .js files of opensocial from the Google OpenSocial
Specs page...
Someone on the IRC Opensocial channel told me that those JS files are just
like templates and that developers are responsible to wire them up. Are we
supposed to just fill those gaps between empty {} ?
--
Akash Manohar
akashmanohar@gmail.com
Re: Getting Gadget Info without rendering gadget
Posted by Kevin Brown <et...@google.com>.
On Fri, Feb 15, 2008 at 6:32 AM, Dan Lester <da...@danlester.com> wrote:
>
> Just a thought: rpc should cater for the 'nocache' attribute - either in
> another input field or with query /rpc?nocache=1.
Yes, this will be added. We should probably open JIRA issues for these
things. Right now it can be resolved by making it so that instead of passing
a dummy ProcessingOptions down to GadgetServer, it passes an
HttpProcessingOptions, which will extract nocache params (amongst other
things).
Eventually, I'd like to refactor the JsonRpc stuff to a generic Rpc
interface so that we can support any wire format (JSON, XML, SOAP,
whatever). This is especially important to large organizations using shindig
that already have custom rpc infrastructure.
>
> Otherwise, I get the cached version for the info, then the ifr might
> return a newer version.
>
> Of course, under normal usage without nocache=1 there's no guarantee the
> cache won't expire between these stages. In fact, even with nocache=1,
> the XML could be changed between calls.
>
> Looking at the code, I wondered if query parameters should be passed to
> gadget server when invoked by the rpc servlet, but in tests it certainly
> doesn't work.
>
> Thanks,
>
> Dan
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 11 February 2008 22:09
> To: shindig-dev@incubator.apache.org
> Subject: Re: Getting Gadget Info without rendering gadget
>
>
> That's exactly the intended use for RpcServlet. Great example!
>
> On Feb 11, 2008 2:04 PM, Dan Lester <da...@danlester.com> wrote:
>
> >
> > OK, I'll keep checking out and trying the Rpc again over the next few
> > days. I'm playing around with both Java and PHP at the moment (but
> > both using Java gadget server of course). My initial code to get info
> > over Rpc just used curl in something like:
> >
> >
> > $gadgets_array = array();
> >
> > foreach ($gadgetUrls as $url) {
> > $gadgets_array[] = array( 'url' => $url,
> > 'moduleId' =>
> > count($gadgets_array)+1 );
> > }
> >
> > $req = array(
> > 'context' => array(
> > 'country' => 'US',
> > 'language' => 'en',
> > 'view' => 'default' ),
> > 'gadgets' => $gadgets_array );
> >
> > $rpc = new
> >
> RpcSender('http://localhost:8080/gadgets/rpc'<http://localhost:8080/gadgets/rpc%27>
> <http://localhost:8080/gadg
> ets/rpc%27 <http://localhost:8080/gadgets/rpc%27>>
> > );
> > $info = $rpc->Send($req);
> >
> > class RpcSender {
> >
> > private $addr;
> >
> > function __construct($addr) {
> > $this->addr = $addr;
> > }
> >
> > public function GetAddr() {
> > return $this->addr;
> > }
> >
> > public function Send($req) {
> > // req is an array-object that needs to be JSON-ified
> >
> > $json_req = json_encode($req);
> >
> > $ch = curl_init();
> > curl_setopt($ch, CURLOPT_URL, $this->GetAddr());
> > curl_setopt($ch, CURLOPT_POST, 1);
> > curl_setopt($ch, CURLOPT_POSTFIELDS, $json_req);
> > curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
> >
> > $res = curl_exec($ch);
> >
> > if (curl_errno($ch)) {
> > $res = null;
> > // Should handle curl_error($ch);
> > } else {
> > $res = json_decode($res, true);
> > }
> >
> > curl_close($ch);
> >
> > return $res;
> > }
> > }
> >
> >
> >
> > -----Original Message-----
> > From: Kevin Brown [mailto:etnu@google.com]
> > Sent: 11 February 2008 19:58
> > To: Dan Lester
> > Cc: shindig-dev@incubator.apache.org
> > Subject: Re: Getting Gadget Info without rendering gadget
> >
> >
> > On Feb 11, 2008 11:23 AM, Dan Lester <da...@danlester.com> wrote:
> >
> > > Kevin,
> > >
> > > The JsonRpc servlet is a great contribution - I've got it working
> > > from
> >
> > > PHP.
> > >
> > > However, is there any chance it could return all available details
> > > from the spec? That would include thumbnail_url, width, height,
> > > author_email, etc - every attribute on the ModulePrefs tag, I
> > > suppose.
> >
> >
> > Yes, these will be added. Not all of them are currently supported on
> > the GadgetSpec interface. I'll be adding these over the next few days
> > (after submitting the pending headers patch; see SHINDIG-56). I think
> > we'll ultimately wind up supporting the entire extended spec here, not
>
> > just the canonical one.
> >
> >
> > >
> > > You mention that error handling is "kind of rough". I think any
> > > client
> >
> > > can just cater for the idiosyncrasies for now, but one glaring issue
>
> > > is that any one gadget spec not found causes the whole call to break
>
> > > (returns 'Incomplete processing'). That rather ruins your hard work
> > > to
> >
> > > allow multiple gadget specs to be fetched at once.
> >
> >
> > I went ahead and fixed this in SHINDIG-56 as well. I didn't realize it
>
> > was breaking when anything failed, but rather only when something went
>
> > horribly wrong. I'll double check this.
> >
> >
> > >
> > >
> > > SHINDIG-25 is marked as closed which is why I'm bringing it up
> > > rather than just waiting to see if you had anything more in store...
> >
> >
> > I'd like new , individual bugs to be opened for specific issues as
> > they're encountered, which is why I closed SHINDIG-25.
> >
> > I'm glad you appreciate it, though. Thanks for the feedback!
> >
> > ~Kevin
> >
> >
>
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.
RE: Getting Gadget Info without rendering gadget
Posted by Dan Lester <da...@danlester.com>.
Just a thought: rpc should cater for the 'nocache' attribute - either in
another input field or with query /rpc?nocache=1.
Otherwise, I get the cached version for the info, then the ifr might
return a newer version.
Of course, under normal usage without nocache=1 there's no guarantee the
cache won't expire between these stages. In fact, even with nocache=1,
the XML could be changed between calls.
Looking at the code, I wondered if query parameters should be passed to
gadget server when invoked by the rpc servlet, but in tests it certainly
doesn't work.
Thanks,
Dan
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: 11 February 2008 22:09
To: shindig-dev@incubator.apache.org
Subject: Re: Getting Gadget Info without rendering gadget
That's exactly the intended use for RpcServlet. Great example!
On Feb 11, 2008 2:04 PM, Dan Lester <da...@danlester.com> wrote:
>
> OK, I'll keep checking out and trying the Rpc again over the next few
> days. I'm playing around with both Java and PHP at the moment (but
> both using Java gadget server of course). My initial code to get info
> over Rpc just used curl in something like:
>
>
> $gadgets_array = array();
>
> foreach ($gadgetUrls as $url) {
> $gadgets_array[] = array( 'url' => $url,
> 'moduleId' =>
> count($gadgets_array)+1 );
> }
>
> $req = array(
> 'context' => array(
> 'country' => 'US',
> 'language' => 'en',
> 'view' => 'default' ),
> 'gadgets' => $gadgets_array );
>
> $rpc = new
>
RpcSender('http://localhost:8080/gadgets/rpc'<http://localhost:8080/gadg
ets/rpc%27>
> );
> $info = $rpc->Send($req);
>
> class RpcSender {
>
> private $addr;
>
> function __construct($addr) {
> $this->addr = $addr;
> }
>
> public function GetAddr() {
> return $this->addr;
> }
>
> public function Send($req) {
> // req is an array-object that needs to be JSON-ified
>
> $json_req = json_encode($req);
>
> $ch = curl_init();
> curl_setopt($ch, CURLOPT_URL, $this->GetAddr());
> curl_setopt($ch, CURLOPT_POST, 1);
> curl_setopt($ch, CURLOPT_POSTFIELDS, $json_req);
> curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
>
> $res = curl_exec($ch);
>
> if (curl_errno($ch)) {
> $res = null;
> // Should handle curl_error($ch);
> } else {
> $res = json_decode($res, true);
> }
>
> curl_close($ch);
>
> return $res;
> }
> }
>
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 11 February 2008 19:58
> To: Dan Lester
> Cc: shindig-dev@incubator.apache.org
> Subject: Re: Getting Gadget Info without rendering gadget
>
>
> On Feb 11, 2008 11:23 AM, Dan Lester <da...@danlester.com> wrote:
>
> > Kevin,
> >
> > The JsonRpc servlet is a great contribution - I've got it working
> > from
>
> > PHP.
> >
> > However, is there any chance it could return all available details
> > from the spec? That would include thumbnail_url, width, height,
> > author_email, etc - every attribute on the ModulePrefs tag, I
> > suppose.
>
>
> Yes, these will be added. Not all of them are currently supported on
> the GadgetSpec interface. I'll be adding these over the next few days
> (after submitting the pending headers patch; see SHINDIG-56). I think
> we'll ultimately wind up supporting the entire extended spec here, not
> just the canonical one.
>
>
> >
> > You mention that error handling is "kind of rough". I think any
> > client
>
> > can just cater for the idiosyncrasies for now, but one glaring issue
> > is that any one gadget spec not found causes the whole call to break
> > (returns 'Incomplete processing'). That rather ruins your hard work
> > to
>
> > allow multiple gadget specs to be fetched at once.
>
>
> I went ahead and fixed this in SHINDIG-56 as well. I didn't realize it
> was breaking when anything failed, but rather only when something went
> horribly wrong. I'll double check this.
>
>
> >
> >
> > SHINDIG-25 is marked as closed which is why I'm bringing it up
> > rather than just waiting to see if you had anything more in store...
>
>
> I'd like new , individual bugs to be opened for specific issues as
> they're encountered, which is why I closed SHINDIG-25.
>
> I'm glad you appreciate it, though. Thanks for the feedback!
>
> ~Kevin
>
>
Re: Getting Gadget Info without rendering gadget
Posted by Kevin Brown <et...@google.com>.
That's exactly the intended use for RpcServlet. Great example!
On Feb 11, 2008 2:04 PM, Dan Lester <da...@danlester.com> wrote:
>
> OK, I'll keep checking out and trying the Rpc again over the next few
> days. I'm playing around with both Java and PHP at the moment (but both
> using Java gadget server of course). My initial code to get info over
> Rpc just used curl in something like:
>
>
> $gadgets_array = array();
>
> foreach ($gadgetUrls as $url) {
> $gadgets_array[] = array( 'url' => $url,
> 'moduleId' => count($gadgets_array)+1
> );
> }
>
> $req = array(
> 'context' => array(
> 'country' => 'US',
> 'language' => 'en',
> 'view' => 'default' ),
> 'gadgets' => $gadgets_array );
>
> $rpc = new RpcSender('http://localhost:8080/gadgets/rpc'<http://localhost:8080/gadgets/rpc%27>
> );
> $info = $rpc->Send($req);
>
> class RpcSender {
>
> private $addr;
>
> function __construct($addr) {
> $this->addr = $addr;
> }
>
> public function GetAddr() {
> return $this->addr;
> }
>
> public function Send($req) {
> // req is an array-object that needs to be JSON-ified
>
> $json_req = json_encode($req);
>
> $ch = curl_init();
> curl_setopt($ch, CURLOPT_URL, $this->GetAddr());
> curl_setopt($ch, CURLOPT_POST, 1);
> curl_setopt($ch, CURLOPT_POSTFIELDS, $json_req);
> curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
>
> $res = curl_exec($ch);
>
> if (curl_errno($ch)) {
> $res = null;
> // Should handle curl_error($ch);
> } else {
> $res = json_decode($res, true);
> }
>
> curl_close($ch);
>
> return $res;
> }
> }
>
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 11 February 2008 19:58
> To: Dan Lester
> Cc: shindig-dev@incubator.apache.org
> Subject: Re: Getting Gadget Info without rendering gadget
>
>
> On Feb 11, 2008 11:23 AM, Dan Lester <da...@danlester.com> wrote:
>
> > Kevin,
> >
> > The JsonRpc servlet is a great contribution - I've got it working from
>
> > PHP.
> >
> > However, is there any chance it could return all available details
> > from the spec? That would include thumbnail_url, width, height,
> > author_email, etc - every attribute on the ModulePrefs tag, I suppose.
>
>
> Yes, these will be added. Not all of them are currently supported on the
> GadgetSpec interface. I'll be adding these over the next few days (after
> submitting the pending headers patch; see SHINDIG-56). I think we'll
> ultimately wind up supporting the entire extended spec here, not just
> the canonical one.
>
>
> >
> > You mention that error handling is "kind of rough". I think any client
>
> > can just cater for the idiosyncrasies for now, but one glaring issue
> > is that any one gadget spec not found causes the whole call to break
> > (returns 'Incomplete processing'). That rather ruins your hard work to
>
> > allow multiple gadget specs to be fetched at once.
>
>
> I went ahead and fixed this in SHINDIG-56 as well. I didn't realize it
> was breaking when anything failed, but rather only when something went
> horribly wrong. I'll double check this.
>
>
> >
> >
> > SHINDIG-25 is marked as closed which is why I'm bringing it up rather
> > than just waiting to see if you had anything more in store...
>
>
> I'd like new , individual bugs to be opened for specific issues as
> they're encountered, which is why I closed SHINDIG-25.
>
> I'm glad you appreciate it, though. Thanks for the feedback!
>
> ~Kevin
>
>
RE: Getting Gadget Info without rendering gadget
Posted by Dan Lester <da...@danlester.com>.
OK, I'll keep checking out and trying the Rpc again over the next few
days. I'm playing around with both Java and PHP at the moment (but both
using Java gadget server of course). My initial code to get info over
Rpc just used curl in something like:
$gadgets_array = array();
foreach ($gadgetUrls as $url) {
$gadgets_array[] = array( 'url' => $url,
'moduleId' => count($gadgets_array)+1
);
}
$req = array(
'context' => array(
'country' => 'US',
'language' => 'en',
'view' => 'default' ),
'gadgets' => $gadgets_array );
$rpc = new RpcSender('http://localhost:8080/gadgets/rpc');
$info = $rpc->Send($req);
class RpcSender {
private $addr;
function __construct($addr) {
$this->addr = $addr;
}
public function GetAddr() {
return $this->addr;
}
public function Send($req) {
// req is an array-object that needs to be JSON-ified
$json_req = json_encode($req);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $this->GetAddr());
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $json_req);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$res = curl_exec($ch);
if (curl_errno($ch)) {
$res = null;
// Should handle curl_error($ch);
} else {
$res = json_decode($res, true);
}
curl_close($ch);
return $res;
}
}
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: 11 February 2008 19:58
To: Dan Lester
Cc: shindig-dev@incubator.apache.org
Subject: Re: Getting Gadget Info without rendering gadget
On Feb 11, 2008 11:23 AM, Dan Lester <da...@danlester.com> wrote:
> Kevin,
>
> The JsonRpc servlet is a great contribution - I've got it working from
> PHP.
>
> However, is there any chance it could return all available details
> from the spec? That would include thumbnail_url, width, height,
> author_email, etc - every attribute on the ModulePrefs tag, I suppose.
Yes, these will be added. Not all of them are currently supported on the
GadgetSpec interface. I'll be adding these over the next few days (after
submitting the pending headers patch; see SHINDIG-56). I think we'll
ultimately wind up supporting the entire extended spec here, not just
the canonical one.
>
> You mention that error handling is "kind of rough". I think any client
> can just cater for the idiosyncrasies for now, but one glaring issue
> is that any one gadget spec not found causes the whole call to break
> (returns 'Incomplete processing'). That rather ruins your hard work to
> allow multiple gadget specs to be fetched at once.
I went ahead and fixed this in SHINDIG-56 as well. I didn't realize it
was breaking when anything failed, but rather only when something went
horribly wrong. I'll double check this.
>
>
> SHINDIG-25 is marked as closed which is why I'm bringing it up rather
> than just waiting to see if you had anything more in store...
I'd like new , individual bugs to be opened for specific issues as
they're encountered, which is why I closed SHINDIG-25.
I'm glad you appreciate it, though. Thanks for the feedback!
~Kevin
Re: Getting Gadget Info without rendering gadget
Posted by Kevin Brown <et...@google.com>.
On Feb 11, 2008 11:23 AM, Dan Lester <da...@danlester.com> wrote:
> Kevin,
>
> The JsonRpc servlet is a great contribution - I've got it working from
> PHP.
>
> However, is there any chance it could return all available details from
> the spec? That would include thumbnail_url, width, height, author_email,
> etc - every attribute on the ModulePrefs tag, I suppose.
Yes, these will be added. Not all of them are currently supported on the
GadgetSpec interface. I'll be adding these over the next few days (after
submitting the pending headers patch; see SHINDIG-56). I think we'll
ultimately wind up supporting the entire extended spec here, not just the
canonical one.
>
> You mention that error handling is "kind of rough". I think any client
> can just cater for the idiosyncrasies for now, but one glaring issue is
> that any one gadget spec not found causes the whole call to break
> (returns 'Incomplete processing'). That rather ruins your hard work to
> allow multiple gadget specs to be fetched at once.
I went ahead and fixed this in SHINDIG-56 as well. I didn't realize it was
breaking when anything failed, but rather only when something went horribly
wrong. I'll double check this.
>
>
> SHINDIG-25 is marked as closed which is why I'm bringing it up rather
> than just waiting to see if you had anything more in store...
I'd like new , individual bugs to be opened for specific issues as they're
encountered, which is why I closed SHINDIG-25.
I'm glad you appreciate it, though. Thanks for the feedback!
~Kevin
Re: Getting Gadget Info without rendering gadget
Posted by Akash Xavier <ak...@gmail.com>.
Dan,
Are you working on a php container?
Can u share some details with others on how you implemented it?
On Feb 11, 2008 11:23 AM, Dan Lester <da...@danlester.com> wrote:
> Kevin,
>
> The JsonRpc servlet is a great contribution - I've got it working from
> PHP.
>
> However, is there any chance it could return all available details from
> the spec? That would include thumbnail_url, width, height, author_email,
> etc - every attribute on the ModulePrefs tag, I suppose.
>
> You mention that error handling is "kind of rough". I think any client
> can just cater for the idiosyncrasies for now, but one glaring issue is
> that any one gadget spec not found causes the whole call to break
> (returns 'Incomplete processing'). That rather ruins your hard work to
> allow multiple gadget specs to be fetched at once.
>
> SHINDIG-25 is marked as closed which is why I'm bringing it up rather
> than just waiting to see if you had anything more in store...
>
> Thanks,
>
> Dan
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 08 February 2008 01:58
> To: shindig-dev@incubator.apache.org
> Subject: Re: Getting Gadget Info without rendering gadget
>
>
> Yes, there will most likely just be a new method on GadgetServer (a new
> class would require replicating much of what it does already anyway).
>
> On Feb 7, 2008 5:32 PM, Dan Lester <da...@danlester.com> wrote:
>
> >
> > Excellent - thanks for pointing me to those open issues.
> >
> > I guess your JsonRpc servlet will be wrapping some classes that I can
> > access directly if I'm using Java. Prefer to use your 'official' code
> > than something I've hacked together for my own purposes...
> >
> > Anyway, I'll have a look at your submission when it's ready.
> >
> > Thanks,
> >
> > Dan
> >
> >
> > -----Original Message-----
> > From: Kevin Brown [mailto:etnu@google.com]
> > Sent: 07 February 2008 17:23
> > To: shindig-dev@incubator.apache.org
> > Subject: Re: Getting Gadget Info without rendering gadget
> >
> >
> > I'm working on a JsonRpc servlet that requires this functionality. If
> > you can wait until this weekend, you'll find that I've already got
> > everything that you probably need. See also
> > https://issues.apache.org/jira/browse/SHINDIG-51 and
> > https://issues.apache.org/jira/browse/SHINDIG-25.
> >
> > On Feb 7, 2008 8:39 AM, Dan Lester <da...@danlester.com> wrote:
> >
> > >
> > > Let's say I have a directory of gadgets that users might want to run
>
> > > on my site, entered only by URL. I want to display more information
> > > about each gadget to the user so they can make a choice about which
> > > gadgets they might want to run - so, I would want to extract
> > > information from the XML such as author name, thumbnail,
> > > description.
> > >
> > > So far, I have ripped out bits of code from
> > > GadgetRenderingServlet.java, doing most of the same things as the
> > > /ifr
> >
> > > servlet except for actually rendering the gadget. This seems to
> > > work, and even uses the same cache I think. But I just thought there
>
> > > must be
> >
> > > a better way? If not, is it worth adding a class to do this?
> > >
> > > I've decided to build the whole site in Java so that I can do things
>
> > > like this. I'm not sure what I'd do if I was using another language
> > > for the rest of my site.
> > >
> > > Thanks for any guidance!
> > >
> > > Dan
> > >
> > >
> >
> >
>
>
--
Akash Xavier
akashmanohar@gmail.com
RE: Getting Gadget Info without rendering gadget
Posted by Dan Lester <da...@danlester.com>.
Kevin,
The JsonRpc servlet is a great contribution - I've got it working from
PHP.
However, is there any chance it could return all available details from
the spec? That would include thumbnail_url, width, height, author_email,
etc - every attribute on the ModulePrefs tag, I suppose.
You mention that error handling is "kind of rough". I think any client
can just cater for the idiosyncrasies for now, but one glaring issue is
that any one gadget spec not found causes the whole call to break
(returns 'Incomplete processing'). That rather ruins your hard work to
allow multiple gadget specs to be fetched at once.
SHINDIG-25 is marked as closed which is why I'm bringing it up rather
than just waiting to see if you had anything more in store...
Thanks,
Dan
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: 08 February 2008 01:58
To: shindig-dev@incubator.apache.org
Subject: Re: Getting Gadget Info without rendering gadget
Yes, there will most likely just be a new method on GadgetServer (a new
class would require replicating much of what it does already anyway).
On Feb 7, 2008 5:32 PM, Dan Lester <da...@danlester.com> wrote:
>
> Excellent - thanks for pointing me to those open issues.
>
> I guess your JsonRpc servlet will be wrapping some classes that I can
> access directly if I'm using Java. Prefer to use your 'official' code
> than something I've hacked together for my own purposes...
>
> Anyway, I'll have a look at your submission when it's ready.
>
> Thanks,
>
> Dan
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 07 February 2008 17:23
> To: shindig-dev@incubator.apache.org
> Subject: Re: Getting Gadget Info without rendering gadget
>
>
> I'm working on a JsonRpc servlet that requires this functionality. If
> you can wait until this weekend, you'll find that I've already got
> everything that you probably need. See also
> https://issues.apache.org/jira/browse/SHINDIG-51 and
> https://issues.apache.org/jira/browse/SHINDIG-25.
>
> On Feb 7, 2008 8:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> >
> > Let's say I have a directory of gadgets that users might want to run
> > on my site, entered only by URL. I want to display more information
> > about each gadget to the user so they can make a choice about which
> > gadgets they might want to run - so, I would want to extract
> > information from the XML such as author name, thumbnail,
> > description.
> >
> > So far, I have ripped out bits of code from
> > GadgetRenderingServlet.java, doing most of the same things as the
> > /ifr
>
> > servlet except for actually rendering the gadget. This seems to
> > work, and even uses the same cache I think. But I just thought there
> > must be
>
> > a better way? If not, is it worth adding a class to do this?
> >
> > I've decided to build the whole site in Java so that I can do things
> > like this. I'm not sure what I'd do if I was using another language
> > for the rest of my site.
> >
> > Thanks for any guidance!
> >
> > Dan
> >
> >
>
>
Re: Getting Gadget Info without rendering gadget
Posted by Kevin Brown <et...@google.com>.
Yes, there will most likely just be a new method on GadgetServer (a new
class would require replicating much of what it does already anyway).
On Feb 7, 2008 5:32 PM, Dan Lester <da...@danlester.com> wrote:
>
> Excellent - thanks for pointing me to those open issues.
>
> I guess your JsonRpc servlet will be wrapping some classes that I can
> access directly if I'm using Java. Prefer to use your 'official' code
> than something I've hacked together for my own purposes...
>
> Anyway, I'll have a look at your submission when it's ready.
>
> Thanks,
>
> Dan
>
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: 07 February 2008 17:23
> To: shindig-dev@incubator.apache.org
> Subject: Re: Getting Gadget Info without rendering gadget
>
>
> I'm working on a JsonRpc servlet that requires this functionality. If
> you can wait until this weekend, you'll find that I've already got
> everything that you probably need. See also
> https://issues.apache.org/jira/browse/SHINDIG-51 and
> https://issues.apache.org/jira/browse/SHINDIG-25.
>
> On Feb 7, 2008 8:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> >
> > Let's say I have a directory of gadgets that users might want to run
> > on my site, entered only by URL. I want to display more information
> > about each gadget to the user so they can make a choice about which
> > gadgets they might want to run - so, I would want to extract
> > information from the XML such as author name, thumbnail, description.
> >
> > So far, I have ripped out bits of code from
> > GadgetRenderingServlet.java, doing most of the same things as the /ifr
>
> > servlet except for actually rendering the gadget. This seems to work,
> > and even uses the same cache I think. But I just thought there must be
>
> > a better way? If not, is it worth adding a class to do this?
> >
> > I've decided to build the whole site in Java so that I can do things
> > like this. I'm not sure what I'd do if I was using another language
> > for the rest of my site.
> >
> > Thanks for any guidance!
> >
> > Dan
> >
> >
>
>
RE: Getting Gadget Info without rendering gadget
Posted by Dan Lester <da...@danlester.com>.
Excellent - thanks for pointing me to those open issues.
I guess your JsonRpc servlet will be wrapping some classes that I can
access directly if I'm using Java. Prefer to use your 'official' code
than something I've hacked together for my own purposes...
Anyway, I'll have a look at your submission when it's ready.
Thanks,
Dan
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: 07 February 2008 17:23
To: shindig-dev@incubator.apache.org
Subject: Re: Getting Gadget Info without rendering gadget
I'm working on a JsonRpc servlet that requires this functionality. If
you can wait until this weekend, you'll find that I've already got
everything that you probably need. See also
https://issues.apache.org/jira/browse/SHINDIG-51 and
https://issues.apache.org/jira/browse/SHINDIG-25.
On Feb 7, 2008 8:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> Let's say I have a directory of gadgets that users might want to run
> on my site, entered only by URL. I want to display more information
> about each gadget to the user so they can make a choice about which
> gadgets they might want to run - so, I would want to extract
> information from the XML such as author name, thumbnail, description.
>
> So far, I have ripped out bits of code from
> GadgetRenderingServlet.java, doing most of the same things as the /ifr
> servlet except for actually rendering the gadget. This seems to work,
> and even uses the same cache I think. But I just thought there must be
> a better way? If not, is it worth adding a class to do this?
>
> I've decided to build the whole site in Java so that I can do things
> like this. I'm not sure what I'd do if I was using another language
> for the rest of my site.
>
> Thanks for any guidance!
>
> Dan
>
>
Re: Getting Gadget Info without rendering gadget
Posted by Kevin Brown <et...@google.com>.
I'm working on a JsonRpc servlet that requires this functionality. If you
can wait until this weekend, you'll find that I've already got everything
that you probably need. See also
https://issues.apache.org/jira/browse/SHINDIG-51 and
https://issues.apache.org/jira/browse/SHINDIG-25.
On Feb 7, 2008 8:39 AM, Dan Lester <da...@danlester.com> wrote:
>
> Let's say I have a directory of gadgets that users might want to run on
> my site, entered only by URL. I want to display more information about
> each gadget to the user so they can make a choice about which gadgets
> they might want to run - so, I would want to extract information from
> the XML such as author name, thumbnail, description.
>
> So far, I have ripped out bits of code from GadgetRenderingServlet.java,
> doing most of the same things as the /ifr servlet except for actually
> rendering the gadget. This seems to work, and even uses the same cache I
> think. But I just thought there must be a better way? If not, is it
> worth adding a class to do this?
>
> I've decided to build the whole site in Java so that I can do things
> like this. I'm not sure what I'd do if I was using another language for
> the rest of my site.
>
> Thanks for any guidance!
>
> Dan
>
>
Getting Gadget Info without rendering gadget
Posted by Dan Lester <da...@danlester.com>.
Let's say I have a directory of gadgets that users might want to run on
my site, entered only by URL. I want to display more information about
each gadget to the user so they can make a choice about which gadgets
they might want to run - so, I would want to extract information from
the XML such as author name, thumbnail, description.
So far, I have ripped out bits of code from GadgetRenderingServlet.java,
doing most of the same things as the /ifr servlet except for actually
rendering the gadget. This seems to work, and even uses the same cache I
think. But I just thought there must be a better way? If not, is it
worth adding a class to do this?
I've decided to build the whole site in Java so that I can do things
like this. I'm not sure what I'd do if I was using another language for
the rest of my site.
Thanks for any guidance!
Dan
Re: creating a custom container
Posted by Akash Xavier <ak...@gmail.com>.
Cassie...
I have this doubt.
My technical language might be a little bad. So please bare with me.
I have filled up the blanks between {} in almost all the files. Now I am
only parsing the gadget file with php and rendering it within an iframe.
The parsing is done as per the Canonical Gadget Spec as specified in the API
Specification. To connect the opensocial javascript to the backend I have
used AJAX requests within those {}. I have made the data available to these
ajax-php calls through RPC (implemented in the php file). Is that enough to
get a working container or am I supposed to do anything else.
On Feb 7, 2008 5:12 AM, Akash Xavier <ak...@gmail.com> wrote:
> Thank You very much Cassie!
> Fantastic reply!
> That was what I really needed!
>
> That's easier to understand because you got into technical details.
>
>
> On Feb 6, 2008 8:32 PM, Cassie <do...@apache.org> wrote:
>
> > Oh, one last point. So the reason I recommend making a separate file for
> > mycontainer.js and using inherits is because it makes upgrading the
> > version
> > of your container infinitely easier. The reference files always get
> > upgraded
> > to support the latest version of opensocial (0.7 right now) and are set
> > up
> > in such a way that you can simply drop in the new files when you want to
> > upgrade your site. This allows you to perhaps implement one or two more
> > mycontainer methods for each version without worrying about exactly what
> > the
> > user facing calls are. That's the only reason why just putting code
> > between
> > the {} isn't recommended. (it would work though :)
> >
> > - Cassie
> >
> >
> > On Wed, Feb 6, 2008 at 8:26 PM, Cassie <do...@apache.org> wrote:
> >
> > > I think Kevin might have confused your question with another one
> > Akash.
> > >
> > > Here is what you should do:
> > > 1. Use the opensocial reference files found in the
> > > features/opensocial-reference directory (you did this already)
> > > 2. Create one additional file called "mycontainer.js"
> > > 3. Within mycontainer.js make a javascript class which extends the
> > > opensocial.container class found in the container.js file. You can use
> > the
> > > .inherits method to do this extension. (Function.inherits is included
> > in
> > > opensocial.js)
> > > 4. Override/implement all of the methods you need to. The functions
> > > should have some semi-decent js docs which tell you what you need to
> > do.
> > > 5. As the last line in your mycontainer.js file call
> > > opensocial.Container.set(new MyContainer()); (tailor that to your
> > class of
> > > course)
> > >
> > > And that's it! That should give you a fully functioning opensocial
> > > container. The code you just created all goes within each of the
> > gadget
> > > iframes (that's just the default setup we have right now, it is not
> > > mandatory) and then gadgets can use the opensocial calls.
> > >
> > >
> > > Now, steps 3-5 are a little tricky to describe with words which is why
> > I
> > > made the samplecontainer.js file. You can find it in your
> > > features/opensocial-samplecontainer directory. It does the inherits,
> > has
> > > some fake data, implements the right things and so forth. Many people
> > may
> > > want to just copy the samplecontainer.js file and modify it to suit
> > their
> > > needs. The one main difference is that your opensocial container will
> > > probably need to talk back to your servers (rather than just having
> > all of
> > > the data locally).
> > >
> > > I am working on a servercontainer.js which will hopefully serve as a
> > good,
> > > and more useful, reference container. It will most likely talk back to
> > some
> > > optional shindig servlets or something. I haven't made to much
> > progress yet
> > > though so if you get yours working and want to submit a patch that
> > would be
> > > fantastic!
> > >
> > > Okay, let me know if you have any troubles and happy opensocialing it
> > up.
> > >
> > > - Cassie
> > >
> > >
> > >
> > > On Sun, Feb 3, 2008 at 5:12 PM, Akash Xavier <ak...@gmail.com>
> > > wrote:
> > >
> > > > Kevin,
> > > >
> > > > Do I just have to fill those blanks between { } or do I have to
> > edit
> > > > the
> > > > function names?
> > > >
> > > > On Feb 3, 2008 1:53 PM, Kevin Brown <et...@google.com> wrote:
> > > >
> > > > > I wouldn't try to use the sample pages to make real sites. As the
> > name
> > > > > "reference" implies, they really are just there to show you how to
> > > > wire
> > > > > your
> > > > > own site to use the server. Hopefully this will become clearer
> > once
> > > > the
> > > > > RpcServlet becomes available and it's possible to really do
> > everything
> > > > the
> > > > > "right way".
> > > > >
> > > > > ~Kevin
> > > > >
> > > > > On Feb 3, 2008 9:39 AM, Akash Xavier <ak...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > I just downloaded the .js files of opensocial from the Google
> > > > OpenSocial
> > > > > > Specs page...
> > > > > > Someone on the IRC Opensocial channel told me that those JS
> > files
> > > > are
> > > > > just
> > > > > > like templates and that developers are responsible to wire them
> > up.
> > > > Are
> > > > > we
> > > > > > supposed to just fill those gaps between empty {} ?
> > > > > >
> > > > > > --
> > > > > > Akash Manohar
> > > > > > akashmanohar@gmail.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Akash Manohar
> > > > akashmanohar@gmail.com
> > > >
> > >
> > >
> >
>
>
>
> --
>
> Akash Manohar
> akashmanohar@gmail.com
>
--
Akash Manohar
akashmanohar@gmail.com
Re: creating a custom container
Posted by Akash Xavier <ak...@gmail.com>.
Thank You very much Cassie!
Fantastic reply!
That was what I really needed!
That's easier to understand because you got into technical details.
On Feb 6, 2008 8:32 PM, Cassie <do...@apache.org> wrote:
> Oh, one last point. So the reason I recommend making a separate file for
> mycontainer.js and using inherits is because it makes upgrading the
> version
> of your container infinitely easier. The reference files always get
> upgraded
> to support the latest version of opensocial (0.7 right now) and are set up
> in such a way that you can simply drop in the new files when you want to
> upgrade your site. This allows you to perhaps implement one or two more
> mycontainer methods for each version without worrying about exactly what
> the
> user facing calls are. That's the only reason why just putting code
> between
> the {} isn't recommended. (it would work though :)
>
> - Cassie
>
>
> On Wed, Feb 6, 2008 at 8:26 PM, Cassie <do...@apache.org> wrote:
>
> > I think Kevin might have confused your question with another one Akash.
> >
> > Here is what you should do:
> > 1. Use the opensocial reference files found in the
> > features/opensocial-reference directory (you did this already)
> > 2. Create one additional file called "mycontainer.js"
> > 3. Within mycontainer.js make a javascript class which extends the
> > opensocial.container class found in the container.js file. You can use
> the
> > .inherits method to do this extension. (Function.inherits is included in
> > opensocial.js)
> > 4. Override/implement all of the methods you need to. The functions
> > should have some semi-decent js docs which tell you what you need to do.
> > 5. As the last line in your mycontainer.js file call
> > opensocial.Container.set(new MyContainer()); (tailor that to your class
> of
> > course)
> >
> > And that's it! That should give you a fully functioning opensocial
> > container. The code you just created all goes within each of the gadget
> > iframes (that's just the default setup we have right now, it is not
> > mandatory) and then gadgets can use the opensocial calls.
> >
> >
> > Now, steps 3-5 are a little tricky to describe with words which is why I
> > made the samplecontainer.js file. You can find it in your
> > features/opensocial-samplecontainer directory. It does the inherits, has
> > some fake data, implements the right things and so forth. Many people
> may
> > want to just copy the samplecontainer.js file and modify it to suit
> their
> > needs. The one main difference is that your opensocial container will
> > probably need to talk back to your servers (rather than just having all
> of
> > the data locally).
> >
> > I am working on a servercontainer.js which will hopefully serve as a
> good,
> > and more useful, reference container. It will most likely talk back to
> some
> > optional shindig servlets or something. I haven't made to much progress
> yet
> > though so if you get yours working and want to submit a patch that would
> be
> > fantastic!
> >
> > Okay, let me know if you have any troubles and happy opensocialing it
> up.
> >
> > - Cassie
> >
> >
> >
> > On Sun, Feb 3, 2008 at 5:12 PM, Akash Xavier <ak...@gmail.com>
> > wrote:
> >
> > > Kevin,
> > >
> > > Do I just have to fill those blanks between { } or do I have to edit
> > > the
> > > function names?
> > >
> > > On Feb 3, 2008 1:53 PM, Kevin Brown <et...@google.com> wrote:
> > >
> > > > I wouldn't try to use the sample pages to make real sites. As the
> name
> > > > "reference" implies, they really are just there to show you how to
> > > wire
> > > > your
> > > > own site to use the server. Hopefully this will become clearer once
> > > the
> > > > RpcServlet becomes available and it's possible to really do
> everything
> > > the
> > > > "right way".
> > > >
> > > > ~Kevin
> > > >
> > > > On Feb 3, 2008 9:39 AM, Akash Xavier <ak...@gmail.com> wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > I just downloaded the .js files of opensocial from the Google
> > > OpenSocial
> > > > > Specs page...
> > > > > Someone on the IRC Opensocial channel told me that those JS files
> > > are
> > > > just
> > > > > like templates and that developers are responsible to wire them
> up.
> > > Are
> > > > we
> > > > > supposed to just fill those gaps between empty {} ?
> > > > >
> > > > > --
> > > > > Akash Manohar
> > > > > akashmanohar@gmail.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Akash Manohar
> > > akashmanohar@gmail.com
> > >
> >
> >
>
--
Akash Manohar
akashmanohar@gmail.com
Re: creating a custom container
Posted by Cassie <do...@apache.org>.
Oh, one last point. So the reason I recommend making a separate file for
mycontainer.js and using inherits is because it makes upgrading the version
of your container infinitely easier. The reference files always get upgraded
to support the latest version of opensocial (0.7 right now) and are set up
in such a way that you can simply drop in the new files when you want to
upgrade your site. This allows you to perhaps implement one or two more
mycontainer methods for each version without worrying about exactly what the
user facing calls are. That's the only reason why just putting code between
the {} isn't recommended. (it would work though :)
- Cassie
On Wed, Feb 6, 2008 at 8:26 PM, Cassie <do...@apache.org> wrote:
> I think Kevin might have confused your question with another one Akash.
>
> Here is what you should do:
> 1. Use the opensocial reference files found in the
> features/opensocial-reference directory (you did this already)
> 2. Create one additional file called "mycontainer.js"
> 3. Within mycontainer.js make a javascript class which extends the
> opensocial.container class found in the container.js file. You can use the
> .inherits method to do this extension. (Function.inherits is included in
> opensocial.js)
> 4. Override/implement all of the methods you need to. The functions
> should have some semi-decent js docs which tell you what you need to do.
> 5. As the last line in your mycontainer.js file call
> opensocial.Container.set(new MyContainer()); (tailor that to your class of
> course)
>
> And that's it! That should give you a fully functioning opensocial
> container. The code you just created all goes within each of the gadget
> iframes (that's just the default setup we have right now, it is not
> mandatory) and then gadgets can use the opensocial calls.
>
>
> Now, steps 3-5 are a little tricky to describe with words which is why I
> made the samplecontainer.js file. You can find it in your
> features/opensocial-samplecontainer directory. It does the inherits, has
> some fake data, implements the right things and so forth. Many people may
> want to just copy the samplecontainer.js file and modify it to suit their
> needs. The one main difference is that your opensocial container will
> probably need to talk back to your servers (rather than just having all of
> the data locally).
>
> I am working on a servercontainer.js which will hopefully serve as a good,
> and more useful, reference container. It will most likely talk back to some
> optional shindig servlets or something. I haven't made to much progress yet
> though so if you get yours working and want to submit a patch that would be
> fantastic!
>
> Okay, let me know if you have any troubles and happy opensocialing it up.
>
> - Cassie
>
>
>
> On Sun, Feb 3, 2008 at 5:12 PM, Akash Xavier <ak...@gmail.com>
> wrote:
>
> > Kevin,
> >
> > Do I just have to fill those blanks between { } or do I have to edit
> > the
> > function names?
> >
> > On Feb 3, 2008 1:53 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > I wouldn't try to use the sample pages to make real sites. As the name
> > > "reference" implies, they really are just there to show you how to
> > wire
> > > your
> > > own site to use the server. Hopefully this will become clearer once
> > the
> > > RpcServlet becomes available and it's possible to really do everything
> > the
> > > "right way".
> > >
> > > ~Kevin
> > >
> > > On Feb 3, 2008 9:39 AM, Akash Xavier <ak...@gmail.com> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I just downloaded the .js files of opensocial from the Google
> > OpenSocial
> > > > Specs page...
> > > > Someone on the IRC Opensocial channel told me that those JS files
> > are
> > > just
> > > > like templates and that developers are responsible to wire them up.
> > Are
> > > we
> > > > supposed to just fill those gaps between empty {} ?
> > > >
> > > > --
> > > > Akash Manohar
> > > > akashmanohar@gmail.com
> > > >
> > >
> >
> >
> >
> > --
> > Akash Manohar
> > akashmanohar@gmail.com
> >
>
>
Re: creating a custom container
Posted by Cassie <do...@apache.org>.
I think Kevin might have confused your question with another one Akash.
Here is what you should do:
1. Use the opensocial reference files found in the
features/opensocial-reference directory (you did this already)
2. Create one additional file called "mycontainer.js"
3. Within mycontainer.js make a javascript class which extends the
opensocial.container class found in the container.js file. You can use the
.inherits method to do this extension. (Function.inherits is included in
opensocial.js)
4. Override/implement all of the methods you need to. The functions should
have some semi-decent js docs which tell you what you need to do.
5. As the last line in your mycontainer.js file call
opensocial.Container.set(new MyContainer()); (tailor that to your class of
course)
And that's it! That should give you a fully functioning opensocial
container. The code you just created all goes within each of the gadget
iframes (that's just the default setup we have right now, it is not
mandatory) and then gadgets can use the opensocial calls.
Now, steps 3-5 are a little tricky to describe with words which is why I
made the samplecontainer.js file. You can find it in your
features/opensocial-samplecontainer directory. It does the inherits, has
some fake data, implements the right things and so forth. Many people may
want to just copy the samplecontainer.js file and modify it to suit their
needs. The one main difference is that your opensocial container will
probably need to talk back to your servers (rather than just having all of
the data locally).
I am working on a servercontainer.js which will hopefully serve as a good,
and more useful, reference container. It will most likely talk back to some
optional shindig servlets or something. I haven't made to much progress yet
though so if you get yours working and want to submit a patch that would be
fantastic!
Okay, let me know if you have any troubles and happy opensocialing it up.
- Cassie
On Sun, Feb 3, 2008 at 5:12 PM, Akash Xavier <ak...@gmail.com> wrote:
> Kevin,
>
> Do I just have to fill those blanks between { } or do I have to edit the
> function names?
>
> On Feb 3, 2008 1:53 PM, Kevin Brown <et...@google.com> wrote:
>
> > I wouldn't try to use the sample pages to make real sites. As the name
> > "reference" implies, they really are just there to show you how to wire
> > your
> > own site to use the server. Hopefully this will become clearer once the
> > RpcServlet becomes available and it's possible to really do everything
> the
> > "right way".
> >
> > ~Kevin
> >
> > On Feb 3, 2008 9:39 AM, Akash Xavier <ak...@gmail.com> wrote:
> >
> > > Hi everyone,
> > >
> > > I just downloaded the .js files of opensocial from the Google
> OpenSocial
> > > Specs page...
> > > Someone on the IRC Opensocial channel told me that those JS files are
> > just
> > > like templates and that developers are responsible to wire them up.
> Are
> > we
> > > supposed to just fill those gaps between empty {} ?
> > >
> > > --
> > > Akash Manohar
> > > akashmanohar@gmail.com
> > >
> >
>
>
>
> --
> Akash Manohar
> akashmanohar@gmail.com
>
Re: creating a custom container
Posted by Akash Xavier <ak...@gmail.com>.
Kevin,
Do I just have to fill those blanks between { } or do I have to edit the
function names?
On Feb 3, 2008 1:53 PM, Kevin Brown <et...@google.com> wrote:
> I wouldn't try to use the sample pages to make real sites. As the name
> "reference" implies, they really are just there to show you how to wire
> your
> own site to use the server. Hopefully this will become clearer once the
> RpcServlet becomes available and it's possible to really do everything the
> "right way".
>
> ~Kevin
>
> On Feb 3, 2008 9:39 AM, Akash Xavier <ak...@gmail.com> wrote:
>
> > Hi everyone,
> >
> > I just downloaded the .js files of opensocial from the Google OpenSocial
> > Specs page...
> > Someone on the IRC Opensocial channel told me that those JS files are
> just
> > like templates and that developers are responsible to wire them up. Are
> we
> > supposed to just fill those gaps between empty {} ?
> >
> > --
> > Akash Manohar
> > akashmanohar@gmail.com
> >
>
--
Akash Manohar
akashmanohar@gmail.com
Re: creating a custom container
Posted by Kevin Brown <et...@google.com>.
I wouldn't try to use the sample pages to make real sites. As the name
"reference" implies, they really are just there to show you how to wire your
own site to use the server. Hopefully this will become clearer once the
RpcServlet becomes available and it's possible to really do everything the
"right way".
~Kevin
On Feb 3, 2008 9:39 AM, Akash Xavier <ak...@gmail.com> wrote:
> Hi everyone,
>
> I just downloaded the .js files of opensocial from the Google OpenSocial
> Specs page...
> Someone on the IRC Opensocial channel told me that those JS files are just
> like templates and that developers are responsible to wire them up. Are we
> supposed to just fill those gaps between empty {} ?
>
> --
> Akash Manohar
> akashmanohar@gmail.com
>