Difference between revisions of "Xml-rpc changes in Joomla!"
From Joomla! Documentation
(New page: === XML-RPC changes in J1.6 === 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 <louis.landry@jooml...) |
m (Wilsonge moved page Xml-rpc changes in Joomla! 2.5 to J2.5:Xml-rpc changes in Joomla!: Move to 2.5 namespace) |
||
(11 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
− | === XML-RPC changes in | + | {{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. | ||
− | On Wed, Apr 8, 2009 at 10:43 AM, Louis Landry | + | 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. | 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. | ||
Line 8: | Line 10: | ||
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: | 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/ | + | <pre>/components/com_foo/ |
/components/com_foo/controllers/c1.php | /components/com_foo/controllers/c1.php | ||
/components/com_foo/controllers/c2.php | /components/com_foo/controllers/c2.php | ||
Line 18: | Line 20: | ||
... | ... | ||
/components/com_foo/controller.php | /components/com_foo/controller.php | ||
− | /components/com_foo/foo.php | + | /components/com_foo/foo.php</pre> |
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. | 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 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. | ||
− | + | <pre>/components/com_foo/ | |
− | |||
− | |||
− | /components/com_foo/ | ||
/components/com_foo/controllers/c1.php | /components/com_foo/controllers/c1.php | ||
/components/com_foo/controllers/c1.xmlrpc.php | /components/com_foo/controllers/c1.xmlrpc.php | ||
Line 41: | Line 40: | ||
... | ... | ||
/components/com_foo/controller.php | /components/com_foo/controller.php | ||
− | /components/com_foo/foo.php | + | /components/com_foo/foo.php</pre> |
− | |||
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. | ||
− | + | <source lang="php"> | |
class FooControllerC1 extends JController | class FooControllerC1 extends JController | ||
{ | { | ||
Line 56: | Line 54: | ||
// Exit the application. | // Exit the application. | ||
} | } | ||
− | } | + | }</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: | ||
− | + | <source lang="php"> | |
class FooControllerC1 extends JController | class FooControllerC1 extends JController | ||
{ | { | ||
Line 81: | Line 78: | ||
} | } | ||
− | } | + | }</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. | ||
− | + | <source lang="php"> | |
class FooControllerC1 extends JController | class FooControllerC1 extends JController | ||
{ | { | ||
Line 96: | Line 92: | ||
// Exit the application. | // Exit the application. | ||
} | } | ||
− | } | + | }</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 104: | 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}&format={SERVICE_TYPE}</pre> | |
− | index.php?option=com_foo&task={CONTROLLER}.{TASK}& | ||
− | |||
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&format=xmlrpc </pre> | |
− | index.php?option=com_foo&task=c1.bar& | ||
− | |||
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&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 &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. | 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. | ||
Line 132: | Line 123: | ||
Louis | Louis | ||
+ | ====Example component==== | ||
+ | Example component created to test XML-RPC web services: [http://help.joomla.org/files/xmlrpctest.zip] (Thanks [[User:Aduran]]) | ||
− | + | <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)