J2.5

Difference between revisions of "Xml-rpc changes in Joomla!"

From Joomla! Documentation

m (Xml-rpc moved to Xml-rpc changes in Joomla! 1.6: more descriptive. Old title was obcenely deceptive.)
m (Wilsonge moved page Xml-rpc changes in Joomla! 2.5 to J2.5:Xml-rpc changes in Joomla!: Move to 2.5 namespace)
 
(8 intermediate revisions by 5 users not shown)
Line 1: Line 1:
=== XML-RPC changes in J1.6 ===
+
{{version/tutor|2.5,3.1}}
 +
 
 +
=== XML-RPC changes in J2.5 ===
 
This is a copy of the message send to the Google Groups "Joomla! CMS Development" group.  
 
This is a copy of the message send to the Google Groups "Joomla! CMS Development" group.  
  
Line 24: Line 26:
 
In 1.5, you would need to have some logic in your base foo.php to determine which controller gets included and executed based on some request variables, etc.
 
In 1.5, you would need to have some logic in your base foo.php to determine which controller gets included and executed based on some request variables, etc.
  
In 1.6, there is a new convention based way of achieving this behavior as well as adding in service requests.
+
In 2.5, there is a new convention based way of achieving this behavior as well as adding in service requests.
  
 
<pre>/components/com_foo/
 
<pre>/components/com_foo/
Line 42: Line 44:
 
If you have a look at this version of the com_foo component, you will notice a couple of extra files.  In the controllers folder you now have c1.xmlrpc.php and c1.json.php.  These controllers are where the logic to handle service calls to the c1 controller tasks would live.  Lets assume that the controller class in c1.php has only one method/task, bar.
 
If you have a look at this version of the com_foo component, you will notice a couple of extra files.  In the controllers folder you now have c1.xmlrpc.php and c1.json.php.  These controllers are where the logic to handle service calls to the c1 controller tasks would live.  Lets assume that the controller class in c1.php has only one method/task, bar.
  
<pre>class FooControllerC1 extends JController
+
<source lang="php">
 +
class FooControllerC1 extends JController
 
{
 
{
 
     function bar()
 
     function bar()
Line 51: Line 54:
 
         // Exit the application.
 
         // Exit the application.
 
     }
 
     }
}</pre>
+
}</source>
  
 
If you wanted to allow an XMLRPC service request for this controller, you would simply create c1.xmlrpc.php as shown in the second folder structure and define the methods/tasks that you want to handle:
 
If you wanted to allow an XMLRPC service request for this controller, you would simply create c1.xmlrpc.php as shown in the second folder structure and define the methods/tasks that you want to handle:
  
<pre>class FooControllerC1 extends JController
+
<source lang="php">
 +
class FooControllerC1 extends JController
 
{
 
{
 
     function bar()
 
     function bar()
Line 74: Line 78:
 
     }
 
     }
  
}</pre>
+
}</source>
  
 
You will also notice in the second folder structure, that there is a c1.json.php.  As you can imagine, this class is pretty straightforward as well.
 
You will also notice in the second folder structure, that there is a c1.json.php.  As you can imagine, this class is pretty straightforward as well.
  
<pre>class FooControllerC1 extends JController
+
<source lang="php">
 +
class FooControllerC1 extends JController
 
{
 
{
 
     function bar()
 
     function bar()
Line 87: Line 92:
 
         // Exit the application.
 
         // Exit the application.
 
     }
 
     }
}</pre>
+
}</source>
  
 
As you can see, controllers can be built up to handle as many different types of service requests as you want for whatever types of tasks you want, within your standard component folders.  It would also be trivial to turn services on/off with simple conditional statements and component configuration settings.
 
As you can see, controllers can be built up to handle as many different types of service requests as you want for whatever types of tasks you want, within your standard component folders.  It would also be trivial to turn services on/off with simple conditional statements and component configuration settings.
Line 94: Line 99:
 
The standard way of requesting these various controllers/methods by convention is something like:
 
The standard way of requesting these various controllers/methods by convention is something like:
  
<pre>  index.php?option=com_foo&task={CONTROLLER}.{TASK}&protocol={SERVICE_TYPE}</pre>
+
<pre>  index.php?option=com_foo&task={CONTROLLER}.{TASK}&format={SERVICE_TYPE}</pre>
  
 
So, if we wanted to send a request to the bar method in controller c1 via XMLRPC the URL to use would simply be:
 
So, if we wanted to send a request to the bar method in controller c1 via XMLRPC the URL to use would simply be:
  
<pre>    index.php?option=com_foo&task=c1.bar&protocol=xmlrpc </pre>
+
<pre>    index.php?option=com_foo&task=c1.bar&format=xmlrpc </pre>
  
 
Similarly if we want the JSON service protocol:
 
Similarly if we want the JSON service protocol:
  
<pre>    index.php?option=com_foo&task=c1.bar&protocol=json </pre>
+
<pre>    index.php?option=com_foo&task=c1.bar&format=json </pre>
 +
 
 +
