About Phella
Innovations
Features & Approach
Demo & Implementations
Plug-ins
Download
Documentation
Contact



Table of Content

Note: Some code samples and HTML renderings in this manual are imaginary for ullistrative purpose only. Though other samples marked as LIVE SAMPLE are actual execution of the corresponding code. You may see how clean and simple code to achieve rather complex results. This is the main feature what Phella was developed for. Also you may try interactive LIVE SAMPLE right from this document and see what result it generates.

Introduction

Phella is the small footprint PHP framework. While with the additional plugins it may be scaled to much larger extent. One of the most important plugins is CMS. It doesn't make Phella a boxed CMS but offers intellegent API to build a custom tuned CMS. Though there is at least one ready made CMS approach supplied as a sample and completely working solution which already employed in several projects. See more detailed description at www.phella.net.

Phella was programmed for PHP4. At the moment this lines were written PHP4 was just stopped from further developmnet. And yet it is still the most used PHP platform worldwide. Of cause Phella will work in PHP5 too. And there you can get a bit more flavour.

Somebody may find style of programming in Phella a bit too loose. The very first code line says:

<? error_reporting (E_ALL ^ E_NOTICE) ?>

There are strong oppinions that such approach is not recommended. Yes, we aware of that. And still after observation of all pro's and contra's we believe that simplicity and cleanless of the program is the most important feature. For instance we can write the same thing in two ways:

<?
  /*1*/ if (isset($variable) && !is_empty($variable)) {...}

  /*2*/ if ($variable) {...}
?>

The first line is theoretically more correct but the second is simplier. Finally the more iportant is what goes for {...} and the "if" expression is additional condition. This sample may be not impressive when you see it isolated but if program literally overloaded with such "technical" details you hardly can get main logic of the program while browsing through the code. We are in web stuff and if there empty value or non-existing variable the sense is the same in 99.99% cases. If it an exception then work it differently but please leave the rest of the code "clean".

Glossary

Controller

A PHP script which controls all workflow for the project. It is called on every web request and maintains all the tasks for this request.

Module

A PHP script which provides functionality of the certain part of project. Modules usually don't have any visual output commands (unless it's a debug output).

Template

A HTML document with PHP tags which generates visual presentation of the webpage.

In fact 'modules' and 'templates' are the same type PHP scripts. Difference is only logical - 'modules' do calculations without output and 'templates' do output of calculated data. It is how presentation separated from functionality.

It is also good to format 'modules' and 'templates' differently. 'Modules' as whole script:

<?
…
/* PHP code lines */
…
?>

And 'templates' as HTML documents with PHP embeddings:

<html>
…
<center>This page has been accessed <?=$OUTPUT["counter"]?> times.</center>
…
</html>

Main Template

A template which generates main output for the requested webpage. Its name is passed in the web request to the Controller. All other templates and modules used in the same request are just mounting chase for the main one. For instance when server gets request:

http://www.domain.com/?template=home&lang=en
or
http://www.domain.com/?page=home&lang=en

the 'main template' with the name "home" will be invoked by the Controller.

Template Variable

A query request variable which carries name of the main template requested by the user. We may consider it as a name of the requested webpage. For instance:

http://www.domain.com/?page=home&lang=en

In this sample 'template variable' is page. This name can be changed in the configuration file.

In order to retreive name of the current main template we dicourage to use 'template variable' explicitly. Let leave it only for URL appearance. Enstead we advice to use definition TEMPLATE which always carries name of the current template disregarding of what 'template variable' is. In other words this sample of what is not appreciated:

<? if ($page=='home'): ?>
...
<? endif ?>

Better to use this notation:

<? if (TEMPLATE=='home'): ?>
...
<? endif ?>

Synonymous Module

Synonymous Template

In Phella each template assumes corresponding (pairing) module. It has the same name and called 'synonymous'. When template invoked for output the synonymous module automatically called before to generate necessary data. If synonymous module doesn't exist, there is no error will be generated. It means template doesn't need any data to generate (or takes it from another source).

Standalone Module

A module which is not pared to any synonymous template. It has to be called explicitly (or set in configuration file) when one needs functionality of such module.

