The core elements

So, why the core code of SKY. has a form presented here? Is it good or bad? Only time can give the correct answer to this question. The lifetime of the SKY. project once a considerable number of programmers will get acquainted with it, and your personal time, dear reader, which you will give to the SKY. project and analyze yourself everything it has. In the project we are putting and will put every effort and means to make this code ideal! Let's begin from the beginning: should the ideal code be simple enough for the overwhelming majority of Web developers to easily take advantage of it with little or no reading documentation and still being very effective; is it possible? The answer to both questions: Yes! Simple code is the first and most important rule in SKY. Moreover, there can be only one perfect code, a priori, and we are looking for it in the SKY. project.

Reflections when creating the core code are as follows: we will need a reusable code (1 file - main/sky.php), which you can always run, from any point of entry. It will initiate a connection to the main database, will include a wrapper function sql() to make requests to the database. All requests going through this function will automatically get into the trace buffer. We need a trace function and our own error handler, which will request a trace function with the option "show error". We need a class of SKY. that will contain the data register, configuration data memory, as well as other useful features. Let's call file main/sky.php the first wing file, as it will be run for all entry points.

For the front-end and admin entry points we will create the file main/wings.php, it will contain a standard reusable code for user sessions, user registration, and any other code. This is the code of the second wing, as it is used in more than one entry points.

We will also create a file main/front.php, this file will be used only for a single point of entry - front, so, this is the code of the third wing, as the code in the main/cron.php file - to run from the entry point cron.


Queries to the admin section:

where /adm specifies the access to the admin section, a page indicates the executable file in the admin folder, i.e. admin/_page.php, in the file .htaccess the query is redirected to the index.php file. From this file, the admin router is activated - admin/index.php. Queries to the front section:

Thus, if we assume that general addressing (the most flexible) includes: the protocol, the domain name, the folder address, the file and QS (query string, keys with values, for example,?qq=ww&rr=tt), then the main system of addressing of SKY. applications prohibits the use of "folder address" part (the the use of symbol of folders demarcation "/") that allows you to use relative addressing to images and other addresses in view-files. It greatly simplifies the coding of queries, the size of the generated HTML file. Also it becomes possible not to create a separate virtual server for each project, but to create new projects just in the folder of the same virtual server on a developer's workstation (all SKY. applications must remain operable when placing them in a folder of the virtual server). For example,


Let us note, just for the fun of it, that constant PATH (see the file main/wings.php) in the given example will contain /project3/.

In SKY. we introduced abstract variables PAGE, PVAL, WHAT, WVAL that correspond to the parts of a query - the first key and a value, and also the second. The first variable identifies the respective page that corresponds to the file-processor or controller (for MVC).


Usually to execute an ajax query, you need to do a lot of formal actions, so in order not to do them (to make it easy) in SKY. we introduced a function ajax (..) in the file pub/wings.js. When you use it, you do not need to write the address of the file handler, as it provides a part of the current page address (retrieves it from document.location.href), i.e. (in the case of MVC) a query goes to "your" controller, and only a pseudo name of the handler method is indicated. The function has also pre-defined the use of the POST method, as much more often AJAX functionality requires the absence of browser-caching. Besides, the address generated for the real access to the server includes a standard part for this functionality - AJAX key: (pval - controller method for MVC) (ajax query to the admin section) (plain, not ajax query to the the admin section is run by MOD_REWRITE)

that sets the PHP constant of AJAX at non-zero value, i.e. already in the reusable code of the first wing there is information on the standard AJAX query that allows, for example, to automatically disable LAYOUT for this query, and write the trace data into the database (and not to make output into STDOUT).


