Controllers in Venddor IO

Understanding Pre- and Post-Controllers

The fundamental structure of Venddor IO's operation hinges on initiating one of its primary executable PHP files, either admin.php or index.php. Following the initiation, a sequence of PHP files responsible for the platform's functionality is executed.

1. Either index.php or admin.php -> 2. init.php -> 3. [controller_name].php

In Venddor IO's lexicon, the third file in this chain is termed a 'controller'. This controller handles data within the software, managing tasks such as extracting requisite information from the database, processing and calculating data, and setting up the data for subsequent display.

Controller Routing and Location

The route and identity of the controller are autonomously determined by the platform, relying on the 'dispatch' parameter relayed to the main executable file. This 'dispatch' parameter is structured as [controller_name].[mode_name], with the [controller_name] denoting the controller's name, and [mode_name] specifying the mode the controller will operate in. The resultant file is named [controller_name].php.

Controllers overseeing the admin panel (utilising the admin.php) reside in the app/controllers/backend directory, while those meant for the customer section (utilising index.php) are housed in the app/controllers/frontend directory. If the designated controller isn't located in these specific directories, the system attempts to initiate it from app/controllers/common. This is structured to accommodate scenarios where a singular controller caters to both customer and administrator interfaces, delivering identical functionalities for both.

Controller Execution Process

The actual connection of the controller is orchestrated by the function in [/app/functions/fn.control.php]/fn_dispatch(). This function:

• Verifies the validity of the 'dispatch' parameter.
• Assesses the current user's permissions for the specified controller.
• When required, redirects to a secure protocol (HTTPS).
• Curates an orderly list of pre controllers and postcontrollers (sourced from both modules and the core) for systematic, sequential connection.
• Determines the display template autonomously.

Breaking Down Venddor IO Controllers

When navigating Venddor IO, you might come across a URL structure similar to this:

http://venddor_io_dir/admin.php?dispatch=products.manage

Given the dispatch parameter's value as products.manage and considering the admin.php file is being executed, the controller's path translates to /controllers/backend/products.php. Within this file, the 'manage' parameter dictates the series of actions the controller undertakes. Specifically, in this scenario, 'manage' signifies that the controller should retrieve a product list from the database and subsequently present it within the admin interface.

Controller Structure Blueprint

Venddor IO controllers are typically structured with the following segments:

• Handling POST requests.
• Addressing GET requests.
• Defining local functions, exclusive to that controller.

To determine the mode of operation for processing a GET request, Venddor IO uses the [mode_name] segment of the dispatch parameter.

POST Requests Handling

POST request handling is prioritised before GET request processing. Every POST block typically concludes with a command that reverts control from the controller to the fn_dispatch() function:

return array(CONTROLLER_STATUS_OK, "$index_script?dispatch=controller_name$suffix");

Here, the CONTROLLER_STATUS_OK parameter represents a successful status post-controller execution, while the succeeding parameter dictates the redirection path post-POST request processing.

if ($mode == 'add') {
    // This section would be dedicated to actions following the product addition form submission
}
return array(CONTROLLER_STATUS_OK, "$index_script?dispatch=products$suffix");

GET Requests Processing

The segment handling GET requests is systematically positioned after the POST block.

if ($mode == 'manage') {
   // This code runs when the URL is "http://venddor_io_dir/admin.php?dispatch=products.manage"
}

The given code snippet inspects the mode parameter's value (dispatch=controller.mode) and executes the embedded code when the value corresponds to 'manage'. This action is triggered during a GET request.

Concluding a GET mode operation, controllers typically:

1. Hand over control to the display system or template.
2. Redirect using the GET method.
3. Terminate both the controller's and program's execution without further action, using the exit command.

By default, unless explicitly directed to the latter two actions, control shifts to the fn_dispatch() function. To pass data to the template for visualisation, a specific structure is employed.

Function Mechanism in Controllers

In the Venddor IO architecture, controllers play a pivotal role in navigating and processing data. A controller's primary role is to handle user requests, manipulate data, and decide the appropriate view to render.

A controller's functions adhere to standard function structuring protocols. When there's a need to invoke a controller function elsewhere, it's best to place this function either in the core program or within a module.

Data Accessibility in Controllers

For data manipulation within a controller, Venddor IO offers standard data arrays:

• $_REQUEST: This consolidates all incoming data from GET and POST requests. It undergoes specific treatments like stripping out HTML tags and eliminating automatically added PHP slashes.
• $_SESSION: This is the conventional PHP array storing session-related data.
• Registry: This unique static class acts as a storage for data that should be universally accessible. Configuration parameters read during initiation are stored here. Notably, the data stored can be cached, reducing database queries for infrequently updated information.

Transferring Control to Templater

Post controller execution, control transitions back to fn_dispatch(), which subsequently redirects it to the templater. The default path to the desired template is automatically determined:

• Admin Interface: /backend/templates/views/[controller_name]/[mode_name].tpl
• User Interface: /themes/[theme name]/templates/views/[controller_name]/[mode_name].tpl

For instance, with the URL as http://venddor_io_dir/admin.php?dispatch=products.manage, the corresponding template path would be /backend/templates/views/products/manage.tpl.

Controller Execution via Console

• Admin Console Command: php /path/to/venddor_io/admin.php --dispatch=controller.mode
• User Console Command: php /path/to/venddor_io/index.php --dispatch=controller.mode
• Universal Command (for common controllers): Either of the above commands suffice.

Parameters can be provided as follows:

php admin.php --dispatch=controller.mode --param1=value --param2=value --param3[]=value1 --param3[]=value2 --param4[param5]=value

Such parameters reach the controller as regular request parameters, accessible via the $_REQUEST array. For modes addressing POST requests, include the -p argument post parameter specification.