Embperl - building dynamic websites with Perl

How the menu structure is defined in config.epl doesn't matter. In case of the Embperl website this is done within a Perl hash, but it could also have been a XML file, the only point is that the method get_menu returns it in a well defined way.

The config object and the menu struture is placed into the request object. Just like the application object, the request object is a blessed hash reference. You can use theses hashs to store your own object data. Embperl itself doesn't store anything inside of these hashs. The difference between request and application object is their life time. While the request object and all data it contains, is destroyed at the end of the request, the application object is only destroyed when the server ends.

The method fill_menu now takes this menu structure and the parameters of the request and prepares it for displaying. So when finaly menuleft.epl is invoked to display the menu, it only has to take the prepared data and surround it with a nice layout. It doesn't contain any logic anymore, so we have seprated the logic into the application object and the layout into the template.

Another imported feature of the application object is, that it is invoked before any output is generated, so you are able to modify most of the request parameters. This is done in the next few lines of the init method, by callining map_file. map_file tries to locate the requested uri in the configuration provided by config.epl and, if found, returns the actual filename for it. It also takes into account other parameters like the preferred language to map to the correct file. The init method now modifies the request to serve this file, instead of using the one that come out of the mapping done by Apache.

As we have seen before the application object is search in the same way as other pages. We can use this to define a derived application object to extent functionality. For the Embperl website this is done in the /db directory. The website provides several bit of information, which are stored in a database, like news, links, examples, etc.

All necessary pages for the database access are beneath the /db directory and it also contains a file epwebapp.pl. So when any page underneath /db is requested Embperl::Object will find this application object instead of the one in the base directory. This application object provides all necessary logic for the database access, but we still need the functions from application object we have discussed above. So what we do is tell Embperl that is application object inherits from the first one. This is done by calling Execute with the isa parameter:

    BEGIN { Execute ({isa => '../epwebapp.pl', syntax => 'Perl'}) ; }

This call load and compiles the base object and adjusts the @ISA array of the calling object accordingly to get a proper inherence. This object also has an init method, which looks like this:

    sub init 
        {
        my $self = shift ;
        my $r = shift ;

        $self->SUPER::init($r) ;
        $self->initdb($r) ;

        if ($fdat{-add_category}) 
            {
            $self -> add_category ($r) ;
            $self -> get_category($r) ;
            } 
        elsif ($fdat{-add_item}) 
            {
            $self -> add_item ($r) ;
            $self -> get_category($r) ;
            $self -> get_item_lang($r) ;
            } 
        elsif ($fdat{-show_item}) 
            {
            $self -> get_category($r) ;
            $self -> get_item_lang($r) ;
            } 
        else 
            {
            $self -> get_category($r) ;
            $self -> get_item($r) ;
            }
        return 0 ;
        }

First it calls SUPER::init to give the base class a chance to do its initialization. Then it calls initdb, which sets up database connections etc. As next step it checks the hash %fdat, which contains all the form data that is send by GET or POST to the page. Depending on what the user requested when he/she submit the form, different methods are called, which do the database access, like retrieving data and inserting new items etc. The result of the database access is again placed into the request object so it's available to the be displayed.