Home : Introduction : Embperl::Object
Google Web perl.apache.org

 
Home
 
Features
 
Introduction
 
Embperl
 
Embperl::Object
 
Embperl 2 Advanced
 
DBIx::Recordset
 
Documentation
 
Installation
 
Download
 
Support
 
Changes
 
Wiki
 
More infos
 
Add info about Embperl
 
Login

    Stable 2.4.0
    Beta 2.5.0_3
Support the development of Embperl! More...
Modular File Inheritance
[ << Prev: Modular Files ] [ Content ] [ Next: Subroutines in EmbperlObject >> ]

To recap, we have seen how we can break our site into modules which are common across multiple files, because they are automatically included by base.epl. Inheritance is a way in which we can make our websites even more modular.

Although the concept of inheritance is one that stems from the object-oriented paradigm, you really don't need to be an OO guru to understand it. We will demonstrate the concept through a simple example, leading on from the previous one.

Say you wanted different parts of your website to have different <TITLE> tags. You could set the title in each page manually, but if you had a number of different pages in each section, then this would quickly get tiresome. Now we could split off the <HEAD> section into its own file, just like constants.epl and init.epl, right? But so far, it looks like we are stuck with a single head.epl file for the entire website, which doesn't really help much.

The answer lies in subdirectories. This is the key to unlocking inheritance, and one of the most powerful features of EmbperlObject. You may use subdirectories currently in your website design, maybe for purposes of organization and maintenance. But here, subdirectories actually enable you to override files from upper directories. This is best demonstrated by example (simplified to make this specific point clearer - assume constants.epl, init.epl and cleanup.epl are the same as in the previous example):

/base.epl

   	<HTML>
	[- Execute ('constants.epl')-]
	[- Execute ('init.epl')-]
   	<HEAD>
	[- Execute ('head.epl')-]
	</HEAD>
	<BODY>
	[- Execute ('*') -]
	</BODY>
	[- Execute ('cleanup.epl') -]
	</HTML>

/head.epl

<TITLE>Joe's Website</TITLE>

/contact/head.epl

<TITLE>Contacting Joe</TITLE>

Assume here that we have an index.html file in each directory that does something useful. The main thing to focus on here is head.epl. You can see that we have one instance of this file in the root directory, and one in a subdirectory, namely /contact/head.epl. Here's the neat part: When a page is requested from your website, EmbperlObject will search automatically for base.epl first in the same directory as the requested page. If it doesn't find it there, then it tracks back up the directory tree until it does find the file. But then, when executing base.epl, any files which are Executed (such as head.epl) are first looked for in the original directory of the requested file. Again, if the file is not found there, then EmbperlObject tracks back up the directory tree.

So what does this mean exactly? Well, if we have a subdirectory, then we can if we want just have the usual index.html file and nothing else. In that case, all the files included by base.epl will be found in the root document directory. But if we redefine head.epl, as in our example, then EmbperlObject will pick up that version of the file whenever we are in the /contact/ subdirectory.

That is inheritance in action. In a nutshell, subdirectories inherit files such as head.epl, constants.epl and so on from upper, "parent" directories. But if we want, we can redefine any of these files in our subdirectories, thus specializing that functionality for that part of our website. If we had 20 .html files in /contact/, then loading any one of them would automatically get /contact/head.epl.

This is all very cool, but there is one more wrinkle. Let's say we want to redefine init.epl, because there is some initialization which is specific to the /contact/ subdirectory. That's fine, we could create /contact/init.epl and that file would be loaded instead of /init.epl whenever a file is requested from the /contact/ subdir. But this also means that the initialization code which is in /init.epl would never get executed, right? That's bad, because the base version of the file does a lot of useful set up. The answer is simple: For cases like this, we just make sure and call the parent version of the file at the start. For example:

/contact/init.epl

[- Execute ('../init.epl') -]

[- # Do some setup specific to this subdirectory -]

You can see that the very first thing we do here is to Execute the parent version of the file (i.e. the one in the immediate parent directory). Thus we can ensure the integrity of the basic initialization which every page should receive.

EmbperlObject is very smart about this process. Say, for example, we have a situation where we have several levels of subdirectory; then, say we only redefine init.epl in one of the deeper levels, say /sub/sub/sub/init.epl. Now, if this file tries to Execute ../init.epl, there may not be any such file in the immediate parent directory - so EmbperlObject automatically tracks back up the directories until it finds the base version, /init.epl. So, for any subdirectory level in your website, you only have to redefine those files which are specific to this particular area. This results in a much cleaner website.

You may break your files up into whatever level of granularity you want, depending on your needs. For instance, instead of just head.epl you might break it down into title.epl, metatags.epl and so on. It's up to you. The more you split it up, the more you can specialize in each of the subdirectories. There is a balance however, because splitting things up too much results in an overly fragmented site that can be harder to maintain. Moderation is the key - only split out files if they contain a substantial chunk of code, or if you know that you need to redefine them in subdirectories, generally speaking.


[ << Prev: Modular Files ] [ Content ] [ Next: Subroutines in EmbperlObject >> ]

© 1997-2012 Gerald Richter / ecos gmbh