The SKY. core
The following three files make the base of SKY. core:
The first contains a necessary code for any entry points, the second for entry points 'front' and 'admin', and the third only for the 'front' entry point. On the basis of functions and classes (objects) provided in these files, the whole system of SKY. is built, as well as any SKY. applications, etc. As a matter of fact, the code in these files complements the programming language PHP and the MySQL database with necessary functions and classes that are built based on the most frequently used parts of the algorithms in Web-programming and which make these algorithms as simple as possible and maximum user-friendly. In total up to 30 functions in the global domain and four objects (access to DB happens through a SKY. object). Thus in the global scope there are three objects SKY, USER, and ADM. The latter is not explicitly defined and is generated from an array, through type casting. This object is available, if a current visitor has a personal record in the table 'users' (a registered user) and is currently authorized. Core functions are fairly simple to be described. If you're a programmer and you see their code, you'll understand their purpose. A few words about the SKY. core objects. All core objects may have one instance (used as singletons).
SKY. object is multi-functional. It performs the functions of unpacking and storing in a database of the site settings, carries data registry functions, encapsulates the trace functionality, and provides access to the DB. DB object. provides a special way (which helps minimize the code) of adding and updating rows of tables, with a simultaneously embedded functional of data validation recorded into the tables. At the same time the information about the structure of tables is used, which can be saved (cached) by SKY. object in the DB. This object implies that the names of the form fields on the append or edit page of the application object is the same as the columns of the table, for example an edit form fields of some article (application object) are the same as the columns of the table "articles". ADM object just encapsulates the data of PHP array into one object (easier to use) - information on the access to the Administration section for current use (if the user has any access to administration). And the USER object contains properties (information) and the management techniques of the current site visitor. In general, in SKY. there is no sessions table, but there is a partially equivalent (in a functional way) table of visitors - `visitors`.
Eight special functionals
For the front part of Web applications SKY. provides the following mechanisms (functional):
- labels-tags - are specified in the HTML code and before "issuance" to STDOUT (the browser) are parsed (through functions
head(..)) to replace the label with the executable code PHP or HTML code, have recursion. This allows you to easily create complex diagrams of display of the parts of the Web application pages, and create a mechanism for fixed caching.
- fixed caching is (implemented using the function
cache(..)), allows you to fully disable (cache) the PHP code parts to improve the performance of Web applications.
Another important functionality:
- tracing is necessary for convenience of Web applications debugging. All requests to the database (going through function-wrappers
sqlf(. ..)) are automatically traced, moreover the direct use of the function
trace(..)is also possible.
- data registry is a well-known global data encapsulation approach is defined in SKY. object.
- SKY. memory - automatic saving and retrieving configuration data in the database.
- special insert, update - a DB object mechanism
- layers CRON, MVC
The following tables are always defined in the SKY. applications (except the rare cases) `visitors`, `users`, `memory`. The first records the sessions of the site visitors, the second is the table of authorized users, the latter is a special table where each record (line) has its own unique individual function. For example, in this table a line with id=1 stores trace output of AJAX requests.
Recommended architectural solution, when building a Web application, means that the LAYOUT of a site pages is located in the file index.php, and the output to STDOUT (browser) is delayed by PHP function
ob_start(). Of course, if the application has multiple simultaneously supported styles or the application requires more than one LAYOUT, they may be stored in the folder
/view/. Front page handler, in this architectural solution is located in the file
main/body.php. Handlers for pages with a lot of code are transferred to the files
main/b_page_name.php. Accordingly, the AJAX requests in the file
main/ajax.php, and the requests which processing requires a large number of code are written in
main/a_name_of_request.php. For applications with very large number of functionality, it is recommended to use the architectural solution with MVC Layer, as this pattern very well formalises the location of the application code for a simple diagram and conceptually generates a large number of files of controllers and models. At the same time LAYOUT can also be in the file index.php. Request handlers (both of AJAX and the front part of the site), in the case of using the MVC pattern, as usually, are stored in the controllers (in
main/mvc/c_page_name.php files). The third architectural solution when building applications - the use of the "NICE" LAYOUT. Page handlers, in this case, are stored in the files
page_name.php (application root folder).
Please pay attention: CRON Layer, is always located in
main/cron.php. CRON-tasks usually have a little PHP code and can be stored together in the same file. However, if you have a lot of code and/or execution of the code of CRON-task requires higher reliability, the separate CRON-tasks must be located in the files
main/c_cron_task.php. The fact is that, if the file
main/cron.php contains the code for many tasks, then the tasks that are defined lower in the file are likely to be erroneously not-executed due to fatal errors in the tasks that are defined higher in the file.
See examples of architectural solutions described on the download page of SKY.
The system of single-letter prefixes in SKY.
In SKY. we use a system of single-letter prefixes with an underscore. Global variables with prefixes:
- $g_... - GET requests, with enabled screening by using a backslash. In a superglobal array $_GET, and backslashes are removed if there were any (see the code at the beginning of the file
- $p_... - POST requests, shielding is similar
- $c_... - cookies, shielding is similar
- $f_... - uploaded files
- $s_... - configuration variables from SKY. memory. Variables-references refer to variables within the SKY. object.
- $r_... - variables which correspond to the names of the table columns, using a constant
`fetch`in the code, as follows:
The names of the files MVC-layer:
- main/mvc/c_page_name.php - the names of controllers files
- main/mvc/t_name_model_table.php - names of the files of tables models
- main/mvc/m_name_other_model.php - names of the models files other than of the tables
The properties of the MVC-Layer objects and names of the methods of MVC controllers:
- c_page_name_type(...) - names of the page controllers methods
- $this->g_..., p_, c_, f_, s_ inside of the controllers and models objects, access to corresponding global variables described here above (access by the link).
- $this->m_..., t_ - inside controllers and models objects, access (and automatic creation of instances of models objects if they were never instantiated). Comment: If you want to create more than one instance of a model, you must use an operator
In view files, in the global scope (only when using the MVC pattern):
- $v_... - view variables passed from pages controllers (access by the link, the variables are stored in the properties of the controllers $this->_v, in an associative array)
- $y_... - view variables passed from controller common_c::head_c(...). This is a general controller, which is default for all pages, but the method head_c(...) can be overloaded in page controllers.
For details concerning call sequence and MVC-Layer management, see
SKY_view object constructor code. For "registered variables" inside the MVC model, we recommend that you use
x_, prefix properties, such as
Always in the view folder (possibly including styles subfolders), files can have such prefixes:
- y_... - LAYOUT files
- _... - the files that begin with an underscore are the files of the central body of pages
- files without prefixes - are the included parts of pages
Always folders that begin with an underscore are the folders (directories) that should exist only on the computer of the developers. Production must not have the folders that begin with an underscore. On a developer's computer it is recommended to have the following folders: _arch, _dev, _loc
Versioning system in SKY.
In SKY. we use versioning system by the following scheme: number-dot-three_digits, for example, a version 2.232. It is convenient to present version numbers, at the same time, with 'FLOAT' type in the memory. In this diagram, the "digit" is the version majority number, "three_digits" is a build number. If in the public domain you indicate a new version of some project, we recommend to assign a version number which is as close to the value, where there will be three zeros after a point, as possible. For example, version 0.980 (a candidat for a stable version). It is understood that this is the first public upload of the project and after a maximum of approx. 10 builds it is planned to get a stable version 1.000. A calculated value of builds must be multiplied by 2 (double stock).
If you've totally re-written an application so that it is not compatible with the old version, despite that its purpose has remained the same, the application should be given a new name and the versioning must be started anew.
Idealization of the core and the whole system of SKY.
All files, including SKY. core, packages and applications are subject to versioning. After some iteration process, you need to get the perfect version of "clear cloud" (within strictly defined limits). You must always strive that the perfect condition of "clear cloud" was the most frequently used for reuse (most frequent particular case). There may be cloud modification of files or applications that are rare particular cases (compared to "clear cloud"), they are generated by modification scripts. You should not create applications or files which are too much capable for configuration. It often happens that possibilities of codes of such applications remain unused, plus an application becomes too much complicated, confusing and less productive. When designing in SKY., you need to remember the main rule - "In SKY. everything is really simple."
Because of the SKY. paradigm: there can be only one ideal code for each specific task, in SKY, for example, there can be only one application FORUM. SKY. (implementation of general purpose Forum), one perfect version. But there may be scripts of modifications, such as a forum for creating the site, torrent server. The last forum code is generated from the Forum FORUM.SKY. "clear cloud" by its modification (through a special script). The last forum should also be called FORUM.SKY., but have the attribute 'Portname' equal to 'torrent'. If the changes are too big, in order to obtain the ideal forum for torrent server (which implies - "from this forum, it is impossible to create a perfect torrent-server"), the application is given a different name, and it must be present in SKY. system as a stand-alone application, and not as a port from any application, for example TORRENT.SKY. If a lot of ideas from the "old" application were used, you can give the name TORRENT.FORUM.SKY, but you must always strive to develop the perfect application within the certain framework.
CORE-SKY files can also have the attribute 'Portname', for example, you can write a file main/sky.php with 'Portname' equal to postgre_sql, this will mean that the functionality of this file strives to remain the same, but uses a different base - DATABASE Postgres sql. If the file functionality is extended, but fully preserves the previous functionality, then 'Portname' must begin with the word 'extended', if it does not preserve it - with the word 'final', for example - Portname: final search engine. Developers must understand that if the available 'clear cloud' CORE-SKY file does not meet the requirements of an application, it is all the same easier to modify an existing 'clear cloud' (or one of the ports) than to write a file anew. Of course you can take into account the file rating in CORE-SKY Codebase.
The names of all applications in SKY. must consist of capital letters and have a postfix .SKY. as shown above in the examples. The application's name must indicate on its belonging to the publicly available SKY. system.
Files, packages, and applications may not have the attribute 'Portname', you do not need to specify it for "clear cloud" objects (ideal or striving to be ideal).
Files and packages (but not applications, they are always unique) may have a 'Filename' attribute with a value "unique" that idealizes the file. For example, the file in the system 'f:main/sky.php' has such an attribute, and you cannot add a file with the same name into the system. But if the file does not have such an attribute (with the same value), for example as 'f:index.php', then there may be several of such files in the system. This means that it is not possible to create such a perfect file, given the equal distribution of the frequency of use of different versions of the file.
In accordance with this, each record can have the attribute `Filename` and `Portname` in the code DB for reuse "CODEBASE".
Tokens in the SKY. 2do.
In certain circumstances, in real time, while programming the code (more often it refers to "clear cloud" code), a developer may not be able to make a part of the code perfect. If he realizes this, but nevertheless, most of the code written by him, in his view, is ideal, he can publish such code for public use, but in the parts which "are not perfect", it is recommended to set a token "2do", using the comment. For PHP code you need to put a comment beginning with "#" mark, for example
or better with an explanation:
# 2do: to revise this article
Such tokens will let you "remember when you see it", or will even allow another person to make changes (additions) to the code and become co-author of the code without a complete analysis of the code (as to its ideality) written by the first author. This peculiarity allows you to speed up the process of receiving of the perfect code by public.
Even this site has a special menu (and it will always have it) - "2do." This is done to ensure that the public knows the SKY. project development priorities. In addition, any programmer in the world can become a co-author of the important tasks of SKY. in the real time of the project development, and it could increase his influence in SKY. In general in SKY. there is a system of levels of user profiles: Root, ProgrammerL1, etc. Initially, after registration, a user receives a standard profile "Registered" and he can immediately participate in the development of SKY., upload his work. Without registration you may only download and use the code for private projects. The profile level defines the level of access to SKY. resources. In the menu "2do" we indicate important tasks that must be performed, sorted in the order of importance. It must be taken into consideration that the list may not include secret tasks.
For the participants, except for profile levels, there is a system of ranks and ratings. The latter define the level of influence on the development of SKY. system. One person, may people or SKY. system itself (in the future) (algorithmically, maybe not a complete solution, but partial at the first stage) can take a decision about the perfect form of any private object in SKY.. But the opinion of SKY system programmers, participants with higher rating will always be very important.
Markers (properties) of records in the code database CODEBASE
In SKY. system in the code database for reuse the entries can have the properties of the class "Code targets". Each property can be marked with a tick or not (logics of "Yes" or "No"), here is a list of properties: localtask - an entry not pretending to be too significant, solving a local task in the project, optimized - an entry pretends for the optimized code condition in it (crystallization is not claimed to be perfect), idea - an entry brining a new idea into the project, coresky - an entry pretending for the code of the first, second, third SKY wing., mystar - the developer is sure in the entry perfection, full (or high) crystallization, waiting_votes - voting is now open for this entry, opened for new authors - co-authors are invited. Selection of entry the properties by the author and voting of the system participants for the entry affects both placement of the entry into a certain section of SKY. and the ranking and title of the entry author.
Properties of the class "Code status": 2do, must_extended, unknown - selection of one out of three.