PHP "echo 'z';" code puts conditionally one byte of "z" in the browser, but in really, it practically never happens, but instead, there is a record to the system buffer and only after reaching the "right portion" of the data the real data transfer happens across the network. STDOUT buffering is the fundamental mechanism for significant performance improvement when transmitting data over the network and normal functioning of all computers and network devices. The logics of buffering is as follows: the packets in the network have a part of proprietary information and a part of useful information, and network performance can be practically achieved when the quantity of useful information goes beyond the informational part (HEADER) in a certain number of times, that is the packet is not small (in order not to transmit a large number of headers) but it is not big either (to send information from one side to the receiver as quickly as possible, on the one hand, and on the other hand, - to make it easier to fix faulty packets of not very large volume). On the other hand, when transmitting very large pages, you need to save a server memory, and for each client (which is connected in parallel) a small volume of memory can be allocated, compared to the volume of the whole page transmitted to him. Thus, the fundamental logics of building modern networks determines the need for buffers for different protocols of the higher level, for example HTTP. Moreover, we need to emphasize that this function is associated with the hardware parts of the networks, which existance is potentially more stable than the existence of any software. Thus, we can consider buffering to be a de facto functional, which cannot be doubted.

The existence of STDOUT buffering de facto allows you to create an additional "delicious" functional of tags. Delicious is when significant system resources allocated for one purpose, can be used simultaneously for another purpose without additional significant resources. Tags is something that you have to find and replace with something different. It is for example the whole text of the HTML page, which is compressed to a smaller size with compression modules; this is conversion of all national symbols of the HTML page into a different encoding, or replacement of the tag-identifier used in SKY. with the corresponding HTML image.

Tags can be divided into the pending values, service and functional. The use of the buffer for page compression and encoding change - this more shows functionality of the tags. Examples of tags in SKY: pending - imagine that we have a tag %ERROR%, which is defined on all pages on top in the center of the page (to make it easier to see), and if PHP did not find errors in the code, then it is replaced with an empty line, but if if found, - then at the very end of the script (to collect as many errors as possible) the tag %ERROR% gets a visual presentation of errors in the most convenient form. service - tags can represent with one identifier, for example %PHP_NEWS%, some HTML data block, wich may contain tags inside (recursion). And rearranging a tag into different parts of the pages, you can easily implement complex forms of the units display on the site. Such tags provide service convenience. functional - for example %HTML_X_COUNTERS%, as here the tag is prefixed with _X_, then on the developer's computer (when constant DEV is not zero), instead of displaying javascript code of the counters that trigger the scripts on external resources in the Internet, it shows just DIV with the attribute class="red_label" and the tag name. It allows a developer without any complexities and special actions to develop the site OFFLINE without the Internet.

Tags also let you implement a functional of "tight" caching, which can improve the code effeciency. For example, consider this code:

...some HTML before
<?cache('right_col')?> <!-- BEGIN CACHE AREA -->
<?cache()?>            <!-- END CACHE AREA -->
...some HTML after

In this example, the tag %PHP_RIGHT% (recognized with regular expression) triggers the PHP code of the tag to get the display. If the tag % PHP_RIGHT% generates the content of the right column of the site and instant relevance of its display is not of immediate interest (as it happens quite often), then this content may be cached and updated only once every 5 minutes, for example. Fully generated right column is recorded into the file cache/right_col.html. During the execution of the function cache ('right_col'), it is checked: if the above file is fresh, then the PHP code of the tag is not run at all, and the display is taken from the cache file. Such caching might disable the execution of several SQL queries and PHP code that generates the content of the right column in general, and significantly improve the efficiency of the site code. In this case, the tag, in addition to the service value also gets a functional one.

Negative points of tags functional: First of all, you must not forget to convert the data received from the site users and your own data containing a percent sign % (which may be interpreted as a frame of a tag) into equivalent HTML entities - %, otherwise there could be an attack linked to the generation of unnecessary tags or there may be your own errors associated with this, that is why the code of the first and second wings have the appropriate corrections, see. for example, the code main/sky.php, function html(..).