If your site is using multi-language support, add the language code to the URL or you will not be able to read the post raw data from (http://input):
 +
 
 +
<pre>    index.php/en?option=com_foo&task=c1.bar&format=xmlrpc </pre>
  
Just to use the base c1.php controller you remove the &protocol={SERVICE_TYPE} variable from the request URL.
+
Just to use the base c1.php controller you remove the &format={SERVICE_TYPE} variable from the request URL.
  
In Joomla 1.6, JController has a new getInstance() method that handles this dispatching of the correct controllers for you based on the request variables.
+
In Joomla 2.5, JController has a new getInstance() method that handles this dispatching of the correct controllers for you based on the request variables.
  
 
We most certainly are not getting rid of the ability to utilize XMLRPC in your components, we are simply trying to make it more consistent and cohesive with the rest of the system.
 
We most certainly are not getting rid of the ability to utilize XMLRPC in your components, we are simply trying to make it more consistent and cohesive with the rest of the system.
 +
  
 
Hope that helps,
 
Hope that helps,
 
Louis
 
Louis
  
On Tue, Apr 7, 2009 at 3:06 AM, Hans wrote:
+
====Example component====
 +
Example component created to test XML-RPC web services: [http://help.joomla.org/files/xmlrpctest.zip] (Thanks [[User:Aduran]])
  
On 23 januari '09 XMLRPC was partly removed from the 1.6 trunk by Anthony and Louis. The map /xmlrp and its contents were removed but the xmlrpc library is still present in /libraries/phpxmlrpc.
 
 
I haven't come across statements about changing XMLRPC support for J1.6. In any case it isn't mentioned in "revisiting the J1.6 roadmap". Have I missed something?
 
 
Would someone please be so kind to inform me and the world about the status of XMLRPC support in J1.6.
 
 
<noinclude>[[Category:Development]]</noinclude>
 
<noinclude>[[Category:Development]]</noinclude>

Latest revision as of 19:41, 4 July 2013

The "J2.5" namespace is a namespace scheduled to be archived. This page contains information for a Joomla! version which is no longer supported. It exists only as a historical reference, it will not be improved and its content may be incomplete and/or contain broken links.

XML-RPC changes in J2.5[edit]

This is a copy of the message send to the Google Groups "Joomla! CMS Development" group.

On Wed, Apr 8, 2009 at 10:43 AM, Louis Landry wrote:

What we have done is to remove the separate XMLRPC application from the trunk and made way for a new method of handling service requests. It is no longer necessary to have an XMLRPC plugin group to handle XMLRPC requests that end up proxying the logic and data structures within a component anyway.

In your component, we'll say com_foo, designed using the MVC pattern you may have a need to handle lots of "task-based" requests. Things like edit, save, delete, etc. Often, when this happens it is helpful to use more than one controller to break out code sections to smaller, more maintainable parts. Doing this you might have the following structure:

/components/com_foo/
/components/com_foo/controllers/c1.php
/components/com_foo/controllers/c2.php

/components/com_foo/models/

...
/components/com_foo/views/
...
/components/com_foo/controller.php
/components/com_foo/foo.php

This allows you to segment out grouped tasks into separate controllers. In this example you can see that there is a c1.php controller and a c2.php controller.

In 1.5, you would need to have some logic in your base foo.php to determine which controller gets included and executed based on some request variables, etc.

In 2.5, there is a new convention based way of achieving this behavior as well as adding in service requests.

/components/com_foo/
/components/com_foo/controllers/c1.php
/components/com_foo/controllers/c1.xmlrpc.php
/components/com_foo/controllers/c1.json.php
/components/com_foo/controllers/c2.php

/components/com_foo/models/

...
/components/com_foo/views/
...
/components/com_foo/controller.php
/components/com_foo/foo.php

If you have a look at this version of the com_foo component, you will notice a couple of extra files. In the controllers folder you now have c1.xmlrpc.php and c1.json.php. These controllers are where the logic to handle service calls to the c1 controller tasks would live. Lets assume that the controller class in c1.php has only one method/task, bar.

class FooControllerC1 extends JController
{
    function bar()
    {
        echo 'Hello World';


        // Exit the application.
    }
}

If you wanted to allow an XMLRPC service request for this controller, you would simply create c1.xmlrpc.php as shown in the second folder structure and define the methods/tasks that you want to handle:

class FooControllerC1 extends JController
{
    function bar()
    {
        // Get an XMLRPC server object and de-serialize the request payload.


        // Run method logic.


        // Build XMLRPC response payload.


        // Output XMLRPC response payload.


        // Exit the application.
    }

}

You will also notice in the second folder structure, that there is a c1.json.php. As you can imagine, this class is pretty straightforward as well.

class FooControllerC1 extends JController
{
    function bar()
    {
        echo json_encode('Hello World');


        // Exit the application.
    }
}

As you can see, controllers can be built up to handle as many different types of service requests as you want for whatever types of tasks you want, within your standard component folders. It would also be trivial to turn services on/off with simple conditional statements and component configuration settings.


The standard way of requesting these various controllers/methods by convention is something like:

   index.php?option=com_foo&task={CONTROLLER}.{TASK}&format={SERVICE_TYPE}

So, if we wanted to send a request to the bar method in controller c1 via XMLRPC the URL to use would simply be:

    index.php?option=com_foo&task=c1.bar&format=xmlrpc 

Similarly if we want the JSON service protocol:

    index.php?option=com_foo&task=c1.bar&format=json 

If your site is using multi-language support, add the language code to the URL or you will not be able to read the post raw data from (http://input):

    index.php/en?option=com_foo&task=c1.bar&format=xmlrpc 

Just to use the base c1.php controller you remove the &format={SERVICE_TYPE} variable from the request URL.

In Joomla 2.5, JController has a new getInstance() method that handles this dispatching of the correct controllers for you based on the request variables.

We most certainly are not getting rid of the ability to utilize XMLRPC in your components, we are simply trying to make it more consistent and cohesive with the rest of the system.


Hope that helps, Louis

Example component[edit]

Example component created to test XML-RPC web services: [1] (Thanks User:Aduran)