Sub-template

A template which generates presentation output for the part of a webpage. Sub-template may be called to be inserted into another template to utilize similar portions of output several times or in different pages. The rule of synonymous modules applied to sub-templates either.

Pre-template

Post-template

Templates called by the Controller before and after main template . Rule of the synonymous modules applied to them either. Presentation-wise we may consider them as "header" and "footer".

Pre-module

Post-module

Standalone modules called by the Controller right at the beginning and at the end of all web request flow. These modules don't have any realtion to pre- and post-templates. Pre- and post-templates do have their own pairing synonymous modules.

Incoming Data Pool

A PHP associative array $INPUT containing all incoming data necessary for business logic. It organized similarly to PHP's arrays $_GET or $_POST, but contains variables accumulated from all kind of sources (GET, POST, cookies, session variables). All security checks already done by the Controller, developer don't have to think about technical details how and where certain variable came from.

$INPUT has global scope and available in any module and template by default. It is unappreciated if any user-deifned module writes anything into this array to avoid potential bugs. Logically it is only for reading purposes.

Outgoing Data Pool

A PHP associative array $OUTPUT similar to $INPUT ( Incoming Data pool ), the main transport for exchanging data between modules and templates. When module called it stores generated data into this array. Then template uses data from the array to generate output presentation.

Data Flow Concept

Phella provide abstraction layer above standard HTTP protocol. All incoming (GET, POST, COOKIES) and stored (SESSION) data necessary for implementation of web request accumulated in one pool. There will be no information in the pool how particular piece of data came. All necessary security checks already done by Phella and developer may use data for business logic as it is. The name of the array is $INPUT and it's accessible in every module and template automatically.

There is similar output data pool which holds data generated by the scripts. This data may be used for generating HTML output (in template s) and exchanging information between different module s. The array's name is $OUTPUT.

$INPUT and $OUTPUT arrays declared global but while you processing scope is inside function you obviously have to declare them global again. According to the our main terms of "simplicity" addition declaration is hassle. It may be forgotten either. That why we decided to give you one may be arguable but powerful option. We provide you super-global aliases for $INPUT and $OUTPUT array which no need to be declared inside the functions. The alias for $INPUT is $_GET and alias for $OUTPUT is $_POST.

Yes, it means that we spoiled all initial data in $_GET and $_POST arrays and utilized them for our needs. Remember that we designed Phella covering HTTP protocol for you and that why you don't actually need $_GET and $_POST arrays for the purpose they were designed in lower level of PHP programming. Though for the sake of debugging you still may find original low level content of these arrays in $_GET['_GET'] and $_POST['_POST']. See configuration options how to activate and handle this behavior.

Mechanism of global variables has nothing bad in it's nature if its well organized. For those who has religious tabu not to touch global variables in PHP at all we offer kosher class wrapper. If module module phella_class is included (see $CONFIG['pre-module'] in the config file for that) than you can use:
phella::input('var')===$INPUT['var']
phella::inputSet('var',$val)===$INPUT['var']=$val
phella::output('var1','var2')===$OUTPUT['var1']['var1']
phella::outputSet('var1','var2',$val)===$OUTPUT['var1']['var1']=$val

As you can guess this wrapper works for PHP4. More elegant PHP5 wrapper is coming soon. Need to note that we do not encorage using "wild" global variables other from those we provide.

Working with Sessions and Cookies

As was said above Phella was made to place layer between developer and HTTP protocol. It means that session variables and cookies are not an exception here and coming into the common pool of input data together with GET and POST. Variables which suppose to be stored in the sessions and/or cookies should be listed in the config file (see $CONFIG['session-vars'] and $CONFIG['cookie-vars']).

For instance we declared variable "sort" as a session variable:

<?
  $CONFIG['session-vars']['sort'] = array('valid'=>array('none','asc','desc'));
?>

It means that (1) session mechanism automatically starts, (2) $INPUT['sort'] initialised to the current value from session or to "none" by default. If client supplies another value through GET or POST channel, then it will be taken and stored in the session.