Secondly, unfortunately, in PHP, a functional related to the operation of STDOUT buffers is extremely poorly implemented and confused. Instead of multiple functions of the family ob_.. ob_get_clean, ob_end_flush, etc, it was necessary to make one function ob_action with keys-constants OB_FLUSH, OB_GET, OB_CLEAN, OB_END, as well as OB_REPLACE (replacement of the buffer contents without the fact of resetting or emptying), OB_CALLBACK - indication of whether to call the callback function and a conditional resetting, emptying, etc.. For example, when reaching 4096 bytes for resetting, the callback function is invoked and it is validated whether all tags pending values are calculated (the other types can be calculated at the current stage). If "Yes", then a network packet is sent to the browser. If "No" - buffering continues. This would make it possible to use 100% computer power in this aspect. It is also necessary for the first level of buffering to be virtual, i.e., on the first call to ob_start() function the system buffer must be used, and the memory would not be allocated specifically for it, and in the callback function the buffer would be passed by the reference.


Let's consider the possible types of multilingual applications.


The genius of the MVC pattern is evident in its simplest form.


There is an idea to create "black boxes" in SKY. applications. What is it and what is their purpose? Well, first of all, this is a reusable code that will be stored in the cells of the applications database, which will be packed (removed whitespace) to improve performance. Such code will not "loom" in the file system with an application code and facilitate understanding of the structure of the application to a programmer. And such code will be executed by eval(sql("+"select ...")); or a special function. In addition there is a factor contributing to the creation of the "black boxes" due to the fact that there are many examples of a reusable code that must be in your application, but it is unwanted to be seen in the file system at the stage of an application development for programmers. For example, such as a code that analyzes what type of device referred to the site - a mobile device with a limited screen or a workstation witha "big" monitor. The code in this example contains a lot of comparisons of a user-agent query (or/and other variables) for certain signatures in a certain sequence and was created once through painstaking work (or regenerated automatically by special algorithm). It is not advisable for a programmer to see it in the current project, i.e. it was decided by the programmer to use the code "as it is," without any further of its improvements. Of course, the use of the executable code stored in a database creates additional risks in terms of security, but this technology can be used only (a separate topic for discussion) in the DEBUG mode on a developer's workstation! Programmers can decide themselves what code to send to the black box, and before unloading the project code for "production" into an aggressive network - to remove the black boxes (and the whole system of them) using a special utility of application DEV.SKY. To organize this process you can come up with a formal scheme, algorithm that will be a part of the DEV.SKY. The black boxes can also be stored in a Codebase on SKY. server (under the condition you trust the code on the server), that will indicate that this code has the property of potentially poor attention to the code in terms of its improvement due to certain reasons. Despite the "closeness" of the code, the code can be viewed and changed in the DEV.SKY. application.


In connection with the global spread of mobile devices nowadays there is a need to adapt the sites quickly for mobile versions. width = "100%"


If folders with files of Web application must not be made available to the Web server (for example, the folder main), but be in "open zone", usually in such a folder the .htaccess file (for apache Web server) will be written down with the content: deny from all - that prevents access to the folder with the means of the Web server, and in some way guarantees security from outside access. The production of such files does not bear any semantic code for the applications operability, and is purely a means of security. In general, on the basis of abstract logic, it makes sense (and it is implemented in SKY. applications) to make the INIT and RESET functions, and put the code in the file main/debug.php. This function (and the entire file) is connected only in the mode of DEBUG application, that is, only when the DEBUG constant has a non-zero value in the file main/conf.php, when the application is in debug mode, and thus almost always only on a developer's workstation, and on the production it will not create any additional computational costs. The INIT function is always run only one time in life, after the installation of any application (Codebase recordы with a prefix a:, for example, a:lite.sns. For RESET function there is a button in the admin section of any application (which has admin section). The file admin/_main.php is used in the admin section in all applications. It is reasonable to create files described above (.htaccess) via the INIT function not to "clog" the code of creation of an application in Codebase record with such formal actions. Similar to this logic there is another function, in the abstract sence, which is attributed to the standard function of INIT and RESET applications of SKY.