PHP Booosta

PHP Booosta 3 Tutorial

Editing the PHP and template files

Before we start editing the files that have been autmatically generated, we will have a look on them. Here is how the registration.php looks like:

<?php
include_once 'lib/framework.incl.php';

class App extends booosta\usersystem\Webappadmin
{
  #protected $fields = 'name,edit,delete';
  #protected $header = 'Name,Edit,Delete';
  #protected $checkbox_fields = '';
  protected $null_fields = ['birthdate','comment'];
}

$app = new App('lecturer');
$app->set_subname('course');
$app->auth_user();
$app();
?>

Let's analyze this file:

We included lib/framework.incl.php. This is the central include file ob Booosta. You need to include this on the top of every file. But it is ususally the only file you have to include.
A new class named "App" is defined that is derived from the class booosta\usersystem\Webappadmin. This class provides all the code necessary to add, edit and delete records in the database table. You do not need to call this class "App". You can choose an other name if you want.
Next there are 3 commented out lines. They are there for your convenience. If you need this variables you just have to uncomment and edit them. The $fields variable for example determines which database fields should be displayed in the list of existing records. $header represents the headline of the table displaying these records. $checkbox_fields tell Booosta which fields are represented by checkboxes in the according HTML form. It can't figure out this information by itself because web browsers do not send unchecked checkboxes in the request - they just omit this field.
Then there is a variable $null_fields. This tells Booosta that if an empty string is provided by the request, it should store the value NULL in the database and not an empty string for these fields.
After the class definition, the class is instantiated. As parameter for the constructor we provide the name of the database table that should be worked on.
We tell the new created object now, that there is a subtable named "course".
Then we ask the object to authenicate the currently logged in user. If no valid admin user is logged in, it redirects the browser to the login page. Why does the object know that it should look for an admin user and not a normal user? Because it is derived from the class Webappadmin and not Webappuser!
Finally we call the run method of the object. This notation is short for $app->run().

This is all the code we have for managing our lecturers. All the basic functionallity is provided by the superclass. This example shows you the standard way to write code in Booosta. You define your own classes and make modifications to them. Then you instantiate an object from it and run it.
Let's have a look on the course.php:

<?php
include_once 'lib/framework.incl.php';

class App extends booosta\usersystem\Webappadmin
{
  #protected $fields = 'name,edit,delete';
  #protected $header = 'Name,Edit,Delete';
  #protected $checkbox_fields = '';
  protected $null_fields = ['description'];
}

$app = new App('course');
$app->set_supername('lecturer');
$app->auth_user();
$app();
?>

It looks pretty much similar, except that we have set a supername instead of a subname. No additional magic here. Finally we have the registration.php:

<?php
include_once 'lib/framework.incl.php';

class App extends booosta\usersystem\Webappadmin
{
  #protected $fields = 'name,edit,delete';
  #protected $header = 'Name,Edit,Delete';
  protected $foreign_keys = [['course' => ['table' => 'course']],['user' => ['table' => 'user']],];
  #protected $checkbox_fields = '';
}

$app = new App('registration');
$app->auth_user();
$app();
?>

Here we have something new: $foreign_keys. This variable tells the system, which fields in the database table points to a record on another table. Here it says that the field "user" is a foreign key to the table user and the same goes for "course".
As we learned before, our application consists of PHP files and templates. So let's have a look on the templates. For every script there are 3 templates that are autogenerated: *_default.tpl, *_new.tpl and *_edit.tpl. They are for the display of the record list, for the creation of new records and the editing of existing records. Let's look at the templates for lecturer:

tpl/lecturer_default.tpl:

{BBOXCENTER bboxsize::12}
{BPANEL paneltitle::Lecturer}
{BLINKADD|New Lecturer|lecturer.php?action=new}

{%liste}

{/BPANEL}
{/BBOXCENTER}

First, we have two lines that define the layout of the page. It draws a box on the page and puts a panel into it.
Then we have the link for creating a new lecturer.
After that we have a variable named "liste".
Finally we close the panel and the box.

We see here, how templates are built. There are tags like BLINKADD and variables like liste. Tags are are surrounded by { and }. They have parameters that can be seperated by blanks or by |. If you seperate them with | you can use blanks in a parameter (like in "New Lecturer"). Variables are surrounded by . Their content is read from the object variable $TPL in the object. The content of for example comes from $this->TPL['liste'] in the object.

tpl/lecturer_new.tpl:

{DATEINIT}
{BBOXCENTER}
{BPANEL|paneltitle::New Lecturer}

{BFORMSTART|lecturer.php|onSubmit::return checkForm();}
{HIDDEN action newdo}

{BTEXT|name|texttitle::Name}
{BDATE|birthdate|texttitle::Birthdate}
{BFORMGRP|Gender|size::4}{SELECT|gender
m
f}{/BFORMGRP}
{BTEXTAREA|comment|40|10|textareatitle::Comment}

{BFORMSUBMIT class::center-block}
{BFORMEND}

{/BPANEL}
{/BBOXCENTER}

We have some interesting new things here:

We have a from starting here pointing to lecturer.php and an onSubmit Javascript trigger.
We have a hidden field "action" for the form with value "newdo"
A text field "name" with a title, that is displayed in front of the input field
A date field named "birthdate"
A form group element, which surrounds the following select field
The select field named "gender" with the two options "m" and "f"
A Textarea named "comment" with 40 columns and 10 lines
A submit button for the form

tpl/lecturer_edit.tpl:

{DATEINIT}
{BBOXCENTER}
{BPANEL|paneltitle::Edit Lecturer}

{BFORMSTART lecturer.php}
{HIDDEN action editdo}
{HIDDEN id {%id}}

{BTEXT|name|{%name}|texttitle::Name}
{BDATE|birthdate|{%birthdate}|texttitle::Birthdate}
{BFORMGRP|Gender|size::4}{SELECT|gender|{%gender}
m
f}{/BFORMGRP}
{BTEXTAREA|comment|40|10|textareatitle::Comment
{%comment}}

{BFORMSUBMIT class::center-block}
{BFORMEND}
{/BPANEL}
{/BBOXCENTER}

{BBOXCENTER bboxsize::12}
{BPANEL|paneltitle::Course}
{BLINKADD|New course|course.php?action=new&lecturer={%id}}

{%subliste}

{/BPANEL}
{/BBOXCENTER}

The template for editing has some differences:

First, it has an additional hidden field "id" which passes the id of the record to edit to the PHP script.
There are default values in the form fields, which contain the current values in the database. This is to make sure that current values are in the form when editing a database record with this form.
There is a second box that shows the variable "subliste". This is only the case, if we have a subtable for the current table.

Now let us edit the registration.php. What do we want to change? First, the users are not displayed in the select. Second, it would be a good idea, if the registration date is saved automatically to the current date and not filled in in the web form. Last we want to have the grade "not attended" as the default setting in the select. To achieve this, we make the following adjustments to our code:

<?php
include_once 'lib/framework.incl.php';

class App extends booosta\usersystem\Webappadmin
{
  #protected $fields = 'name,edit,delete';
  #protected $header = 'Name,Edit,Delete';
  protected $foreign_keys = [['course' => ['table' => 'course']],['user' => ['table' => 'user', 'showfield' => 'username']],];
  #protected $checkbox_fields = '';

  protected function before_add_($data, $obj)
  {
    $obj->set('regdate', date('Y-m-d'));
  }
}

$app = new App('registration');
$app->auth_user();
$app();
?>

You see two changes here:

We told Booosta, that the field to show ("showfield") for "user" is "username".
We added a hook function. To learn what hook functions are, please read the fine manual. What we do here is to tell the object to do something, before it adds the record to the database. What does it do? It takes the object containing all the data that will be inserted in the database and manipulates the field "regdate" by setting it to the current date. The data object now has this value stored and will save it in the database.

We also need a change in the template tpl/registration_new.tpl:

{DATEINIT}
{BBOXCENTER}
{BPANEL|paneltitle::New Registration}

{BFORMSTART|registration.php|onSubmit::return checkForm();}
{HIDDEN action newdo}

{BFORMGRP Course size::4}{%list_course}{/BFORMGRP}
{BFORMGRP User size::4}{%list_user}{/BFORMGRP}
<!-- line deleted -->
{BFORMGRP|Grade|size::4}{SELECT|grade|Not attended
Excellent
Good
Average
Deficient
Failing
Not attended}{/BFORMGRP}

{BFORMSUBMIT class::center-block}
{BFORMEND}

{/BPANEL}
{/BBOXCENTER}

You see we made two changes. We deleted the line where the regdate was displayed (you should just delete this line and not replace it by the comment like we did). And we added a default value to the select "grade". If you got to add a registration now, you will see the changes. You can register your first user with a course now.

Previous - Next