So once you declared variable a session you may forget it. Phella Controller will handle all validations and back-end operations for sessions and cookies.

All said above concerns only "public" variables which client may change at his own wish. There are also may be "private" variables which client may not manipulate freely, for instance authorization state of the client. In this case such variable (1) should not be declared in $CONFIG['session-vars'], (2) to avoid any possible security damage such variable should carry dot in its name. For instance you will have variable $INPUT['.authorized'] automatically retrived from the session storage while client may never ammend it directly. Presence of a dot symbol at the beginning makes clear idiomatic impression of a "private" data, we ecourage such custom.

To store explicitly "private" variable in the session use phella_sess_store() .

Working with Markdown

Because of small footprint Phella good not only for the heavy programmed websites but pretty static ones too. It is much easier to develop and maintain them within a framework than "raw". If there is a lot of content to carry we offer Markdown to publish the texts. Thoughe WYSIWYG is also available but Markdown is our preffered solution. See our Approaches if wonder why.

In Synonymous Module we showed you that each webpage or Template comes with the pairing Module of the same name. Together with Markdown this pair extends to a triade. Well quite often Markdown page doesn't need its own functionaly module if its only static text. To simplify explanation instead of triade Markdown-Template-Module lets talk about pair Markdown-Template, the other member works as usual.

First what you need is to activate Markdown functionality in config file. See $CONFIG['source-prefix'] and $CONFIG['source-suffix'] which work very same as $CONFIG['template-prefix'] and $CONFIG['template-suffix'].

If Phella detects Markdown source it processes it and stores to the HTML cache which actually is the Template in our terms. Not every webpage have to be done in Markdown, some of them may have usual HTML/PHP source in the Templates. It is no need to specify which page is in Markdown and which is HTML, everything detected on the fly. Markdown itself also allows HTML and PHP embeddings.

Phella automatically regenarates cache (Template) if Markdown source has been ammended. Abviously there is one condition that Templates (which work as a cache now) have to be "writable" for your webserver (user "nobody", "www" or else). This may be good reason to arrange templates in a separate "writable" directory see ($CONFIG['template-prefix']).

The rest of the functionality is very transparent. You don't have to pay special attention is it a Markdown page or generic HTML.

Working with Cache

Phella provide three different kinds of caching mechanism. They are independed and used for different puproses. That why theoretically they can be combined very wildly.

Static cache

Each webpage in Phella combined at least from 3 parts. Even if pages are not really dynamic but any way PHP invoked every time to put together footer, body and header. Phella footprint is so small that it takes practically the same resources if the operation was done in plain PHP without any framework. But even here you can be more savvy. You can switch on static cache mechanism and since that first invoke of the page will create plain HTML cache and all other calls will be directed to this cache. Nor Phella neither any other single PHP code line will be invoked. All call will go through your webserver only to a static HTML file.

In fact you can develop the website on your working station, export it to plain HTML files and upload only them to the production server. You don't need Phella and even PHP itself on the server. Well it is a bit exaggerated sample, any website need a bit of dynamic stuff (contact form for instance). But we believe you got the point.

Static cache works in conjuction with re-write mechanism (though re-write can be used alone without cache). As you remember re-write purpose is to mimic dynamic pages as static. Then if switched both it not only mimics the page but actually stores it to the disk. And then sinse the file exits it actually used instead of dynamic call.

See $CONFIG['cache-prefix'] to trigger cache and $CONFIG['rewrite-encode'] to setup re-write rules. There is also sample of the Apache ".htaccess" file provided with the re-write rules.

Fractional cache

The cache is good when it saves heavy load to the database if data updated less frequently than read. Alas there is always some dynamic surrounding for the data (rotated banners, counters, etc.). It means no avail to cache whole webpage. Then we offer so called fractional cache.

Certain chunks of the webpage may be cached in plain HTML files. If corresponding data in the database was modified then cache file automatically removed. On the next read call it will be created again from the fresh data.

Fractional Cache also involves default re-write mechanism (see $CONFIG['rewrite-encode']). Usually formed chunks of templates we include into the common template using function phella_include() . If we want this chunk to be cached then we include it with phella_include_cache() . See also $CONFIG['fract-cache-prefix'] to define cache storage.

