Live server is an inbuilt server that runs on javascript language and helps to enable live php development, an environment in which the PHP is rendered on a live state. In order to keep live server efficient, the live server runs at the top of the application before any content is rendered when it is pre-enabled in top level core configuration file or when it is manually called called in routes. However, in template files, the live server script is imported at the point of call through the use of a live server template directive that will be discussed later.
Helper classes, functions and features have been restructured and integerated into this framework to support live development state within a specified range of support. For example, an error notification system was attached to php error handlers to convert php errors into an error pop-up notification message to reduce what is known as a "KILL EFFECT" which occurs when live server terminates and may not be able to continue unless the page is refreshed or the error is fixed before refreshing the page.
Certain PHP errors prevents the live server from running because they shut down the entire application. In order to reduce the effect of these errors, the liveserver will continue to run with a relative error pop-up notification message until the page is manually refreshed. Once the page is refreshed while such errors are active, the live server will not be able to restart until such errors are fixed and the page is refreshed to reboot the liveserver. In the cases where soft errors (e.g warning and notice errors) occurs, the liveserver will still try to reboot to keep the application on a live state and any error detected will be converted to a pop-up notification message.
Although, the live server may prove helpful, due to the comprehensive structure which php uses to handle its errors, spoova live server debug system is still known to have some minor issues. The live server implements different resource management approach to reduce its effect on cpu performance. One of these is the internal behavioral pattern of pausing watch mode for web pages that are not in view. Another feature and improvement added over time is the introduction of live server options that gives more controls over how the live server is expected to be used by the developer, giving the developer more controls over resource management. Although, the Live server was built to support majorly offline development, it is disabled by default and can be initialized or turned off through different ways which are further explained below:
Resource class. Once the basic core static files
are loaded, the live server script will be loaded immediately so that developer can start to work on a live state mode. This mode
requires activation through the command-line by running the command below :
> php mi watch online
> php mi watch offline
> php mi watch disable
icore/init
file by setting "RESOURCE_WATCH" key to a default value of "1" or "2" which stands for
offline or online respectively while a default of "0"
disables the live server. These values should be defined without quotes. Although, setting up live server this
way may sound easy, it is not the most efficient way to start the live server unless a template file cannot be reached.
Template files are preferred and recommended for starting the live server. Resource class to load the live server through an embedded format which is added directly
to the header of the page. There are two ways in which the live server can be imported in this format. The first method is shown below:
<?= Res::import("::watch") ?>
<?= Res::live() ?>
icore/init
file by setting "RESOURCE_WATCH" key to a default value of "1" or "2" which stands for
offline or online respectively while a default of "2"
disables the live server. These values should be defined without quotes. Although, setting up live server this
way may sound easy, it is not the most efficient way to start the live server unless a template file cannot be reached.
Template files are preferred and recommended for starting the live server.
@live
@live()
@Res('::watch')
Route files and we don't have access to the template
files. The monitor() function can help to quickly load the live server script from any route file once
the relative webpage is visited even if no template is loaded. An example is shown below:
<?php
class Home extend Window {
function __construct() {
self::call($this, 'home');
}
function home() {
monitor();
}
}
home webpage is visited, the live server will be loaded.
This is useful for perfoming a quick code test.
<!DOCTYPE html>
<html lang="en">
<head>
@live
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
@yield()
</body>
</html>
@template('main')
//child html here...
@template;
index will inherit the live server from its parent template main.
The flexibility of the live server also makes it easy to turn off the live server for any child template even if it was turned on from a
parent template. This behaviour makes it easier to manage the live server from a single parent file which every other children template will inherit from
without any form of difficulty. The sample below is how we can turn off the live server for the child template file.
@template('main:off')
//child html here...
@template;
Res::off(). An example of this is shown below:
<?php
use Routes;
class Home extends Routes {
function __construct(){
Res::off(); //switch off live server
self::load('template', fn() => compile());
}
}