Web applications

Building a free-form Web application from scratch (using a reusable SKY code) is performed as follows: SKY null-site code representing the "blank site" is taken as a basis. It is developed further on with the SKY. tools and of course through direct programming by a person. SKY null-site (the code of the first and second wing) is built with the following purposes: to provide maximum convenience for the programmer who makes a direct programming, as well as to provide for the maximum need in the code to solve all the core issues that arise when you build websites, but NOT TO carry the redundant code, which could reduce the performance of the system, would be large in size, could confuse the programmer. On the basis of such form, you can build about 80% of the sites currently existing in the Internet, which would have the same success that they have, but that would have been easier and more productive, faster if programmed using SKY. code in its basis. For the remaining 20% of sites we use the cloud modifications of the code of the first and second wing, which are performed by SKY. tools.

Any interactive site almost always requires administration and an administrative section. The administrative section of a site could potentially be executed together with the Frontend code, but it is often done in the form of a separate section (in many existing framework), it is a good practice, because almost for all sites:

  1. Seperation of the administrative section from Frontend potentially reduces the risk of unauthorized access (hacking))
  2. For the admin panel code, there is no need in special work on its design and its design can be the same for any site.
  3. There is a possibility to almost "complete" the admin panel with the needed reusable code that minimizes its programming.

In comparison to when the administrative section is performed on the Frontend, this scheme has the obvious intuitive and friendly advantage and you may reject its application in very rare cases when administration on Frontend is functionally important and the above described benefits logically disappear.


The SKY. entry points are globally functionally different sequences of the code execution. The main are: index admin and cron, and the name of the current entry point is always defined in constant START. There may be other points in applications, such as xml, which defines the way of the script "passing" XML data from the site, but 3 points listed above are the major ones and they are used practically in all cases. Ajax requests in SKY. are not shown with a separate entry point, as ajax requests can be in the admin area and on the Frontend, which is logically associated notion..


SKY. application are always developed on the local workstation of programmers and almost any SKY. application supports the uniqueness of the code execution on a PC of a programmer and on a "production", i.e. there ia a constant DEV, using which you can make branches in the code on the production and application development. For example, in the configuration file 2 accesses to the DB of "production" and a developer's PC are indicated at once. Of course, if the project is developed by more than one programmer, then this simple approach requires correction, but a unique setup of installation of the application on programmers' PC and on the "production" is not recommended in SKY. Copying of all files of the application code (including configuration) must not take the site to the "production" of the system, despite the fact that you can use versions control systems like GIT or SVN and know how to avoid the above problem with their help. The second example of using DEV constant: on your local PC you can disable the external click counters or banner ads or replace remote statistical fileswith the local ones to perform faster and easier debugging.

In SKY. applications there is always a "primary" configuration file `main/conf.php` where & nbsp; in which the initial configuration is performed: configuraing DEBUG, DEV constants and connection to DB. DEBUG constant enables debugging mode of the application. DEV constant can be defined as follows (if you have a working Windows PC and the server is a Unix-like system):

define('DEV', PHP_OS == 'WINNT');

PATH constant defines the location of the application root relatively to the root of the Web server, if the application is in the root of the Web server, has a value and and is determined for production and for local installation separately, like so: define('PATH', DEV ? '/forum/' : '/');

START constant is defined at the very top of the file that is executing code in the Web server (this is usually index.php). Primary configuration file has minimum settings and they involve mainly installation nuances. The bulk of the configuration settings in SKY. is stored in the database.


Clean null-site SKY. (not a cloud modification) has the following structure of directories which is located in the root of the Web server:


If necessary the directories class, cache, label, and others can be added. It is implied that all directories except for the root of the Web site and pub are closed for the Web. Despite the fact that in some framework it is recommend placing such directories above the root of the Web server, in SKY. it is not recommended, except for the sites to which there are increased security requirements. At present there are about 10% of such websites in the Internet and mostly these are the sites related to the financial (or other important) transactions, or those with the attendance of more than 100000 people per day. In this case, you need to use a cloud-based version of null-site.

In SKY. (for all public applications) you must build your applications code so that they can be placed in the Web root or a subdirectory (no difference), for example in the Web site root there is a primary site code and in the forum folder - FORUM.SKY.

In the 'admin' directory the admin files are stored, in the 'main' - the core files, the code of the first and second wing. The 'pub' folder stores pictures, style sheets files, and javascript files, including public libraries. The 'view' folder contains 'view' php files, but if the Web application script has more than one style sheet of the front-type site, then the "view" files are in the folders of a specific style sheet, such as view/default or view/seesun and the static files in pub/default or pub/seesun correspondingly. Secondary "view" files must not begin with an underscore, for example view/header.php. "View" files of the central body of the page must begin with an underscore, for example view/_news.php and the code of the file must begin with such line: . By the way, all the other php script files, which are not the beginning of the script execution (where constant START is defined), must be preceded by the code: 