Markdown cache

This cache is a bit different nature from the previous two. It doesn't create HTML file per se. Instead it creates a PHP file which is Template in our terms. Well most likely this Template will consist of only HTML tags with no PHP code but theoreticaly it is a Template . And in theory it can be cached further down to a Static Cache for instance.

Markdown cache used always if Markdown functionality triggered on. See also Working with Markdown to understand how we employ it.

Setup

Default Setup

Developer has to organize website in that way so all request were going to the Controller. Phella comes with a sample of index.php file which do the task. Normally one has to drop it into the website root directory without any changes.

Suppose you have a root directory for your website at ~/public_html. Then index.php should appear as:

~/public_html/index.php

Another file config.php normally also goes together with index.php in the same directory. Sample of the configuration file is also supplied.

~/public_html/config.php

Read trough all config file as it is well commented and gives you idea what you can tune up for your project. The following explanation is good if configuration file used as it is supplied.

Copy engine directory "phella" to corresponding sub-directory:

~/public_html/phella/

Create header for your project:

<html>
    <head>
      <?=phella_head()?>
    </head>
    <body>

Save it to:

~/public_html/head.tpl.php

Create footer for your project:

</body>
</html>

Save it to:

~/public_html/foot.tpl.php

Create home page and write in some sample text:

<p>Hello world!</p>
<p>Today is <?=$OUTPUT['date']?></p>

Save it to:

~/public_html/home.tpl.php

Now create a business module for the home page carring all complex calculations:

<?
  $OUTPUT['date']= date('l, F jS, Y');
?>

Save it to:

~/public_html/home.mod.php

Here it is! One page website is ready to run. Call it http://localhost or http://www.mysite.com or whatever else your webserver configured. The most easy way to produce all the steps above is to copy our provided source as it is with all directory tree into your ~/public_html/.

Custom Setup

A lot of custom ajustments may be done in config file. Read it and get an idea. Here we just name several.

Remember that some modules and templates have to have the same names (synonimous). For instance the page "home" consists of two files. You may give them different suffixes/preffixes or store in different folders:

~/public_html/home.tpl.php
~/public_html/home.mod.php

or

~/public_html/templates/home.php
~/public_html/modules/home.php

Note that if you don't need any specific functionality for the webpage, you may omit corresponding module file at all.

Do the setup in configuration file accordingly the way you store templates and modules. In first case it should be:

<?
  $CONFIG["template-prefix"] = "";
  $CONFIG["template-suffix"] = ".tpl.php";
  $CONFIG["module-prefix"] = "";
  $CONFIG["module-suffix"] = ".mod.php";
?>

And for the second case:

<?
  $CONFIG["template-prefix"] = "templates/";
  $CONFIG["template-suffix"] = ".php";
  $CONFIG["module-prefix"] = "modules/";
  $CONFIG["module-suffix"] = ".php";
?>

Shared Setup

One Phella engine may serve one or several projects on a shared hosting. In the chapter above we used dedicated installation. Configuration for that will be:

<?
  $CONFIG["system-prefix"] = "phella/";
  $CONFIG["system-suffix"] = ".php";
?>
In order to share one Phella installation to different virtual websites you need to copy "phella" directory to some other directory on the server. For instance:
<?
  $CONFIG["system-prefix"] = "/shared/phella/";
  $CONFIG["system-suffix"] = ".php";
?>

Note that if you use leading slash in prefixes it means file system root directory. Without slash it means current directory, where "index.php" is.

Among shared PHP code which used within the server Phella has some HTTP shared resources such as images and JavaScripts. They are stored within the directory set in $CONFIG["system-prefix"]. To form a HTTP link to such resource you need to use something like:

<script language="JavaScript" src="<?=phella_href('(shared)','document','calendar/calendar.js')?>"></script>

This samples shows how to embed a calendar script.

