[Solar-talk] Web Services

[Michael Caplan]

Hi Paul,
 
Thanks for the detailed outline on how to approach integrating web services.  I've worked through your scenario, which sounds pretty compelling for a RESTish implementation.  
 
However, for my needs one point of access is required (eg: http://example.com/index.php/xmlrpc/ <http://example.com/index.php/xmlrpc/docs/read/HomePage> ) where the actual RPC method request would map to the application and method (eg: RPC method request Tech.getUsers would map to application Tech and method Tech::rpcGetUsers). This proved to be pretty easy to implement with a new Solar app, and a sprinkling of Reflection.  I imagine one can take the same approach with SOAP with little difficulty.
 
Best,
 
Michael

________________________________

From: solar-talk-bounces at lists.solarphp.com on behalf of Paul M Jones
Sent: Mon 10/2/2006 10:53 AM
To: solar-talk at lists.solarphp.com
Subject: Re: [Solar-talk] Web Services



On Oct 2, 2006, at 7:31 AM, Michael Caplan wrote:

> Perhaps this is related to the thread from this weakened on nested 
> controllers, but I am looking for a way to integrate web services 
> (xml-rpc primarily) as an interface that is callable by 
> application.  Architecturally, I am wondering how I can best 
> leverage Solar to integrate this.  Anyone have any pointers?

With the disclaimer that I have not actually done this, I can think 
of one way offhand.

Add an actionXmlrpc() method to your page controllers, then use the 
_forward() method to perform the related actions, and finally switch 
to an XML-RPC view/layout combination instead of the web-browser 
combination.  This is sort of REST-ish, but I think the idea is 
applicable:

     public function actionXmlrpc()
     {
         // get all params passed into the method
         $params = func_get_args();

         // find the "real" action based on the first param
         $action = array_shift($params);

         // forward to the "real" action with remaining params
         $this->_forward($action, $params);

         // $this is now populated with all the data from the action.
         // reset the view and layout for xml-rpc output.
         $this->_view = "xmlrpc/" . $action;
         $this->_layout = "xmlrpc";

         // done!
     }

Given a "docs" controller and a "read" action like this URL indicates...

     http://example.com/index.php/docs/read/HomePage

... you would get the XML-RPC version with a URL like this:

     http://example.com/index.php/xmlrpc/docs/read/HomePage

With the above code example, you need View/xmlrpc/*.php for each 
action exposed via XML-RPC, and a Layouts/xmlrpc.php file for the 
layout wrapping the view.

Of course, this is a very naive example.  If you have XML-RPC usage 
in mind, probably best to either design your public properties for 
dual use (data-view and browser-page view), or create a special 
$xmlrpc property and populate it properly in each "normal" action, or 
have the actionXmlrpc() method look at all $this properties and 
format them properly, or some other technique that I haven't thought of.

Hope this begins to help; as I said, it's very much an off-the-cuff 
first pass at the problem.


--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.   <http://solarphp.com>

Savant: The simple, elegant, and powerful solution for
templates in PHP.   <http://phpsavant.com>


_______________________________________________
solar-talk mailing list
solar-talk at lists.solarphp.com
http://mail.killersoft.com/mailman/listinfo/solar-talk







E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message.

The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 7698 bytes
Desc: not available
Url : http://mail.killersoft.com/pipermail/solar-talk/attachments/20061006/d733696c/attachment.bin