Re: [cgiapp] directory structure and static pages

[Shaun Guth <suppressed>]

On Thu, 2003-09-04 at 07:01, Andy Taylor 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?

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

I have moved towards using 3 top-level directories for all my work.  If
my domain was foobar.com, the vhosts dir would look like:

/var/www/foobar.com/source/
/var/www/foobar.com/output/
/var/www/foobar.com/system/
                    system/templates
                    system/modules

'source' contains exactly the structure that the website will have when
it's built, so it holds template files that mirror the real site (ie, a
file named index.html, but with template code in it).

'output' is where cached versions of the rendered pages will go

'system' contains the .cgi scripts we use.  In our hypothetical
situation we have two scrips - 'render.cgi' that will build our static
pages and 'dynamic.cgi' which will output search results or something.

'system/modules' directory is for our CGI::App modules, probably
something like App::SuperClass,  App::Renderer,  App::Dynamic

The superclass is set up to initialize the template engine for including
files from our 'system/templates' directory.  This is where my common
header/footer/etc go.


Now for the tricky bit:  I use a mod_rewrite script (but I think a
custom mod_perl request handler would be more efficient) to do the
actual 'work' of determining what's a dynamic and what's a static
request.  Essentially it goes through 4 steps:

1.  Pass through any specific requests for /source/* or /output/* (this
is so pages can link directly to images without the mod_rewrite handler
getting in the way).  Pass through any requests for /system/ as well,
since this will get called by forms which call and use the
'dynamic.cgi'.  Stop processing if the URL matched here.

2. Does the file that the user is requesting exist in the 'output'
directory?

    "Yes" - Then we just rewrite the URL to the output directory and off
they go (this is serving up our 'cached' page). Stop processing

3. (If "No" from #2):  Does the file that the user is requesting exist
in the 'source' directory?

    "Yes" - Then we rewrite to /system/render.cgi and pass the name of
the page we need to render.  The 'render.cgi' script reads the source
file in, creates the appropriate cached document, and then serves it up
to the client. Stop processing.

4. (If "No" from #3):  Error finding the file, serve up a 404 page,
write out a log entry, do a happy dance, etc :) 


My humble apologies if this is exceedingly abstruse - I had to rush the
reply, but I hope you get the general idea.  Feel free to contact me
privately, and I can arrange for you to see some of the code.  Be aware
that most of it relies on TT2 not H::T and is slightly more complex than
the setup I have described here, but I have used it successfully in
production.  The site that utilizes this mechanism  gets roughly 4.25
million hits / 180,000 unique visitors per day and have not had any
significant problems.


Shaun Guth


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