By default all the resources go through Phella's internal mechanism. This may influence performance in bad way as soon as browser may deside not to cache them. In this case we advise to give shared Phella directory direct HTTP access through your web server setup. If variable $CONFIG['shared-http'] set to something non-empty, this will be used as prefix for URL to shared resources. Note that $CONFIG["system-prefix"] is the server filesystem path and $CONFIG['shared-http'] is URL path. In the default setup they are the same but it is not a common case.

If you run a webserver with virtual websites than you provide access to shared Phella through two channels: filesystem and web interface. For instance:

<?
  $CONFIG["system-prefix"] = "/clients/shared/phella/";
  $CONFIG["system-suffix"] = ".php";
  $CONFIG["shared-http"] = "http://www.myhosting.com/shared/phella/";
?>

If you use something like Apache's ALIAS setup you can do it more personalized for your clients:

<IfModule mod_alias.c>
  Alias /phella/ "/clients/shared/phella/"
</IfModule>
<?
  $CONFIG["system-prefix"] = "/clients/shared/phella/";
  $CONFIG["system-suffix"] = ".php";
  $CONFIG["shared-http"] = "/phella/";
?>

Plugin Modules and their Functions

Core Module

Core module responsible for basic functionality of the Phella Framework. Some of the most used functions may have another short form. In order to activate them you need to include module phella_short module (see $CONFIG['pre-module'] in the config file for that).

phella_include()

mixed phella_include(string Template [, arg1 [, …[, argN]]])

synonym [phella_short]: insert(…)

synonym [phella_class]: phella::include(…)

Includes in the place where this function encountered another template or sub-template in this case. If synonymous module exists it will be included automatically right before including this sub-template.

... some HTML text ...
<? phella_include('some_other_name') ?>
... rest of HTML text ...

Or using alternative "short" notation (available with the module phella_short ):

... some HTML text ...
<? insert('some_other_name') ?>
... rest of HTML text ...

The sub-template will have separate scope of variables. Only global variables $INPUT and $OUTPUT always available. If it's necessary to pass parameters in to the sub-template, $OUTPUT may be used for this task.

Let see one of the common sample. You output all pictures on your website in some kind fancy frame. It is like 5-7 lines of HTML code which are good to move in a separate template "framed_pic". The only we need to pass there is picture file name. See how it may be done:

... some HTML text ...
<? $OUTPUT['pic'] = 'pic1.jpg' ) ?>
<? insert('framed_pic') ?>
... some other HTML text ...
<? $OUTPUT['pic'] = 'pic2.jpg' ) ?>
<? insert('framed_pic') ?>
... rest of HTML text ...

But if parameters have very local meaning (like in this sample) it may be cleaner for the algorithm and business logic not to store them in the output pool . Then it is possible to pass parameters locally using arg1, …, argN.

... some HTML text ...
<? insert('framed_pic', 'pic1.jpg', 'left') ?>
... some other HTML text ...
<? insert('framed_pic', 'pic2.jpg', 'right') ?>
... rest of HTML text ...

To retrieve such 'local' arguments within the sub-template use function phella_get_args() :

<? $src=phella_get_args(1) ?>
<? $align=phella_get_args(2) ?>
... some HTML text ...
<img src="<?=$src?>" align="<?=$align?>">
... rest of HTML text ...

In order to stop processing of the sub-template before it reached its end, one may use return directive. Directive exit will abort all PHP processing including Phella Controller.

Technically it is possible to return a value from sub-template to the caller template, but we don't see any practical use for it.

phella_use()

mixed phella_use(string module [, arg1 [, …[, argN]]])

synonym [phella_short]: module(…)

synonym [phella_class]: phella::use(…)

Calls for stand-alone module . Usage is very similar to phella_include() , apart that there is no rule of synonymous module applied for obvious reason. Remember that module unlike template doesn't suppose to generate any output. Basically it is called only to get extended functionality and/or prepare some data.

There is one difference in behaviour with phella_include() . Phella searches for the module in the directory where all the custom modules reside for this project. If it is not there than Phella attempts to find it in the core directory. If it neither there then error will be generated. Phella never searches for template in the core directory as soon it is no such thing like "system templates".

phella_get_args()

mixed phella_get_args([int n])

