You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Erik Gomersbach (Bluewin)" <er...@bluewin.ch> on 2008/11/05 21:18:43 UTC
Extending PHP Shindig beyond standard services
Hi,
I'm currently looking at extending the container functionality beyond the standard activity, app-data, messages and person services.
For the client/javascript part I found the hi5 code very helpful with getting a better understanding on how to do this.
Example:
Hi5Container.prototype.newAlbumsRequest = function(idSpec, opt_params) {
var rpc = { method : "albums.get" };
...
On the server/PHP side I've added code to the 'ApiServlet' class to handle the requests coming in on the new RPC topic, similar to how the other handlers are added.
Now my question is if this is the best way to extend Shindig/PHP? Or is it possible to do this without having to change the 'ApiServlet' class?
Thanks,
Erik
Re: Extending PHP Shindig beyond standard services
Posted by "Erik Gomersbach (Bluewin)" <er...@bluewin.ch>.
Thanks Chris,
In that case I'll have a go at my first Shindig patch.
Cheers,
Erik
----- Original Message -----
From: "Chris Chabot" <ch...@google.com>
To: <sh...@incubator.apache.org>
Sent: Wednesday, November 05, 2008 11:04 PM
Subject: Re: Extending PHP Shindig beyond standard services
> Hmmm that is actually a good question, and to be honest I haven't really
> thought about this before :)
>
> I guess theoretically you could lift the routing strings from ApiServlet
> and
> put the route => handler pairs in the configuration file, and thus adding
> a
> new custom route would be as simple as configuring a route + class to
> handle
> it (the autoloader should pick up on the class name no problem).
>
> that would take care of the routing / handler part, but then you'd also
> have
> to think of a clever way to re-work the in-&output converters, right now
> it's a class per format (xml, atom, json) with a function per conversion
> type (activity, person, app data).. you could however rework this to a
> class
> per type (route name), with a convert xml / atom / json functions, and
> thus
> being able to extend this dynamically too by depending on the autoloader
> again.
>
> Not a huge amount of code to realize I guess, if you feel motivated to
> code
> this up and submit a patch I'd be more then happy to accept it! (or
> otherwise put this suggestion on my overly long todo list, in which case i
> would suggest filing a ticket in our jira system:
> https://issues.apache.org/jira/secure/CreateIssue!default.jspa)
>
> Hope that's of some help!
>
> -- Chris
>
> On Wed, Nov 5, 2008 at 9:18 PM, Erik Gomersbach (Bluewin)
> <er...@bluewin.ch>wrote:
>
>> Hi,
>>
>> I'm currently looking at extending the container functionality beyond the
>> standard activity, app-data, messages and person services.
>>
>> For the client/javascript part I found the hi5 code very helpful with
>> getting a better understanding on how to do this.
>>
>> Example:
>>
>> Hi5Container.prototype.newAlbumsRequest = function(idSpec, opt_params) {
>> var rpc = { method : "albums.get" };
>> ...
>>
>> On the server/PHP side I've added code to the 'ApiServlet' class to
>> handle
>> the requests coming in on the new RPC topic, similar to how the other
>> handlers are added.
>>
>> Now my question is if this is the best way to extend Shindig/PHP? Or is
>> it
>> possible to do this without having to change the 'ApiServlet' class?
>>
>> Thanks,
>> Erik
>
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.6/1769 - Release Date: 11/5/2008
7:17 AM
Re: Extending PHP Shindig beyond standard services
Posted by Chris Chabot <ch...@google.com>.
Hmmm that is actually a good question, and to be honest I haven't really
thought about this before :)
I guess theoretically you could lift the routing strings from ApiServlet and
put the route => handler pairs in the configuration file, and thus adding a
new custom route would be as simple as configuring a route + class to handle
it (the autoloader should pick up on the class name no problem).
that would take care of the routing / handler part, but then you'd also have
to think of a clever way to re-work the in-&output converters, right now
it's a class per format (xml, atom, json) with a function per conversion
type (activity, person, app data).. you could however rework this to a class
per type (route name), with a convert xml / atom / json functions, and thus
being able to extend this dynamically too by depending on the autoloader
again.
Not a huge amount of code to realize I guess, if you feel motivated to code
this up and submit a patch I'd be more then happy to accept it! (or
otherwise put this suggestion on my overly long todo list, in which case i
would suggest filing a ticket in our jira system:
https://issues.apache.org/jira/secure/CreateIssue!default.jspa)
Hope that's of some help!
-- Chris
On Wed, Nov 5, 2008 at 9:18 PM, Erik Gomersbach (Bluewin)
<er...@bluewin.ch>wrote:
> Hi,
>
> I'm currently looking at extending the container functionality beyond the
> standard activity, app-data, messages and person services.
>
> For the client/javascript part I found the hi5 code very helpful with
> getting a better understanding on how to do this.
>
> Example:
>
> Hi5Container.prototype.newAlbumsRequest = function(idSpec, opt_params) {
> var rpc = { method : "albums.get" };
> ...
>
> On the server/PHP side I've added code to the 'ApiServlet' class to handle
> the requests coming in on the new RPC topic, similar to how the other
> handlers are added.
>
> Now my question is if this is the best way to extend Shindig/PHP? Or is it
> possible to do this without having to change the 'ApiServlet' class?
>
> Thanks,
> Erik