Trace:
Differences ¶
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
| en:tutorial:action-creation [2006/09/22 15:03] – doubleface | en:tutorial:action-creation [2007/09/16 06:39] – laurent | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Creation of an action ====== | ||
| - | ===== A little bit of theory ===== | ||
| - | |||
| - | An action is a fundamental element of the framework. Every display, every form processing, every web service call is an action. | ||
| - | |||
| - | An action is called through a request which has a defined type and generates a specific response, in a specific format, which can be linked to the type of the actual request. | ||
| - | |||
| - | There are several types of requests, notably the type which is named “classic” in Jelix , for which an action can provide a response in an unspecified format: HTML, XML etc. It is for this type of request that you will generally define actions. In general, this type of request provides its parameters in the URL or the body of HTTP request (POST method). | ||
| - | |||
| - | You also have the xmlrpc type requests (used in web services). In XML-RPC, the input data are not URL parameters, but are stored in a XML content. As XML-RPC protocol wants it, an action defined for this type of request must obligatorily provide a response to XML-RPC format. | ||
| - | |||
| - | Knowing the type of request processed and the action, Jelix knows the type of the answer to be generated, and thus controls more or less the response generation. Thus, even the error case (an exception or other) occurring during the processing of the action, the exit format will always be the awaited one. A client who calls a web service with xmlrpc, will thus have no matter what happens, a response in the xmlrpc format. That brings a certain robustness to the application. | ||
