Andy Taylor <suppressed> wrote:
>
> 1. if you are doing a project with a superclass and several modules,
> where do you put your templates and how do you organize them? For
> instance, if /home/ataylor is my home dir, do most people do
> something like /home/ataylor/project/modules and
> /home/ataylor/project/templates and put all the templates in one big
> directory?
i learned the way i do development environments from Jesse during my stint
at Vanguard, have used this methodology pretty religiously since, and it's
served me well. my development environments are always under cvs revision
control, so one requirement of this system is a strong separation between
what is, and what's not, under revision control. of course, perl modules
and templates are always under cvs, while system generated data files, file
uploads, and logs are not, but even these non-cvs files have homes in the
project's directory structure. i lay out each project under a PROJECT_ROOT
directory that contains no files itself, just the subdirectories, with
"project_name" being the the cvs module name, as well:
project_name/
htdocs/
modules/
templates/
devdocs/
conf/
bin/
externals/
logs/
the "externals" and "logs" subdirectories are where transient data files and
apache logs live, but only the directories themselves exist in cvs, no files
in these directories are version-controlled. these directories contain just
one file in cvs, a .cvsignore file, containing a lone asterisk, to keep just
the existence (and name) of the directory in the repository, while keeping
the files themselves out of cvs,and local to the installation.
bin/ is where i put miscellaneous command-line utilities such as backup
scripts, cron jobs and tools for developers to use on a new checkout to say,
set permissions on files and initially generate any local conf files.
htdocs/ is obviously the apache document root of the site - i don't use
cgi-bin directories, as such, outside of the document root, preferring
instead to let my instance scripts live in place right alongside
the static html pages and images etc. of the site's publicly accessible
files. some clients, and other places that i've worked, have insisted on
using a cgi-bin outside of the doc-root, and only allowing executable
scripts to be invoked from there (using apache's ScriptAlias directive),
which is fine and works well also. it just makes the list of subdirectories
in the project_root one entry longer :-)
modules/ is of course where the perl modules reside, and the
templates/ directory contains the html-template files (more below)
devdocs/ is just that, development docs, where the database schema and a log
of database structure changes (an "executable" log of SQL DDL statements) is
maintained, along with installation notes, and sometimes even tarballs of
other software needed to be installed in the project root to setup new dev
environments or production sites. having the database structure and it's
changes, add-hoc installation notes and original versions of installed
modules here, under CVS has saved me much grief.
conf/ contains the local environment's configuration files, in particular an
apache.conf file (or a relevant subset thereof, such as this site's
<VirtualHost> block). Jesse often made this file an html template,
especially in situations where there were multiple development environments,
a staging server and a production site, each a cvs checkout and updated
directly from cvs. in this case, one would run a script in bin/ after a cvs
checkout or update if necessary, to regenerate a local conf file from the
template. for a simpler setup i'l often keep a vhost.conf-sample (or
.htaccess-sample) in cvs and maintain the corresponding "live" conf file for
it in each environent by hand.
but whether the site conf needs to be maintained from a template or by hand,
it keeps all the local installation-specific information in one place, so
that the virtual hostname, and Apache environment variables defined below,
are all that have to be tailored so that the software will have what it
needs to locate perl modules, templates, database connections to use,
without having to touch the code. in the virtual host conf (or even an
.htaccess file) i will typically have:
# for perl to find my local modules
SetEnv PERL5LIB /path/to/project_name/modules
# for C::A and H::T to find my templates
SetEnv HTML_TEMPLATE_ROOT /path/to/project_name/templates
# for scripts to use as the base dir for data files, uploads, etc.
SetEnv EXTERNALS /path/to/project_name/externals
# for DBI to find a database connection
# DBI_DSN and/or DBI_USER may also be defined here
this way, perl scripts can just say:
use MyProject::User::Manager;
and since PER5LIB points to my environment's own modules directory, apache
has already configured my scripts to resolve the relative location of:
MyProject/User/Manager.pm
as
/path/to/project_name/modules/MyProject/User/Manager.pm
and scripts don't have to be modified to work when checked out of cvs into
new development environments. you just have to tailor the conf files to the
particular installation environment, in the same place you might configure
the site as mod_perl vs. CGI-exec mode, or turn on and off debugging flags
and other locally tweakable variables and settings.
for the templates (and to answer your actual question), if i have, for
instance, these 3 C::A modules, in my modules directory:
modules/MyProject/User/Manager.pm
modules/MyProject/User/Profile.pm
modules/MyProject/Login.pm
for their associated templates, i like to have the a similar directory
structure mirrored under templates, but unlike perl modules there's no need
for a top-level MyProject directory, since al the templates in here are
specific to my project (and there's scant chance i'll need a place to put
3rd party "cpan templates", the way i'll often need a place to install cpan
perl modules :-)) so i end up with a templates subdirectory structure like:
templates/User/Manager/list_users.tmpl
templates/User/Manager/add_user.tmpl
templates/User/Manager/edit_user.tmpl
templates/User/Profile/view_profile.tmpl
templates/User/Profile/edit_profile.tmpl
templates/User/Login/login_form.tmpl
templates/User/Login/password_reminder.tmpl
i like grouping similar apps, such as a User Management application (that
is available only to admins), with a similar user profile app, even though
they have different security modules, because if i ad a new user field, or
restructure the users database these are the apps that would tend to need
maintenance.
notice also that each perl ModuleName is represented in templates as a
*directory*. that's because each CGI::Application, having multiple
run-modes, tends to have several corresponding template files. and i don't
like to search through long lists of template filenames to find the ones
that apply to the module i'm working on. also, as you can see i tend to
name my templates as $verb_$noun.tmpl (edit_user, view_profile, etc.) so if
you throw a bunch of these, that belong to different apps, together into a
single directory, they tend to sort badly, with all the add_this and
add_that's together at the top, and their corresponding view_this and
view_that waaaay down at the bottom. anyway it works for me because i also
tend to lean towards modules with one "subject" (user) and no more than 3-6
major types of "operations" such the archetypical create, read, update &
delete. i find that the 3-6 operations typically involve 2
run-modes per, and one template per, though a couple more of either always
tend to creep in. this tendency to have more modules with fewer major
"operations" per module is just my preference. it seems that many folks
tend to use a single CGI-App to house all the code for an entire site, from
authentication and authorization, to user management to
<whetever-else-the-site-does>. i think my leanings toward more modules, in
more ditrectories, is driven by my desire to be able to reuse a thing (like
a user management script) by just scooping up it's perl module and templates
subdirectory from one site and plunk it down in another and not have to
spend time trying to tease the relavent run-modes out of a larger monolithic
.pm file :-)
now, thanks to apache taking care of setting the HTML_TMPL_ROOT environment
variable, my C::A modules can simply say:
load_tmpl('User/Manager/list_users.tmpl')
and not care what the top-level absolute pathname was, in order to find it
under this environment's templates directory with no code changes (after the
initial configuration of the environment).
although i've never needed to make use of them, both PERL5LIB and (i
believe) HTML_TMPL_ROOT even support a colon separated list, as a means of
specifying a *list* of absolute paths to search, if you should find a
situation where you need an archy even hier than this one :-) such as
several sites that share common headers and menus templates but house
different apps (i guess -- as i said, even *i* never seem to need *that*
many nested directories...)
> 2. for a large project, not all of the pages have to be dynamic
> obviously. How do people deal with static pages that you want to
> still share the look of your dynamic pages that you are using
> HTML::Template for? I was considering creating a commandline tool to
> generate the static pages from the HTML::Templates or creating a
> module just for serving static pages (not that they would be static
> anymore) and wrapping the header and footer, setting the title, etc.
> but each of these have downsides. How do the experts do it?
this has been a thorny spot for me in the past. in one case i setup a
simple cgi script (that wan't even a CGI-App) to simply load a "header"
template and populate it based on the user's login session. this script
could then be called using SSI from a static html file (to "include" a
semi-dynamic header or left-navigation menu), and the same header and menu
templates were shared by many (if not all) of the other *application*
templates, as HTML-template includes. i found it a bit awkward though, to
say the least.
while "tmpl_include" is there, unfortunately IMO, there is no corresponding
"wrapper" or include_me_into concept in very many template systems that i've
seen.
i've also toyed with "the nother" approach, i think more like the one you
describe, where sets of physically static files are generated and
regenerated periodically (or using some on-demand caching scheme) from a
corresponding set of templates, but i always end up deciding that, for the
given (small-ish sized) project at hand, that way lies madness, for me.
i think an H::T-based CMS system, like Cascade, Bricolage and/or (what was
the other one recently announced and discussed on the H::T list?) may be the
answer when you find yourself needing to generate many static pages from
dynamic templates, especially if you need to do so on an ongoing basis, and
need to also provide some flexible options for doing publishing runs and
caching output. i haven't checked into the CMS's yet because i always find
my need is more just to ease my own template development and maintenance
chores, not to deliver to users a "skinnable" website :-)
hope this helps you answer *some* of your questions,
-dave
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.