synonym [phella_class]: phella::getArgs(…)

This function retrieves arguments passed to a template or module with functions phella_include() or phella_use() . Returned value is an array of passed values. If argument n supplied then the single Nth argument returned.

phella_href()

string phella_href([string template], [var1, val1 [, …[, varN, valN]]])

string phella_href([string template], [array vars])

synonym [phella_short]:url(…)

synonym [phella_class]: phella::href(…)

Returns qualified URL for another page in the project. Template stays for the template name. If it's omitted or empty string passed then current template (the page where it was called) will be used. Other query variables and its values given by pair of arguments, or in associative array.

For example we need to get URL:

index.php?template=product&group=common&id=234#mark

Then use function:

<?=url("product", "group", "common", "id", 234, "#", "mark")?>

or

<?
$query=array();
$query["group"]= "common";
$query["id"]= 234;
$query["#"]= "mark";

url("product", $query);
?>

Hash sign may appear at any place of the list, it will be always rendered at the end.

phella_href_add()

string phella_href_add(var1, val1 [, …[, varN, valN]])

string phella_href_add(array vars)

synonym [phella_short]: url_add(…)

synonym [phella_class]: phella::hrefAdd(…)

Function is similar to phella_href() but always uses current template and all current query variables already passed.

Examples:

Suppose we have template processed from the URL:

index.php?template=product&group=common&id=234

and used

<?=url_add("sort", "desc");?>

Then it will generate URL:

index.php?template=product&group=common&id=234&sort=desc

If variable passed with the name which already exist in current quiery, then it overwrites old value with the new one.

phella_redirect()

string phella_redirect([string template], [var1, val1 [, …[, varN, valN]]])

string phella_redirect([string template], [array query])

synonym [phella_short]: redirect(…)

synonym [phella_class]: phella::redirect(…)

Redirects current webpage to the new one using HTML header Location. All arguments are same as in phella_href() . In Phella one doesn't have to worry about any output done before sending the header. Redirection will be implemented any way even template already produced some data.

...Some HTML Code...
<? if ($special_condition) phella_redirect("other_page"); ?>
...Rest of HTML...

As alternative for redirection one may use cloaking trick. See how to use it in example:

<? if ($special_condition) return phella_include("other_page"); ?>
...Some HTML Code...

Difference between those two is the address line in the browser. It will state "other_page" or initial one.

phella_sess_store()

phella_cookie_store()

void phella_sess_store(string name, mixed value)

void phella_cookie_store(string name, mixed value)

synonym [phella_class]: phella::sessStore(…)

synonym [phella_class]: phella::cookieStore(…)

These function explicitly store data in session pool or in cookies. The functions used only for secure data (for instance trigger of authorization). Publicly accessible insecure session variables should be described in configuration file and work automatically. Recovery data from the session and cookie cache goes automatically for secure and insecure variables. See Working with Sessions and Cookies fro more details.

phella_include_cache()

string phella_include_cache(string template, [var1, val1 [, …[, varN, valN]]])

string phella_include_cache(string template, [array vars])

synonym [phella_class]: phella::includeCache(…)

Purpose of this function is similar to phella_include() with the only difference it caches its content and uses cache when it available.

Arguments for the function have different meaning either. They are not passed data into the template but list of dependencies. The template may have content depending on those data. See phella_href() for explanation of arguments, the notation is the same.

See also Fractional Cache chapter to understand how it works.

phella_clear_cache()

string phella_clear_cache(string template, [var1, val1 [, …[, varN, valN]]])

string phella_clear_cache(string template, [array vars])

synonym [phella_class]: phella::clearCache(…)

The function clears cache created by phella_include_cache() . Arguments notation is the same. The best place to call this function is the module where database updated, new records inserted or deleted.

phella_email()

string phella_email(string Email [, string Display [, string AddHtml ] ] )

synonym [phella_short]: email(…)

Simple Java script scrambler for protection against email harvesting bots.

Display is the text within <A>...</A> tags. If ommited Email will be used.

AddHtml is additional HTML properties for the <A ... > tag (style, class, etc.).

See usage and its output:

<p>This is what user sees:
<br><?=phella_email("info@phella.net")?>
<p>This is what bot sees:
<br><?=htmlspecialchars( phella_email("info@phella.net") )?>
LIVE SAMPLE

This is what user sees:

This is what bot sees:
<script>document.write(String.fromCharCode(60, 97, 32, 104, 114, 101, 102, 61, 34, 109, 97, 105, 108, 116, 111, 58, 105, 110, 102, 111, 64, 112, 104, 101, 108, 108, 97, 46, 110, 101, 116, 34, 32, 62, 105, 110, 102, 111, 64, 112, 104, 101, 108, 108, 97, 46, 110, 101, 116, 60, 47, 97, 62));</script>

phella_control()

mixed phella_control(string Key [, mixed Value ])

synonym [phella_class]: phella::control(…)

This function issues certain signals to the Controller in order to change it behaviour at runtime. It also may returns current state of the Controller. Currently there are following signals are used:

KeyValueDescription
'run''standalone'Pre- and Post-templates are not included. This may be use when you need for example to form a pop-up window without usual header and footer.
'no-cache'trueDo not cache output for this run
'error-name'Returns name of the template which was not found
'error-path'Returns the path where template was looked at

phella_head()

mixed phella_head([string Key,] [mixed Value])

synonym [phella_class]: phella::head(…)

This function helps to place data in between HTML HEAD tags. It doesn't matter in what moment and how many times you call this function it always will place passed text in proper position.

Usually we have HEAD tags in the header ( pre-template ). Something may need to be changed or added in HEAD depending of body contents. The most prominents sample is the TITLE tag. Almost everybody would love to change while workin on the body part. With Phella you can do it!

Another sample: sometime we may use a JavaScript say Calendar. We don't need it on every page but only for the reservation form. The script is not large but it's no sense to include it on every page. Then with this function you may include only when it necessary.

Key is the modifier which you can use or not. If you ommit it then any time you call the function it will add Value between HEAD tags. If you want to be sure that certain text placed only once than provide some unique Key.

There are some predefined Key values:

KeyDescription
'title''Adds TITLE tag with the text given in Value; phella_head('title','New title') is equivalent to phella_head('<title>New title</title>')
'cross-browser/?????''Adds link to a javascript file "?????.js" from the cross-browser library (see www.cross-browser.com)

One time you need to place this function call without any arguments exactly between HEAD tags. In that place all additional text will be inserted. See Default Setup for sample.

phella_onload()

mixed phella_onload( string Code [, string Position ])

synonym [phella_class]: phella::onLoad(…)

This function registers javascript code to be executed at the page onLoad event. Code is the string of javascript code without <SCRIPT> tag.

It is possible to call the function several times and register several chunks of code. By default they added one after another, but if it's necessary to put something at the head of the queue then pass 'top' as Position argument.

...
<img src="loading.gif" id="animation">
<? phella_onload('getElementByID("animation").style.visibiliy="hidden";') ?>
...

phella_error()

mixed phella_error( string Message [, int Type ])

synonym [phella_class]: phella::error(…)

This function throws error message from the name of Phella and may be usefull for plugin developers. The function triggers standard PHP error mechanism. It reports not the current breakpoint but guesses location of the error in user's source code.

Type is the standard PHP error type default to E_USER_NOTICE.

Module phella_short

Provide alternative shorter notation for some often used core function. See Core Module for description.

Module phella_class

Provide alternative notation for core function. See Core Module for description.

Module phella_debug

This module has a function which may help to find possible problems of the workflow.

phella_watchpoint()

string phella_watchpoint( [ string Prompt [, mixed Test ] ] )

synonym [phella_short]: wp(…)

This function displays information about content of Test at the point where it was invoked. If Test is ommited then $INPUT and $OUTPUT arrays will be taken. Prompt argument helps to distinguish between different calls in different places.

<p><?wp()?>The function presents its output in compact manner different from standard <var>var_dump()</var> using some JavaScripting.
As the an example this function has been called in the beginning of this paragraph. Click on the large dot to display the data.
LIVE SAMPLE

•