In general php statement "die" has a synonym "exit", and in SKY. the first option is used for protection, and the second - for the correct completion of the script.

The "production" should never have directories that begin with an underscore, but on a local development workstation there may be directories like _arch - to store documents to the project and other files, _loc - special scripts for developing the principal application, _dev - a directory of DEV.SKY application.

"View" files (are relevant only for the front part of the Web application) contain HTML layout code with small, very simple php code. The main processing almost of all requests to the server is made in the file main/body.php or if processing has a lot of code, the control is passed from this file to the files main/b_page_type.php, where 'page_type ' is a request page. Ajax requests are executed in the file main/ajax.php or main/a_ajax_page.php, where 'ajax_page' is a page of ajax request. In the "view" files within the HTML code it is allowed to organize the cycles which are not more complex than by using the code: , (see the definition of constants 'fetch' in the file main/sky.php, more complex processing must be carried out in the 'main' folder. In a very complex functional applications, in SKY. you can use the MVC programming pattern, however, for most Web applications, it is recommended not to use it. In the case of a cloud-based modification of null-site for MVC, the handler code is further separated into controllers and models, and the files are located according to the pattern: main/mvc/с_page_type.php, where `page_type` - is a query page and correspondingly in main/mvc/m_some_table.php, where `some_table` is the name of the database table. The admin page files (do not have specific "view"), begin in the same way as the "view" files with an underscore, but are located in admin/_page_type.php. The simple design of the admin pages, as well as a special code of the second wing main/wings.php eliminate the need for "view" files. Sometimes you might want to take out some of the code from these files into special files, for example, admin/special_code.php, it is allowed. Such files must not begin with an underscore. Class files (third wing reusable code), if necessary, are located in the 'class' folder, for example, class/remote.class, they do not begin with an underscore, and have the extension .class. Label files are in the 'label' folder - for example label/comments.php. Rigid caching files - in the 'cache' folder, for example cache/part1.html. Labels and rigid caching is the SKY. functionality of the front part of the sites, which is provided in the file main/front.php. Labels are parts of HTML or files php generating the parts of HTML code (HTML page fragments) that are inserted into HTML automatically with the help of instructions% HTML_NEWS% or % PHP_NEWS% defined at HTML code level (parent), they have recursion. Rigid cash is a functionality that allows you to disable (cache) php code, including SQL queries for the cache lifetime. As a rule it is defined in PHP_ labels type. For example, such a code in the "view" file: %PHP_NEWS% execute php code of the label once for the cache lifetime. Subsequent queries to the page, after generating a cache file in the cache folder, will not load the server with running the code defined in the label. Here the finished result will be used of the generated HTML part from the cache folder. If you must place cache-files of a different type in the project, a subfolder with the name of the type of the cache is created in the cache folder.


Protection can be of two types: with exiting the script and without exiting. For example, you have a query:

$q = sql("select * from article where id=$PVAL");

Protection could be done using the die statement; or without it... Here is an example of implementation of both options:

is_numeric($PVAL) or '' === $PVAL or die; $PVAL or $PVAL = 1; # variant 1

$PVAL = $PVAL ? intval($PVAL) : 1; # variant 2

In SKY. you must use the protection which requires less PHP code. Please note down: in the above examples, the protection is combined with the code of the article selection by default.


Web application pages can be of such types: list, show, edit, add and combined. The types correspond to the operations with data in the data base - select, update, insert. For example this page type is 'show' for the central part of the body of the page. In the left column, the list of news is of the 'list' type . I.e. in the whole the type is combined, but a part of the application architecture is such that the left and right column of most pages is not unique, there is a common code for generating extreme columns, and it means in relation to the 'view' file, which is the central body of the page, this page is a "pure show-article"... However, if under the text of the article there is a listing of comments - the page is combined. Let us note that in the admin section the combined pages are less common. Such formal typing of pages allows us to create a special tool "Visual SKY." as a part of the function of the application DEV.SKY., using which the quick scaffolding of a new annex on the basis of the Visual design is performed. Without programming, for a short time, you have a possibility to generate the admin files and frontal part files of the site with a unique architecture, which, firstly, will be functional immediately after generation, secondly, they will not have a redundant code, and thirdly, like all SKY. applications, they will be extremely productive and easy. After design through a "Visual SKY." tool, application development can go in the normal way - through file correction by the programmers. Page typing also allows to formalize granting the access to the parts of the page, or portions of the site (ACL).


Reusable code in SKY. is divided into the code of the first, second, third wing, meta code and the code of complete applications. See the page "Terms"

Currently in SKY. we use jQuery for writing javascript. This framework has quite a good crystallization, but in SKY. we are developing a more crystal javascript framework - jSKY..