The pre-processor will take care of HTML end tags. The flexible system of scripts binding is more powerful than SSI. It lets you easily create diverse module documents.
The abstract function is an analogy for a tag. Thus, the author of the Internet documents gets the advantage to expand the set of the commands he can use (like in XML).
dbPager is easy to learn, because it comprises small set of basic commands.
The commands have simple syntax and just 7 of them are mostly used. It allows you to learn and use dbPager very soon.
When applying to the external sources of data, dbPager uses Borland Database Engine (BDE 5.0). It enables you to work with wide variety of databases - from desk ones (like dBase and Paradox) to the server ones (as Oracle, MS SQL, Interbase)
The dbPager scripts are compiled in RAM while the first applying to them (the Just In Time Compiler method is used). Usage of the managed cache increases the efficiency even more.
The most efficient solution is offered for MS IIS, where dbPager is set as an ISAPI extension, but thanks to CGI implementation dbPager can be used on the servers of other producers.
There are two major approaches in the world for the Web-programming. The first of them uses algorithm languages (C, C++, REXX, Perl), then the web-site comprises two kinds of documents: HTML and CGI. The modules are usually used for performing of simple actions. They rarely used for the building of dynamic pages of the site (it's too expensive pleasure). The second approach implements the widening of the standard tags (ColdFusion, Miva, XML). From the point of creating the dynamic sites this is preferable approach, because it uses not only the peculiarities, but also the syntax of ML.
Unfortunately, the both ways almost exclude (or make too complicate) the use of visual means of document creation. That why the programmers have to write the scripts using common text-editor software, and two problems rise before them:
dbPager implements the transitional approach to the Web-programming, which eliminates the listed above problems. The basic idea of the dbPager is that HTML documents are treated not as the sequence of tags, but coalition of the incorporated levels (the descriptors). In the dbPager the levels made of the tags pairs (the opening and the closing ones) are described with only one descriptor, and the level's incorporation is provided by structural indents in the file's text:
------------------------------------------ <!-- This is a simple HTML page --> <html> <head> <title>The simple page</title> </head> <body> Hello the World </body> <html> ------------------------------------------- <html> // The same page in dbPager <head><title>The simple page <body>Hello the World -------------------------------------------
As we see the amount of the document text is significantly decreased. Let's imagine that we deal not with so simple page, but with a complicate document comprised of the header, menu, content and an advertisement block. The module presentation of such document significantly eases the work with it:
------------------------------------------- <html> <head><title>The complicate document <body> @header // the header of the document <table border=0><tr> <td valign=top> :: @menu // the menu <td valign=top> :: @info // the content @footer // the advertisement block --------------------------------------------
@header, @menu, @info, @footer are commands to connect with scripts from the external files. This type of binding references is similar with SSI, but dbPager provides even more powerful way to fasten the scripts.
Note that in the previous example the external levels of the documents contain the same descriptors. We can unite those descriptors in a separate file html.dbl:
-------------------------------------------- <html> // The simple example of a pattern <head><title>%arg1% <body> :: @@ // the backward call --------------------------------------------
We see a new constructions here: %arg1% - the substitute value of the variable quantity; @@ - indistinct call as connecting with the incorporated levels scripts. Now the description of the complicate document is significantly simplified:
--------------------------------------------
@html("the complicate document")
@head // the document's header
<table border=0><tr>
<td valign=top> :: @menu // the menu
<td valign=top> :: @info // the content
@footer // the advertisement block
--------------------------------------------
The containing non-evident call scripts we can consider as an extension of the standard HTML tag set. This is the most powerful tool given to a programmer by dbPager. From other prospective this tool is so simple that it is hard to imagine anything better.
The common file (not scripts) in-building into document can be described by the script include.dbl:
-------------------------------------------- read %arg1% :: %file% // to read and to substitute the file --------------------------------------------
To use this script as easy as to write it:
--------------------------------------------
@html("The file article.txt") // we connect the file
<pre> :: @include("article.txt")
--------------------------------------------
dbPager, originally, has small set of basic descriptors and the possibility to create the new ones. From one point it allows easily to learn the programming in dbPager. From other point it doesn't limit the developer in means. The repetition in use of the earlier created extensions is the main principle of programming in dbPager. ("Divide and conquer!")
There is no need to know the complete set of descriptors (only 21 of them) in order to begin creating the documents in dbPager. The seven (the most often used) is enough for you:
This "gentleman's kit" is absolutely enough for creating quite complicate documents. But the use of complete descriptors assortment provides for the programmer really amazing capabilities (opportunities).
The main enjoyment from the work with dbPager the programmer gains when he/she comprehends the programming philosophy on this language and when he/she will go beyond the limits of liner algorithm programming so customary for the computer languages like Basic, C/C++, Pascal, Perl. The descriptions of the documents will become clear and concise. The programming will bring the esthetic pleasure. The ideas of the imbedded contexts and of the abstract processors (the patterns) are the keys to understanding of the dbPager's essence.
The access to the databases is provided with the SQL-requests language. The syntax of the requests is extremely simplified. The example below shows how to expose the list of the registered users:
--------------------------------------------
@html("The List Of Users")
<ul> :: sql select * from userlist by username
<li>%username% - <a href="mailto:%useremail%">%useremail%
--------------------------------------------
The descriptor sql contains the line which is interpreted as a request for database. When the request is fulfilled, the table fields' values are placed into the variable quantities with the same names and for every line of the selection called the imbedded (relatively to the sql descriptor) levels of the script. The variable quantity's values used by placing the name of variable quantity into "%" signs. In the exposed above illustration the third line will be executed in cycle with substituting the emails and users' names.
Besides of sql descriptor there are two more descriptors used for the access to databases:
The work with the sources of data is done through BDE, that why the dbPager supports the whole range of various databases used in MS Windows. The syntax of the request language must be the same as the used database server dialect, because dbPager doesn't execute the requests by itself, but only transmits them to the database server for the execution.
For the sake of system productivity the connection with database server is not closed after the script has been executed. The next application to the server uses already opened connection.
The unusual way to build scripts using the imbedded descriptors' levels allows the interpretation of the scripts to be efficient.
dbPager fulfills the scripts according the " Just In Time compiler " principle. At the first application of the script it is compiled into RAM and is used just after that. During the later applications the pre-loaded code is used. The used dbPager's code is just little a bit slower than the one written on C/C++, Delphi.
It is possible to place any sequence of the descriptors levels of a script into CACHE memory.
It's impossible to cache the scripts automatically, because the script may use (when it generates the documents) such data as date/time, the user session variables, files, selections from DB, but the control of the document's content from this factors is too complicate. So the special descriptors are used for the caching:
cache - to use cache and
reset - to renew cache.
This descriptors use the unique cache identifier, which may be composed from defining the script behavior parameters.
Example:
------------------------------------------
@html("The list of users")
<h3>The list of users for %now%
cache user_list // Caching of the selection with the list formatting
<ul> :: sql select * from userlist order by username
<li>%username% - <a href="mailto:%useremail%">%useremail%
------------------------------------------
As we see, this script doesn't cache the timer's value (%now%), but only the list's output.
Using in dbPager the "JIT compiler" principle together with caching results in very good productivity.
For the best stability and productivity of the entire system dbPager is offered in one of the two varieties:
All the requests coming on the Web-server are translated into dbPager and are fulfilled in it. It is illustrated by the next picture:
In order to apply to the dbPager server WWW server uses one of the two protocols: whether CGI or ISAPI. The choice is defined by the system under which the dbPager is installed. So, there is sense to install dbPager_iis.dll under MS IIS and other servers supporting ISAPI. This module is an extension for the server and once being downloaded into computer's memory it processes all of the coming requests. The ISAPI use is preferable, because it spares the computer's memory and the module downloading time.
If the WWW server doesn't support ISAPI or not completely supports it then the module dbPager_cgi.exe may be used for the interaction with the dbPager. Note, that CGI module doesn't process the requests by itself, but only translates them to dbPager server, that why the CGI usage doesn't slow down much of total system's productivity.
THE DESCRIPTORS' MANUAL
OR...
| BACK HOME |