Difference between revisions of "LiteCommerce:Request dispatcher"

From X-Cart 4 Classic
Jump to: navigation, search
(Created page with 'All requests to the LiteCommerce-based site come through either cart.php or admin.php scripts, for the customer and admin zones respectively. Thus the common LiteCommerceURL look…')
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
All requests to the LiteCommerce-based site come through either cart.php or admin.php scripts, for the customer and admin zones respectively. Thus the common LiteCommerceURL looks like http://website/dir/cart.php?target=<dialog>&<dialog-specific parameters>...} (or admin.php for admin zone). The target parameter specifies the dialog to display. This technique is also known as request dispatching. The benefits of using a dispatcher instead of individual php scripts for each page are the following:
+
All requests to the LiteCommerce-based site come through either <u>cart.php</u> or <u>admin.php</u> scripts, for the customer and admin zones respectively. Thus the common LiteCommerceURL looks like
 +
'''<nowiki>http://website/dir/cart.php?target=&lt;dialog&gt;&lt;dialog-specific parameters&gt;...</nowiki>''' (or admin.php for admin zone). The target parameter specifies the dialog to display. This technique is also known as request dispatching. The benefits of using a dispatcher instead of individual php scripts for each page are the following:
  
 
# dispatcher lets you avoid confusion with callable PHP scripts. In the web-sites with separate php scripts PHP files are divided into two categories: PHP scripts callable from the web browser and included PHP files. This creates confusion and mistakes when you are trying to include a functionality located in a PHP script from another PHP script, because only one PHP script may be run at one session. In LiteCommerce, all PHP files are included, except cart.php and admin.php.
 
# dispatcher lets you avoid confusion with callable PHP scripts. In the web-sites with separate php scripts PHP files are divided into two categories: PHP scripts callable from the web browser and included PHP files. This creates confusion and mistakes when you are trying to include a functionality located in a PHP script from another PHP script, because only one PHP script may be run at one session. In LiteCommerce, all PHP files are included, except cart.php and admin.php.

Latest revision as of 16:28, 5 February 2010

All requests to the LiteCommerce-based site come through either cart.php or admin.php scripts, for the customer and admin zones respectively. Thus the common LiteCommerceURL looks like http://website/dir/cart.php?target=<dialog><dialog-specific parameters>... (or admin.php for admin zone). The target parameter specifies the dialog to display. This technique is also known as request dispatching. The benefits of using a dispatcher instead of individual php scripts for each page are the following:

  1. dispatcher lets you avoid confusion with callable PHP scripts. In the web-sites with separate php scripts PHP files are divided into two categories: PHP scripts callable from the web browser and included PHP files. This creates confusion and mistakes when you are trying to include a functionality located in a PHP script from another PHP script, because only one PHP script may be run at one session. In LiteCommerce, all PHP files are included, except cart.php and admin.php.
  2. dispatcher is more secure: in LiteCommerce calling included PHP files as PHP scripts will produce nothing, because all they do is define PHP classes. All the functionality is located in the included files and is only accessible thru cart.php and admin.phop, as nothing happened when calling included PHPs. Moreover, it is easier to maintain security issues when you have only two callable scripts.
  3. dispatcher is more flexibile: you can add an action to all the requests, like locking your shop.

A dialog in LiteCommerce is a class responsible for processing a request and displaying the dialog page. The class naming convention is Dialog_{target}, where target is a target request parameter, passed either in GET or POST data. A dialog must extend the base Dialog (or Admin_Dialog for admin zone targets) class.

A dialog can have zero or more actions. An action} is a dialog method that is responsible for processing a certain action of the dialog, e.g. form submits. The optional request parameter action is used to locate the appropriate method, which must be named action_{action} and perform the appropriate task. On success, LiteCommerce will redirect the user to the dialog page, to avoid repeating the action by reloading the page. The common control flow of a dialog is shown below.

Figure 3.1 The common control flow of a LiteCommerce dialog

Embim3.png