|
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.
|
